[Meego-tv] [MeeGo-dev] Candidate specification for a generic video player from the TV list
Dominig Ar Foll
dominig.arfoll at fridu.net
Thu Mar 24 14:57:54 PDT 2011
Apologies for responding in dual posting. I would like as much as possible
to concentrate that type of chat on the TV mailing list but I would not
enjoy to leave a question open.
Regarding the already existing projects. Are you aware of MAFW on Maemo5
> The implementation might not be perfect, but the concept behind is sane.
No I did not know it and I think you for the link. I have so far only
written a requirement specification and any idea to move toward a goo
implementation specifications are welcomed. I will dig in their
> 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).
No the colour are just imported from a slide and where just there to help to
identify the blocks. The main idea of that graph is to make very clear that
the proposed concept does not pan to create a universal audio/video pipeline
but has the goal to be able to integrate multiple video pipeline under a
unified umbrella. In particular it aims at enabling to get non open source
pipeline to coexist with public pipelines.
> In "7 Transparency" you need to highlight what your proposal adds to the
> existing features.
The chapter 7) "Transparency" regroup the need to provide certain type of
services in a transparent manner to the the application. My goal is to
enable applications to play multimedia content which knowing much about that
content. e.g. if you write an application which need to access a live TV
service but you live in US, you will have different pipeline once that same
application is run in Europe.The requirement of transparency is applied to
the typeof source and target. In a very similar manner as when you print on
Linux today. Your application knowns very little about the printer but still
* Transport protocol: handled e.g. by gstreamer already, standarts like
> DLNA specify subsets for interoperability already
I am afraid that GStreamer cannot do today everything that I would love it
to do. It does pretty well on most of internet format but Playbin2 has a
very limited set of supported services when it come to Broadcast or IPTV.
Furthermore by default it does not support any smoth streaming feature or
But I agree that GStreamer is a great tool and I would certainly see it as
one of the strong candidate to implement the first open source audio video
pipe line under a UMMS framework.
> * 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
Multimedia asset comes in multiple mode of transport and multiplexing (from
HTTP to Live DVB) in MPEG2-TS, mp4, quick time or Flash. The automatic
detection is sometime possible and some time not. Futhermore some video
pipeline can do many format well while still some other format will impose
an alternative pipeline (Bluray is a good example).
The idea presented here is that the UMMS can decide which pipe line to call
on depending of URL or the detected stream type without requiring a prior
knowledge from the application about the pipeline configuration/selection.
> * 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.
Once again here the goal is to decouple the application from the prior
knowledge requirement of the videopipe line. I am proposing to add to the
traditional target to play video of an xvid not only openGL texture, but
also DLA target and video in overlay. The later is a speciality of SoC but
is mandatory when it come to run HD video on low energy system or to respect
tight security requirement.
> * Transparent Resource Management: That makes a lot of sense and so far
> was planned to be done on QT MultimediaKit
Yes. It make sense and on SoC it's even more critical.
> * Attended and Non Attended execution: This sounds like having a media
> recording service in the platform.
Yes that exactly what it is.
> "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.
In general I do agree but sometime you need to specify. In particular when
you have multiple streams in the same multiplex (e.g. Dolby 7.1 and simple
> * 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.
I would have agreed with you before doing a real deployment of the
Cubovision system in Telecom Italia. When you do HD video on the internet,
they are a few things that you have to live with. Buffer strategy is one of
these. But as you noticed I proposed by default to just proposed classes.
> "9 Restricted Access Mode"
> Most of those are needed as platform wide services. E.g. Parental
> Control would also be needed for Internet access.
Don't disagree with you, but my job is TV :-) If the same concept can be
reuse, that's nice. But I do not know tight regulation impose on parental
control on Internet while on TV devices it' a mandatory requirement in many
> "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?
MeeGo people which are developing application today with QT should have
their effort protected. The UMMS because it designed to support TV
requirement goes further than existing multimedia framework and so providing
compatibility to existing applications is a simple way to be accepted.
> * Device and Domain independence: Again, how does UMMS improve the
> situation here?
On TV our pixel are rectangular while on other devices they are scare. We
also have a zone (call safe zone) where we can not display anything. It's
very safe indeed. I do not want application to have to get that knowledge of
the domain (TV or non TV).
On the device side, embedded SoC and PC are treating video and graphics very
differently, Once again I want to hide that complexity to the application.
> "12 Typical use cases"
> I think it would be helpful to have before and after stories here to
> highlight the benefits of your concept.
Good hint for a further release.
> "13 D-Bus"
> Be careful with generic statements like "D-Bus can be a bit slow ...".
> Stick with facts and avoid myths.
Correct. Number only count. The Cubovision system delivered to Telecom
Italia is using D-Bus and performance has never been an issue but there is
a perception that it might be slow. Before deciding for a final technology
real measurement will be required.
> "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).
I would do a lot to keep existing application running. But if that is not
required, will be happy to ditch it.
> "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.
I do not plan to correct that at higher level, I just want to point that
GStreamer which is used by default in MeeGo has weaknesses.
> * DRM can be implemented outside of GStreamer. still I don't fully
> understand what the issue here might be.
DRM and CA in General as a nightmare and cannot be always decoupled from the
videopipe line. GStreamer is fairly friendly to DRM and CA but some
requirement will impose dedicated video pipe line (e.g. Bluray)
> * 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.
Currently GStreamer needs improvement to support pushed transport. A good
example is Broadcast Live TV where the clock needs to be synchronised on the
satellite source if you do not want to jump a frame once in a while. Nothing
impossible, but not something which works out of the box today.
> * 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.
Yes. But not easy in a full open source environment.
> 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 :)
Providing a full TV experience imposes quite a number of extra requirements
which are definitively not covered by any Open source system today. I hope
that by defining something generic, other MeeGo vertical (in particular
Tablet and IVI) would have access to a better support of live TV in their
domain. For them is optional and nice to have, for TV there is no chose,
it's a mandatory requirement.
> Sorry, this became a somewhat long reply
Dominig ar Foll
Intel Open Source Technology Centre
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MeeGo-tv