On Mon, 28 Jul 2014 17:21:34 +0200 Nicolas George <geo...@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, > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel