Hi again, On 25.03.2011 12:07, Stefan Kost wrote: > Hi, > > On 24.03.2011 23:57, Dominig Ar Foll wrote: <snip> > There is no architectural issue regarding blueray in the our stack. It > is more a legal mess. I belive given you have the time and money, you > could write blueray support to gstreamer in a similar fashion as we have > the dvd support now. >> 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. > That means you would like to have a bunch of different multimedia > frameworks on a device and then use an appropriate one depending on the > URI. E.g. use gstreamer for some formats and use mplayer for some > others. While that might sound like a good idea, I don't think it is one > for several reasons: > - you will needs to abstract the the different apis (well thats actually > your proposal) > - you increase size and complexity of the multimedia stack > - more difficult to debug (e.g. differnet tools needed) > - testing is a lot more difficult > - users might get annoyed by small incompatibilities (seeking works > differently depending on the media) > - you need to do base adaptation several times (integrate codecs, > rendering etc. in several frameworks) > > There might be more reasons that speak against such an approach, but > already the last one would be major enough for me. Can't resist, while speaking with a colleague he came up with a good metaphor for the above. Is there an idea car? No, there isn't. Thus instead of fixing the car to be what we want, we have a simpler solution - we take 3 cars, string the together, put an extra seat on the roof and proxy the controls. Then we can drive using the Fiat in the city, using the Porsche on the motorway and using the van when we need more space for transportation. Of course finding a parking space gets tricky ...
Stefan _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
