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

[Martin S. <so...@in...>]

Hi all!

In the last days, I'm once again getting up to speed in DVD development
for GStreamer.  Let me try to summarize the current state of things:

The (Recent) Past
=================

I have a GStreamer based DVD player at home, with menu support and even
remote control.  I use it regularly now to play movies in my home
theater, through a DXR3 card.  It is pretty robust, and is capable of
good audio/video sync without using a lot of processor power, so it kind
of works for my purposes.

The whole program, however, is an ugly hack.  I'm using a heavily hacked
version of dvdnavsrc which uses signals for reporting such things as
channel and subpicture palette changes.  This doesn't really work, in
fact.  The signals are fired before the corresponding buffers have had
time to reach the MPEG demuxer, and the application ends connecting to a
new pad in mpegdemux before all buffers are through.  The result is
menus that randomly display wrongly and all sorts of other weird stuff. 

An additional problem is that, depending on the type of audio (AC3, PCM,
DTS, mpeg) that is currently playing, you need to activate different
decoder elements.  As far as I've seen, the current schedulers don't
like having around unlinked or partially linked elements, so you have to
do all sort of funny tricks to keep the pipeline working every time
audio changes.

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.

The (Near) Future
=================

In the last weeks, I've been working on a new approach, that, first,
should do the job, and, second, seems to be compatible with what people
have been discussing here recently.  Basically, the idea is to have a
pipeline that doesn't need reconnecting pads at all.  That means that
you have to modify some of the existing elements, and add a few new ones
that act as intelligent "pipe joints".

The pipeline would look as follows:

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.

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.

3. Two separate threads with appropriately long queues would connect to
each one of the three demuxer pads.  One thread handles audio, the other
handles video and subpicture.

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

5. The video/subpicture thread needs to handle an important portion of
the user interaction.  A good software subpicture decoder is necessary,
but I don't really know the status of the existing one.  Personally, I
would rather concentrate on the DXR3 stuff, and collaborate with others
(Jan?) to improve the software implementation in a compatible way, so
that we can simply switch components to go from software to hardware
decoding.

My plan now is to start working on the demuxer.  I know the code
relatively well, so it shouldn't take that long.  Please tell me if
someone else is working on that part, or if there are considerations
that I must take into account. 

Of course, comments, suggestions and constructive criticism will be
greatly appreciated.

Cheers,

M. S.
-- 
Martin Soto <so...@in...>