[RockerC]

Suggest that you look into implementing the UMMS (Unified Multimedia Service) audio/video player abstraction layer framework into XBMC.

This article and UMMS introduction pdf sums up UMMS much better then I even can
http://lwn.net/Articles/465178/
http://wiki.meego.com/images/LinuxCon_20...uction.pdf

However to put it simple, UMMS is an open source abstraction layer framework that have an consistent API which would make it possible for video and audio players to be treated as (binary) addons in XBMC.

Separating the video and audio players from the core XBMC application would also mean XBMC could have multiple video players and multiple audio players, and they could all be upgraded separately from the core application just like any other addon in XBMC.

Having the video and audio player separate binary addons using this API could open up future possibilities like having third-party closed source players dedicated for Blu-ray Disc playback or even DRM protected video on demand services like Netflix. This is possible since UMMS is LGPL licensed and is designed to use D-Bus service API to communicate between the frontend, and the backends it is language-independent and capable of providing license isolation, it could also be made to use a other open API then D-Bus, such as JSON-RPC or WebSocket to provide an bi-directional communications channel between the frontend and the backends.




Brendan Le Foll (username arfoll on the XBMC forums who also ported XBMC to MeeGo) have actually already coded his own proof of concept UMMS player for XBMC called madeo-uplayer that uses GStreamer and is written in Python
https://github.com/arfoll/Madeo-MUMS-player
https://github.com/arfoll/xbmc/tree/meegoplayer


UMMS official site
http://wiki.meego.com/Umms

Official and active / up-to-date Git repositories for MeeGo middleware like UMMS are on meego.gitorious.org
http://meego.gitorious.org/meego-middleware/umms

Public git repo:
git://gitorious.org:meego-middleware/umms.git

First version of the module for Universal Multi Media Service has been published on the Meego OBS
https://build.meego.com/package/show?pac...A1.2%3Aoss

The initial technical specification was published in March 2011 and can be found here
http://wiki.meego.com/File:Meego_Unified...e_V0.4.odt


Hope that the team developers have time to look into UMMS or some other type of a/v player abstraction layer framework for XBMC

[RockerC]

Bumping this as it should be even more interesting now with XBMC getting ported to all different types of embedded platforms

Intel is still pushing for UMMS for the MeeGo TV that will soon become Tizen TV, with XBMC as reference media player

Unified Multimedia Service is python. Using python as the main internal player makes me nervous.

I think you misunderstand, looking at the code, the UMMS framework is not Python, its coded in C for front-end core integration

https://github.com/arfoll/UMMS look under the "src" folder for the UMMS front-end C code which would go into the XBMC core or lib

Again note though that it is Gitorious that have the actively developed repository http://meego.gitorious.org/meego-middleware/umms


UMMS is a very similar concept to that of the PVR abstraction layer framework for XBMC front-end, only one API, many back-ends

Unified Multimedia Service is a abstraction layer framework that allows for the players to be written in any programming-language

UMMS front-end which is the core and middleware with uniformed API for players, then it has separate binary players as back-ends

You could write the main internal player for XBMC in C or C++ and just have it use the UMMS API, inc. porting DVDPlayer to UMMS

The beauty of UMMS is that XBMC could have multiple audio/video players in different programing-languages via same common API


I highly recommend you all read this article about UMMS audio/video abstraction layer, it sums without looking having to at the code

http://lwn.net/Articles/465178/


Suggest that you have a talk about it with Brendan Le Foll (username arfoll on the XBMC forums who also ported XBMC to MeeGo)

Remember that the MeeGo TV project developers who coded UMMS used XBMC as their reference GUI

[RockerC]

Version 0.1of UMMS (Universal Multi Media Service) is now available
http://lists.meego.com/pipermail/meego-t...00123.html

Hello,

I am pleased to announce that a new version of UMMS (Universal Multi Media Service) is available.

To ease your test an development before integration in your device, you will also find a PC version which may not provide the same level of video decode performance depending of your HW but will offer the same D-BUS API.

You will find all the details on our Wiki http://wiki.meego.com/Umms

For convenience, a short description of the update in included bellow.

Enjoy

Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG

--

Some useful resources for UMMS:

Wikipage:

http://wiki.meego.com/Umms
http://wiki.meego.com/UMMS_Architecture
http://wiki.meego.com/UMMS_User_Manual

Packages:

umms core:
http://build.meego.com/package/show?pack...3Atv%3A1.2 <http://build.meego.com/package/show?package=UMMS&project=devel%3Atv%3A1.2>

umms-plugins-tv:
Unfortunately due to license and HW specific features, this module only available via your Intel rep or Intel HW reseller.

umms-plugins-netbook:
http://build.meego.com/package/show?pack...3Atv%3A1.2


Public repo:
git://gitorious.org:meego-middleware/umms.git

[RockerC]

Got this reply when I asked Brendan Le Foll if he himself was planning on pushing the UMMS player backend framework upstream as a pull request to XBMC

