[gst-devel] Potential replacement for dvdreadsrc

[Christian F.K. Schaller]

On Fri, 2006-11-24 at 20:26 -0700, Jason Gerard DeRose wrote:
> Hello,
> 
> I've been working on a potential replacement for the dvdreadsrc element
> and want to get some advice on where to go from here.  This all started
> as my work on seek related bug (1), but the more I worked on dvdreadsrc,
> the more I wanted to rewrite it from scratch, especially to address what
> I felt were some readability problems in dvdreadsrc.  I've been calling
> my element "dvdsrc".
> 
> So, on with my questions:
> 
> Question 1:
> Is my copyright notice (2) correct?  I started my element using
> gst-template.

Sorta/Probably. If your new dvdreadsrc is a full rewrite you shouldn't
list the original dvdreadsrc developers in the copyright. If your
version is modification on the other hand that is 100% correct. Also you
don't need to include the copyright header of the authors from
gst-template, gst-template is meant to be taken by anyone to use for
anything and I think the consensus have always been that the template
code should be considered either to unexpressive to be copyrightable or
as a fallback public domain. The license header in there is meant as a
template too, not as a actual license.


> Question 3:
> After further testing and development, can my element be included in
> gst-plugins-ugly in the 0.10 series?  I would like to see playbin use my
> element over dvdreadsrc.  However, dvdreadsrc should remain for backward
> compatibility as there is one respect in which my dvdsrc element is not
> a drop in replacement: it does not allow seeking or querying in the
> sector or bytes formats.  The manner in which dvdreadsrc implemented
> this was very broken for a significant percentage of DVDs.  It is
> difficult to implement correctly and moreover, as both dvdreadsrc and
> dvdsrc currently operate only in push mode, is unused by most
> applications, including anything playbin-based.  So I left it out of my
> dvdsrc, but feedback is welcomed on this decision.

Yes, this should be ok. Tim-Phillip Muller is probably the best person
to give a final answer (and even integrate the new code in CVS), but he
is away on vacation this week.

> Question 4:
> To push or to pull?  Seeing the discussion about JACK makes me wonder:
> in the future of GStreamer, are pull sources preferred?  Is it worth the
> complexity and effort to implement dvdsrc as a pull source?
You should keep it push based. Most GStreamer devs, including Wim who is
GStreamer lead designer, do not think making something like a dvdsrc
element pull based makes much sense.

> Question 5:
> Should there be separate dvdnavsrc-like and dvdreadsrc-like elements, or
> should there be a single element that does both?  I originally set out
> to rewrite dvdreadsrc as that is what I need for KungFu, my DVD ripper.
>  But as long as this stuff is fresh in my head, I'd like to help enable
> full DVD support for gst0.10.  What is the current status of dvdnavsrc?
>  Where would my efforts best be directed if I wanted to work on this?
> Should I work on adding Nav support to my element, for a future
> all-in-one DVD-src element?
I don't know. Hopefully somone else chimes in on this. Tim again is the person 
who have worked towards DVD support in Totem. Edward Hervey has been
working on a new Decodebin element better tuned to handling DVD's in the
sense that it can deal with changing audio and video streams.

> Question 6:
> What are some tricky multi-angle DVDs that I should test?  My dvdsrc
> element currently does *not* support multi-angle DVDs as I don't own any
> to test, so if anyone has any suggestions... ;)
They are almost non-existant. The only multi-angle I know about is the first Matrix 
DVD where that shooting scene on the roof where he dodges in slow motion
is available in two angles.

Anyway, good stuff so far and thanks for taking an interest in helping
with DVD support. I know Tim has been wanting some help with that for a
long time.

Christian