[gst-devel] Now starting musepack plugin, seeking advice

[Benjamin Otte]

Quoting "Gustavo J. A. M. Carneiro" <gjc at inescporto.pt>:

>   Hello,
>   I've started to write a musepack (http://www.musepack.net) decoder
> plugin for gstreamer.
>   Unfortunately, the musepack library does not fit very well into
> standard GstElement model.  You have a chain() function, which receives
> a data buffer, pushes a data buffer into the decoder, then pushes the
> resulting buffer to the next element.
>   In musepack, you have to implement a "reader" class, and musepack
> pulls data from reader.  That is the reverse of what the chain function
> does.
>   I'm thinking I don't have any choice but to run the decoder in a
> subthread, but if anyone has a better idea I'm all ears! :-)
>   Regards.
>
FWIW and for anyone interested, 2 comments on this:

1) GStreamer 0.8 supports loopbased elements that were created for exactly this 
purpose. See the avi demuxer, the modplug decoder or similar for examples. I'm 
not sure 0.10 will support those without threads though as I want a non-
blocking scheduling model so I can view video without the need for at least 3 
different threads.

2) Loopbased elements - or for that matter the musepack library or the 
vorbiosfile library - are a broken concept, because the loopbased element is 
basically the scheduler of the application. What this means is that the decoder 
library decides when to read more data and does so in a blocking mode. (I don't 
think musepack or vorbisfile allow returning -EAGAIN from a read operation and 
handling this in a sane way, or do they?) If you follow this model and read 
data from a network device, you'll end up with a blocking read from a network 
device, which could potentially block the whole processing thread, which 
certainly isn't nice. 
I've seen this behaviour a lot from multimedia libraries, especially those that 
were designed for file playback and got "virtual files" tagged on later. I 
could come up with quite a bit more: mikmod, dirac, audiofile, ... And there 
are lots of working examples of how easy it is to design a working 
implementation that does not suffer from this: mad, faad, even ffmpeg gets this 
right, and ffmpeg supports a huge lot of formats.

So, whenever you see/are involved with some promising new media lib in the 
future, that does this "virtual file" approach, please get them to see the 
light, before people start complaining the API sucks.


Benjamin

PS: It gets especially weird when you get 2 such decoders pulling data from a 
demuxer. How do you want to code the demuxer?