I am not planning on submitting the UMMS player backend to XBMC
upstream. It could actually live in XBMC upstream fairly easily,
especially now with the recent NORENDER extension davilla added to
LinuxRendererGLES (after discussions with me). The way UMMS provides
playback in XBMC is via GDL transparency, something only supported on
an Intel CE platform. My XBMC builds live in MeeGo images on public
Intel/Linux foundation owned websites and they do not want patent
infringing (ffmpeg,libmad, etc...) code living there. Therefore my
github tree is cleaned up.

Davilla talked to me about providing a way to 'clean' upstream
code (via a script or similar) though nothing has materialised upstream yet.

From what I understand the XBMC team want to keep dvdplayer as the
main player and extend it, whilst I simply replace it to avoid patent issues.
(conditional compilation does not offer patent safety ;-))

Team XBMC know where my code is, and I've had a bit of contact with
them over the past year. If they are interested in pushing the
meegoplayer/UMMS code upstream then that really is their call and I'd
be glad to help with that. But realistically pushing the UMMS code
upstream provides very little to the XBMC community, as most embedded
platforms don't ship with GStreamer elements (at least not of a decent
quality), and so far UMMS+GDL transparency is supported on IntelCE
only.

Note that I've tried to push a few things upstream such as the
--no-mysql option I've added, however there seems to be little
interest in pushing it upstream. I've removed the UMMS repository on
github ( https://github.com/arfoll/UMMS), the gitorious one is the one
that should be used, I did this before the gitorious one was set up.

Cheers,
Brendan

My hope is that UMMS will not only live in the Meego TV project where no other XBMC derivative projects knowing it exists when all could utilize it

[RockerC]

Maybe the UMMS framework is of interest for XBMC to look at again now that we have multiple players like AMLPlayer, OMXPlayer, DVDPlayer, etc.?


Perhaps another interesting news here is that the Ubuntu TV team have sent in a rewrite proposal and design change suggestion for UMMS but their ideas was mostly shot down:

http://lists.meego.com/pipermail/meego-t...hread.html

UMMS rewrite proposal and design change

Overview
---------------

UMMS currently is an excellent start to a mostly comprehensive media
API. However, the Ubuntu TV team believes that it could be refactored to
be even better with a few adjustments to the design, and rewriting it
using C++. The main design difference is the elimination of the plugin
architecture, converting what were called plugins into separate
processes that communicate with the higher level media API via D-Bus.
The other design difference is to separate the recording functionality
out into its own module called Recording Manager.


Rewrite in C++
----------------------

The current implementation of UMMS is in C using the GLib/GObject
libraries to provide an object-oriented experience. From experience, the
Ubuntu TV team does not believe that it?s in the best interest of
maintainability and ease of implementing new complex backends to remain
using this current implementation. Instead, we are proposing to do a
complete rewrite of UMMS using C++11 and other modern libraries like
Boost and Qt. This should provide more compact and readable code, which
will be easier to add new features to in the future as well as fix
future bugs in the new rewritten codebase. It is also more
future-friendly in that embedded devices are increasingly using C++
instead of C for their application and lower subsystem codebases.


Elimination of Plugins
-------------------------------

The goal of having backends be plugins is a good one, however, the
Ubuntu TV team believes this can be accomplished while not having to
rely on a single-process plugin architecture. Instead, our proposal is
to change the backend design so that plugins become separate processes
that communicate with the media API via a message bus such as D-Bus.
There are several benefits to doing this:


1. Having each backend as a separate process will add to the overall
system stability. If one backend hangs or segfaults, it will not cause
the entire media subsystem to hang or segfault as well.
2. It still maintains the separation and versioning that was possible
with the plugin system. One can upgrade one or more backends
independently of upgrading the entire media API system.
3. It allows better task switching prioritization given that each
backend can individually have its priority tweaked and set to be
scheduled in real time.


Recording Functionality
---------------------------------

The last change to the UMMS design pertains to the recording
functionality. It seems to make more sense to separate the recording
functionality out into its own interface and backend. It does not make
sense to categorize recording functionality within the media player
interface. This creates a confusing and monolithic API. We propose the
removal of this functionality from the media player and into its own
interface and backend set. The new name for this set will be Recording
Manager. Its primary purpose will be as an interface to an accompanying
backend that will perform all recordings, manual or scheduled. However,
it will not include the scheduling or conflict resolution functionality.

Please see http://jimhodapp.com/UMMS_Media_API_Diagram.png for a
diagram that shows these changes.


Feedback
---------------

We would like to hear back from the UMMS community and discuss the pros
and cons to this proposal. We?d very much like to help the UMMS
community in its goal of becoming a standard media interface while at
the same time making sure that the Ubuntu TV team can solve its specific
media API needs.


Regards,

Jim Hodapp
- --
Senior Software Engineer
Ubuntu TV Team | www.ubuntu.com/tv
Canonical, Ltd.