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

[Martin Soto]

Hi Benjamin!

On Thu, 2004-01-29 at 19:10, in7y118 at public.uni-hamburg.de wrote:
> 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?

Sounds great.  Since my hacked dvdnavsrc doesn't do nav events, I'm
using the application itself for the remote stuff.  But a lirc nav
element would allow for nicer integration.  I may try my hand at that,
provided no one does it before I get there (I'm giving priority to the
other components of course).

> > 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. ;)

Hehe.  I'll think of uploading portions of that as soon as I (if I ever
;-) get CVS access.

> 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.

Definitely.  I don't either like calling that stuff MPEG.

> > 2. A demuxer.  Either we change the existing one, or make a new
...
> If that works, I'd suggest subclassing mpegdemux. But I have no clue how that 
> element works.

Yeah.  I was checking the code once again yesterday, and my idea is to
clean up the mpegdemux somewhat, and then derive a dvddemux from it.  I
plan to try and remove all DVD specific bits from mpegdemux and move
them to dvddemux.  For example, mpegdemux would deliver raw packets for
the private streams, whereas dvddemux would parse them and deliver the
right sound, subpicture and control data channels.

Opinions on that? 

> > 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...)

Well, the schedulers have to be fixed.  By the way, it would be nice to
discuss the scheduling algorithms here "in the open", before
implementing them.  A big problem I see is that it is not really clear
what basic behavior should be expected from a scheduler.  IMO,
schedulers could differ in things like performance for different
applications, but their behavior in terms of how buffers are routed and
processed should always be predictable.  This doesn't seem to be the
case now.

On the other hand, the problem I'm tackling with my new element is not
just the deficiencies in the current schedulers.  The fact is that you
have pads that change their capabilities on the fly (for example from
48Khz PCM sound to AC3 when going from a menu to the main film) and
someone has to react and route the buffers to the corresponding
decoders.  That's what my new element does.  There's probably a way (I
don't have the GStreamer sources available here) to do that from the
application side, but the element that selects its output pad based on
the caps of the attached elements looks like a cleaner solution to me. 
Am I missing something?

> 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 ;))

Thomas, are you there?  Actually I have some patches for the DXR3
elements (real sync based on the new clock system) that I'd like to
commit.  Of course I can create a patch and put in bugzilla, but I'm
lazy...

> Benjamin

Thanks for your comments,

M. S.
-- 
Martin Soto <soto at informatik.uni-kl.de>
Universität Kaiserslautern