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

[Martin Soto]

Hello Ronald!

On Fri, 2004-01-30 at 10:00, Ronald S. Bultje wrote:
> Cool to see you'll be back actively working on all this!

Yeah, I'm glad to have some time for this again.

> On Wed, 2004-01-28 at 22:58, Martin Soto wrote:
> > 1. A dvdnavsrc element that writes everything to its single source pad. 
...
> >   - Use events.  I know many people don't like the idea of taking the
...
> >   - Implement Benjamin's idea of having many "subchannels" in a stream
...
> I like the events. dvdnavsrc and mpegdemux (or an element derived from
> mpegdemux: dvddemux) could share a private event that's sent between
> them. dvddemux/mpegdemux would then use that to set a new caps with
> corresponding colour tables on whatever element needs those, or forward
> the event to other elements needing it (then, you'd want to make it a
> public event...). Or decoder, mpeg2subt, I don't really know that part
> of "where are colourtables needed and where not"...
> 
> I don't really like the subchannels idea, I feel it gets far too
> complicated. I'd prefer to do this simple.

The channels wouldn't necessary be that complicated, but I agree that
the events are enough in this case, since we are sending small bits of
information.  

The question is, how do I go implementing this stuff?  Is there any
example of private events being used in gst-plugins?  Additionally, in
order to communicate with the actual subpicture decoder, I'd rather 
forward the events, since the capabilities don't actually fit the bill
(color tables keep changing in DVDs, specially when moving out from and
into menus).  Should I simply add some new event types to GstEvent, or
define a new class (GstDVDEvent) somewhere, for interested elements to
share?

It is important that we define and document this protocol, because many
elements are going to share it.  By the way, Jan, it'd be great to hear
from you regarding this ideas.

> > 2. A demuxer.  Either we change the existing one, or make a new
...
> Please, use mpegdemux. If you need specific DVD hacks, go ahead and make
> a dvddemux, but make sure it is properly derived from mpegdemux so you
> don't do any code duplication.

Agreed.  As already stated in my answer to Benjamin, my plan is to clean
up mpegdemux somewhat, and derive a dvddemux from it.

> Ronald

Thanks for the feedback.

Cheers,

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