[FFmpeg-devel] (no subject)

[wm4]

On Tue, 29 Jul 2014 10:45:43 +0200 (CEST)
Oliver Fromme <oliver at fromme.com> wrote:

> Carl Eugen Hoyos wrote:
>  > Oliver Fromme <oliver <at> fromme.com> writes:
>  > 
>  > > That's why I appreciate the patch very much
>  > > that Carl Eugen has created.
>  > 
>  > Did you test the patch?
>  > I think it will not get applied without a test.
> 
> Oh yes, I tested it, and it works!
> Sorry, I thought I'd already mentioned it.
> 
> I've used the same file for testing that I used
> when reporting the problem in the ffmpeg-users
> list.  With your patch, the following works:
> 
> $ OPTS="-vn -an -map "#0x21" -scodec dvdsub test-subs.mkv"
> $ ls -lh *.mpg
> -rw-r--r--  1 olli  wheel   5.5G Jul 27 17:14 dumpstream.mpg
> $ ffmpeg -analyzeduration 6000M -probesize 6000M -i dumpstream.mpg $OPTS
> 
> Input #0, mpeg, from 'dumpstream.mpg':
>   Duration: 01:37:01.70, start: 0.287267, bitrate: 8115 kb/s
>     Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv), 720x576 [SAR 64:45 DAR 16:9], max. 9800 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
>     Stream #0:1[0x80]: Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s
>     Stream #0:2[0x81]: Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s
>     Stream #0:3[0x20]: Subtitle: dvd_subtitle
>     Stream #0:4[0x21]: Subtitle: dvd_subtitle
> Output #0, matroska, to 'test-subs.mkv':
>   Metadata:
>     encoder         : Lavf55.50.100
>     Stream #0:0: Subtitle: dvd_subtitle (dvdsub)
>     Metadata:
>       encoder         : Lavc55.69.100 dvdsub
> Stream mapping:
>   Stream #0:4 -> #0:0 (dvd_subtitle (dvdsub) -> dvd_subtitle (dvdsub))
> Press [q] to stop, [?] for help
> size=       4kB time=00:00:17.56 bitrate=   2.1kbits/s    
> video:0kB audio:0kB subtitle:4kB other streams:0kB global headers:0kB muxing overhead: 21.333687%
> 
> The first subtitle packet of the stream #0x21 is at 0:55:54
> which is at an offset of about 3.4 GB into the file.
> 
> There's still the problem that the timestamps are wrong when
> I extract the subtitles only (no video, no audio), but that
> has nothing to do with your patch.  It's easy to work around
> by just extracting one audio track along with the subtitles,
> then discard the audio track if I don't need it.
> 
>  > [...]
>  > 
>  > > Maybe I'll try to make a patch that can do this
>  > 
>  > If you consider to invest time in DVD reading, 
>  > please work on the dvdnav patch:
>  > http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/104257/focus=140297
> 
> That thread seems to center on DVD playback with ffplay,
> including menu navigation.  I have to confess that that's
> not what I have in mind; I have never used ffplay, and I
> don't care about DVD menus.

I'd be interested in making it work with my player, though. So I can
purge most DVD-specific code from it. As I see it, there's a lot
of DVD (and also bluray) issues ffmpeg could abstract from, such as
rewriting timestamps properly, or dealing with that subtitle stream
crap.

In any case, these goals are not conflicting. There just needs to be a
way to enable/disable navigation.

ffmpeg's current bluray support is pretty laughable though. Not
useable to me in this form.

> My goal is to enable ffmpeg to be able read one title from
> a DVD and encode it.  The number of the title will be given
> on the command line, the default will be the longest title
> on the DVD.  As a side effect, I assume that ffplay will be
> able to play a title from a DVD in the same way.
> 
> Of course, if that's not what the ffmpeg project wants, I
> have no problem with that.  I can just as well continue to
> use separate tools for the job, and use ffmpeg only for the
> actual transcoding.
> 
> By the way, some (or maybe even most) of the statements in
> the post that you linked are wrong.  For example, the video
> system (PAL, NTSC) never changes within one title.  It can
> change from one VTS to another, but since you always encode
> by title, changes in video system don't have to be taken
> into account.  
> 
> I guess some of the wrong assumptions in the post come from
> the bad habit to encode VOB files directly, but trying to
> do that is a mistake and fails in many cases.  You *always*
> have to use the information from the IFO files in order to
> read a title properly, i.e. assemble the cells that belong
> to this title's PGC in the right order.
> 
> Best regards
>    Oliver
> 
>