GStreamer: Past, present, and future [LWN.net]

GStreamer: Past, present, and future

Posted Oct 27, 2010 13:20 UTC (Wed) by jackb (subscriber, #41909)
In reply to: GStreamer: Past, present, and future by alankila
Parent article: GStreamer: Past, present, and future

"In short, I think this media framework is not quite the success story it is portrayed to be, IME."

None of them are.

I haven't found one single framework that will successfully play every video file I have on my hard drive.

It takes a combination of an mplayer, xine and totem (gstreamer) to watch them all.

(Log in to post comments)

GStreamer: Past, present, and future

Posted Oct 27, 2010 21:12 UTC (Wed) by wahern (subscriber, #37304) [Link]

It's because none of the frameworks have the proper design. Most of them shoe-horn plugins into a particular producer-consumer model on the premise that it makes them easier to write, but ultimately it just results in balkanization of efforts.

The very low-level codec implementations--LAME, mpg123, FAAC, FAAD, etc--all share almost identical APIs, even though there was zero cooperation. Given the evident success of that API scheme, why do all these other frameworks depart from that precedent? They try to bake in all sorts of bells and whistles long before the best API for doing so becomes evident, and the end result is crappy performance and nightmarish interfaces.

FFmpeg comes the closest to a good API, and it lies at the heart of many "frameworks", but it has several defects and shortcomings, such as enforcing a threaded pull scheme, and not providing a simple tagged data format which would aid in timing and synchronization. (For my projects I repurpose RTP for this purpose, because IMO it's more valuable to define an interface at the data level than at the function level.)

GStreamer: Past, present, and future

Posted Oct 29, 2010 13:19 UTC (Fri) by wookey (subscriber, #5501) [Link]

Right. I have never understood why each different media player supports a different subset of stuff. As a naive geek who knows very little about multimedia it seems to me that once I have libx264 and libogg and libquicktime installed then every media player I have should be able to support those formats. But clearly that's not the case and there must be something else going on. Do I understand from what you say that VLC, mplayer totem etc don't actually use the same codec libraries but each implement their own? But if that's true what _does_ use these libraries (I see them on my system).

There seem to be complex interactions between players, lower-level media frameworks and individual codec libraries that I clearly don't understand. Can someone explain (or point to docs that explain)?

GStreamer: Past, present, and future

Posted Oct 29, 2010 22:21 UTC (Fri) by Uraeus (subscriber, #33755) [Link]

I assume that when you say stuff you mean media files. Well the reason is that a media file is a collection of things. For instance most media frameworks and players do their own demuxers (as using library versions makes things like trick modes hard to do) and the demuxer is more often than the decoder the one which has to battle with weird files. The second differentation factor is crash policy. The more broken files your player tries to play, the easier it is for said player to encounter something that makes it crash. This is a security risk. So as a player developer one are made to make a decision on how strict to be with more strict meaning less crashes but also less files being playable.