[gst-devel] dvdsrc status update, sundry questions

Tue Dec 12 13:03:22 CET 2006

On Fri, 2006-12-08 at 17:42 -0700, Jason Gerard DeRose wrote:
> Hello everyone,
Hi,
> 
> I wanted to give a quick status update on my dvdsrc(*) work, and also I
> have three questions.
> 
> dvdsrc is now a more or less a stable replacment for dvdreadsrc, aside
> from a few missing features (some which are missing in dvdreadsrc also),
> and, of course, more testing.
> 
> So now I'm ready to break it apart...
> 
> I've spent some time looking through the dvdnavsrc code and have decided
> it really makes sense to combine the functionality of dvdreadsrc and
> dvdnavsrc. There is a lot of duplicated code between the two. If enough
> developers feel that this is a bad idea, I will implement dvdnavsrc as a
> sub class of dvdsrc (or perhaps have both derive from a common class).
> But I personally think the single element approach is much better.
> 
> Regardless, I'm all fired up to get full DVD support into 0.10. My plan
> is to add Nav support to dvdsrc, as a replacement for both dvdreadsrc
> and dvdnavsrc, and to fix or rewrite dvdsubdec (which currently appears
> pretty broken).
Excellent.
> 
> 
> And now on with the questions:
> 
> 1) Decodebin2 best practices?
> 
> This is mostly a question for Edward Hervey. I haven't dug into
> decodebin2 yet, but I just wanted to ask, are there any quick pointers
> you have on how I should best utilize decodebin2, ideas about where
> you'd like to see GStreamer heading architecturally when it comes to
> auto-plugging something like a DVD (on the source element side)?

For DVD I would not bother with autoplugging just yet. I was mostly
thinking of an element that handles dvd:// uris and produces an audio
and video path and does all the linking and stream switch internally. I
say this because the subtitle mixing in DVD is a little special and can
be more efficiently implemented with a specific pipeline (see below).

> 
> As my new element has a different name, keep exact compatibility with
> dvdreadsrc/dvdnavsrc isn't important. So if, say, new custom downstream
> events are needed, I'd gladly implement them, and add any new
> functionality that dvddemux might need.

> I want to get any feedback I can from people working on the downstream
> elements so I can make sure I'm heading in roughly the correct
> direction. I mean rewriting code is fun, but... ;)
> 

I think the current events are in the right direction last time I looked
at them. For all this, it would be nice to have like an overview of how
a pipeline would look and what events are produced by the dvdsrc. This
way we can keep various demuxer implementations in sync along with other
dvdsrc implementations.

> 
> 2) DVD 'table-of-contents' signal?
> 
> Part of the problem I'm having performance wise with KungFu(**) and
> dvdreadsrc is quickly getting at least the number of titles on a DVD,
> and the duration of each title, so I can decide which titles to
> thumbnail.
> 
> For each title, I must drop to STATE_READY, set the title, go back up to
> STATE_PASED, and then query the duration. But dvdreadsrc is doing way
> more work than it needs to get just this information. I'd really like
> some kind of table-of-contents signal to quickly pass this information
> to the application.
My current thinking is that the DVD pipeline has a few element messages
it should emit:
 GstDVDAngle: a new set of angles becomes available
 GstDVDToc:   a new table of contents is available.
 .. 
possibly some message to inform the app that an interaction is to be
done with the user (like entry of code to unlock content,...) Again, an
overview of what is possible in the DVD VM and a suggestion of how to
handle it would be a good way to get this moving forwards.

In general signals are not recommended, use GstMessage instead.
Interfaces and objects that require an app to link to some library can
be acceptable too but should not be required to use the element in a
usefull way. (for example, language or angle switching can usually be
done in the DVD menu or in stream with navigation events although an
interface could make it possible to switch at any time). 

> 
> It seems that Tim Müller got around this problem in Thoggen by using
> libdvdread directly, but KungFu is written in Python, so this isn't an
> option. And it would be nice if all this could be accomplished through
> the normal GStreamer API, so that anyone else who wants, say, to write a
> DVD ripper, has this functionality available.
> 
> I haven't played with cdparanoia/cdiocddasrc much under 0.10, but in 0.8
> the only way I knew to get the number of tracks and the duration of each
> track was to do a series of segment seeks and duration queries. It would
> be nice if these elements also had a similar table-of-contents signal
> (or a table-of-contents event on the bus).
> 
Yeah, this is the complicated way to do this. cdparanoiasrc currently
post a message with discid, trackcount etc. We have no good way of
letting an application know about an hierarchical TOC, let alone seek to
some entry in that TOC. 

> Anyone have any ideas on this?
> 
> 
> 3) Is 'videomixer' suitable for overlaying the decoded subtitles? Once I
> have dvdsubdec working again, is 'videomixer' what should be used?

For DVD I would create a subtitle mixer that takes video on one pad and
the encoded subpicture on another pad. The element is purely chain
based, for each video picture received it blends (while unpacking) the
current subtitle on top of it (with matching timestamps, of course).
When you connect the demuxers subtitle pad directly to the subtitle
decoder/mixer and the raw video path of the video decoder to the mixer
video path, you will get the subpicture before the video frames it
applies to. You can insert an order-preserving queue (like decodebin2
does) to make sure none of the video/subtitle streams run ahead of
eachother (multiqueue).

Hope this helps some of the questions. 

Wim
> 
> 
> ANYWAY...
> 
> In general, if anyone has any advice on any of this, I'm all ears.
> Thanks!
> 
> Cheers,
> Jason
> 
> 
> * I'm currently keeping my dvdsrc code is a Bazaar repository:
> https://launchpad.net/people/jderose/+branch/kungfu/dvdsrc
> 
> ** KungFu is a gst-python based DVD ripper
> https://launchpad.net/products/kungfu
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
-- 
Wim Taymans <wim at fluendo.com>