[FFmpeg-devel] [RFC]Add int64_t probesize2 to AVFormatContext

[wm4]

On Mon, 28 Jul 2014 17:21:34 +0200
Nicolas George <george at nsup.org> wrote:

> Le decadi 10 thermidor, an CCXXII, Oliver Fromme a écrit :
> > Ah!  Thank you very much for pointing me to the concat demuxer.
> > I wasn't aware that it can be (ab)used to declare the presence
> > of streams in an input file.  I will definitely give that a try.
> 
> Please let me know of any issue.
> 
> > Well, my own tool can do all of that ...  The problem is, it
> > is written in Python, and I'm somewhat reluctant to touch Perl
> > scripts.
> 
> If it is written using only basic python structures, I can probably easily
> translate it to perl. The information I need (apart from the default/longest
> title) is, for the selected title:
> 
> - the type and ID of each stream;
> 
> - the offset and duration of each cell.
> 
> > Thinking about it, I'd rather rewrite it in C.  Maybe the
> > functionality can be added to ffmpeg as another demuxer, like
> > "-f dvd -dvd_title 3 -i <path> ..."  The question is whether
> > this would be better than using libdvd.  I've never used libdvd
> > before, so I can't tell for sure.  FWIW, the mplayer team
> > decided to use their own code instead of depending on libdvd.
> 
> IIRC, MPlayer uses libdvdread, just an internal fork because of old
> problems.

There's still stream_dvd.c, which consists tons of eyecancer code to
deal with libdvdread. (I don't know how this code was created, but I
suspect libdvdnav was created from it later.)

One issue is that the mplayer code actually uses the seek tables, while
libdvdnav does not.

> Using libdvdread would be beneficial to read encrypted DVDs directly. Using
> libdvdnav would also work with obfuscated DVDs. But they are probably harder
> to integrate into ffmpeg.
> 
> Regards,
>