[gst-devel] Continuing work on DVD (long)

[in7y118 at public.uni-hamburg.de]

random comments...

Quoting Martin Soto <soto at informatik.uni-kl.de>:

> I have a GStreamer based DVD player at home, with menu support and even
> remote control.
David and me came up half-jokingly with the idea to write a "lircnavfilter" 
that could be inserted into pipelines and would be identity except for sending 
nav events downstream.
You could even put that into non-remote enabled apps and have it work out of 
the box.
Your idea on that?

> Due to the general messiness, I'm not that motivated to make a serious
> release of this player.  The DXR3 elements are already in GStreamer, and
> the rest has to be rewritten.  Anyhow, if anyone has interest, I'll be
> glad to share the code.  Just let me know and I'll send you the files.
>
Stuff like this belongs into gst-sandbox. Judging by some of the code that is 
already in there, yours can't be worse. ;)
 
> 1. A dvdnavsrc element that writes everything to its single source pad. 
> Menu information, like color palettes and button highlight tables would
> have to be sent synchronously with the MPEG data.  There are two options
> here:
> 
>   - Use events.  I know many people don't like the idea of taking the
> event concept to this point, but it would work, and would use the
> current infrastructure.
> 
>   - Implement Benjamin's idea of having many "subchannels" in a stream
> (i. e. buffers have an integer whose value tells the type of content in
> them).  This looks cleaner, but I don't know how big the implementation
> effort is.
> 
You are going to use a custom caps for this, like application/x-dvd or 
application/x-gst-dvd? All that stuff is definitely not mpeg, so I'd dislike 
it being labeled as such.
I'm not sure what the right way to differentiate buffers would be. Suggestions 
like using the first byte in a buffer to describe the type of buffer (which 
would work with current infrastructure) seem hacky to me, too.

> 2. A demuxer.  Either we change the existing one, or make a new
> "dvddemux" or whatever.  It would need (at least) three output pads:
> video, audio and subpicture, and would automatically switch streams
> based on the incoming events/packets.  Changing between different types
> of audio, would imply caps renegotiation on the audio pad.
> 
If that works, I'd suggest subclassing mpegdemux. But I have no clue how that 
element works.

> 4. The audio thread needs to select different decoders based on the
> capabilities currently set for the demuxer audio pad.  An element is
> necessary, with one sink and many sources, that routes material to the
> appropriate source based on the caps set for the sink.  I already have a
> working implementation of such a thing.  I'd gladly upload it to
> GStreamer's CVS if I were given a change ;-)
> 
I'd prefer someone fixing the schedulers as the new autoplugger will 
definitely have to support this.
I guess I know who'll do that in the end. (and yes, I'll write a new one...)

Oh, and bug Thomas to create you a CVS account if you don't have one. I know 
that he knows how to create them. (It worked for Scott ;))


Benjamin