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

Quote: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?package=UMMS&project=devel%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?package=umms-plugins-netbook&project=home%3Azwu28%3Abranches%3Adevel%3Atv%3A1.2


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

Quote: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

Quote: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 | http://www.ubuntu.com/tv
Canonical, Ltd.