Hi Dominig,
On 16.03.2011 11:08, ext Dominig ar Foll wrote: > Hello, > > As many of you may not follow the TV mailing list. I post you an information > about a proposal which might also present interest outside of the TV world. > > when you start to play video on Linux you realise quickly that no > solution can cover the full need of playing video for a real full TV > application. If you try to create a Consumer Electronic (CE) device, you > likely use a System on Chip (SoC) which provides a concept of video > overlay which provide a great help on performance but make any > integration very specific. > > The propose specification has been written for TV but cold be valuable > to any device which either wants to be fully compliant with TV > requirement when playing videos or use SoC with hardware acceleration. > > The proposed specification aims at creating a generic service for Linux > (I will start by MeeGo TV) which could unify the play out of a video and > make transparent the support of various hardware helper provider by some > chip and in particular the support of overlay video common on SoC. > > Thanks to let me know your feedback, preferably on the MeeGo TV mailing > list.. > > File can be found here : > http://wiki.meego.com/File:Meego_Unified_MultiMedia_Service_V0.4.odt Regarding the already existing projects. Are you aware of MAFW on Maemo5 http://www.grancanariadesktopsummit.org/node/219 The implementation might not be perfect, but the concept behind is sane. The picture in "6 Position in MeeGo" looks quite arbitrary to me. Do the colors have a special semantics (meybe add a small leged below). In "7 Transparency" you need to highlight what your proposal adds to the existing features. * Transport protocol: handled e.g. by gstreamer already, standarts like DLNA specify subsets for interoperability already * Transparent Encapsulation and Multiplexing: could you please elaborate why one would need the non-automatic mode. I think it does not make sense to let the application specify what format the stream is in, if the media-framework can figure it (in almost all of the cases). In some corner cases one can e.g. use custom pipelines and specify the format (e.g. a ringtone playback service might do that if it knows the format already). * Transparent Target: Whats the role of the UMMS here? How does the URI make sense here. Are you suggesting to use something like opengl://localdisplay/0/0/854/480? MAFW was introducing renderers, where a local renderer would render well locally and one could e.g. have a UPnP DLNA renderer or a media recorder. * Transparent Resource Management: That makes a lot of sense and so far was planned to be done on QT MultimediaKit * Attended and Non Attended execution: This sounds like having a media recording service in the platform. "8 Audio Video Control" This is a media player interface. Most of the things make sense. Below those that might need more thinking * Codec Selection: please don't. This is something that we need to solve below and not push to the application or even to the user. * Buffer Strategy: same as before. Buffering strategy depends on the use-case and media. The application needs to express whether its a media-player/media-editor/.. and from that we need to derive this. "9 Restricted Access Mode" Most of those are needed as platform wide services. E.g. Parental Control would also be needed for Internet access. "11 Developer and Linux friendly" * Backwards compatible ...: My suggestion is to take inspiration in existing components, but only do any emulation if someone really needs that. It is usually possible to some extend, but whats the point? * Device and Domain independence: Again, how does UMMS improve the situation here? "12 Typical use cases" I think it would be helpful to have before and after stories here to highlight the benefits of your concept. "13 D-Bus" Be careful with generic statements like "D-Bus can be a bit slow ...". Stick with facts and avoid myths. "14 QT-Multimedia" Seriously, don't even consider to stack it on top of qt-multimedia. We're still embedded. You could propose to implement it as part of QT multimedia though (or having it at the same level). "15 GStreamer" It is GStreamer (with a upper case 'S') :) In general please spell check the section. Regarding the three weak points: * smooth fast forward is a seek_event with a rate>1.0. There might be elements not properly implementing that, but I fail to understand how you can fix that on higher layers instead of in the elements. It might make sense to define extended compliance criteria for base adaptation vendors to ensure consistent behavior and features. * DRM can be implemented outside of GStreamer. still I don't fully understand what the issue here might be. * Push/pull: gstreamer is a library. you can do lots of things with it. If you want to use it to broadcast media you can do that very well. Some known examples: rygel (upnp media server), gst-rtsp-server. Just to clarify on the terminology - media processing within the graph is also using push and pull, but that refers to whether one component pushes media to downstream or one component pulls data from upstream. E.g. in media playback of local files GStreamer uses a hybrid setup. * Licenses and Patents: Seriously, this is hardly the fault of GStreamer and its plugin approach is the best solution for it. In the end every vendor shipping a meego solution will need to ensure that the royalties for codecs are payed and the shipped code is fully licensed. Besides a system like MAFW already allowed to e.g. implement a local renderer using mplayer as a foundation if that is preferred. Personally thats fine to me, but I believe the target customer for a TV will except that things work out of the box :) Sorry, this became a somewhat long reply Stefan > -- Dominig ar Foll MeeGo TV Open Source Technology Centre Intel SSG > > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
