Re: Chapter marks not where specified.

Lawrence,

> > What is not obvious is what, if anything, marks a VOBU start.
> 
> That’s this:
> 
> > 00000000: mpeg2 pack hdr, 0.460 sec
> > 0000000e: system header; length=18
> > 00000026: pes private2, PCI; length=980
> > 00000400: pes private2, DSI; length=1018
> 
> A VOBU is defined to start with a NAV PACK, which is a PACK containing
> a PCI and DSI packet. That’s it.
> 
> > What's also a bit curious is that times on the 'pes video 0; line
> > are always about a second ahead of the GOP time.
> 
> Looking at the GOP header description here
> <http://www.mpucoder.com/DVD/mpeghdrs.html>, that GOP time looks like a
> timecode, rather than the usual MPEG timestamp (integer units of a
> 90kHz clock). Presumably it’s there for editing purposes, not for
> playback purposes.
> 

After a little mind-sharpening sleep, I've thrown together a short clip of 5 
minutes and run it through ffmpeg with and without forced key frames every 31 
seconds or so.  The first was specified to be at 30.08 seconds.  Here is the 
result of running mpeg2desc on the "with" output from ffmpeg, reduced as far 
as I dare.  Clearly the I frame at 30.08 s is an I-frame., but does not start 
a new VOBU, only a 12-frame GOP.

00e13000: mpeg2 pack hdr, 30.280 sec
00e1300e: system header; length=18
00e13026: pes private2, PCI; length=980
00e13400: pes private2, DSI; length=1018
00e1382a: GOP: 0:00:30.00, open
00e13832: picture hdr, frametype=I, temporal=0
00e15217: picture hdr, frametype=P, temporal=1
00e15383: GOP: 0:00:30.02, open
00e1538b: picture hdr, frametype=I, temporal=0
00e17d62: picture hdr, frametype=P, temporal=1
00e19822: picture hdr, frametype=P, temporal=3
00e198d9: picture hdr, frametype=P, temporal=4
00e19986: picture hdr, frametype=P, temporal=4
00e19adc: picture hdr, frametype=P, temporal=5
00e19c32: picture hdr, frametype=P, temporal=6
00e19d88: picture hdr, frametype=P, temporal=7
00e19ede: picture hdr, frametype=P, temporal=8
00e1d048: picture hdr, frametype=P, temporal=9
00e1d1ac: picture hdr, frametype=P, temporal=10
00e1d302: picture hdr, frametype=P, temporal=11
00e1f800: mpeg2 pack hdr, 30.824 sec
00e1f80e: system header; length=18
00e1f826: pes private2, PCI; length=980
00e1fc00: pes private2, DSI; length=1018
00e20000: mpeg2 pack hdr, 30.825 sec
00e2000e: pes video 0; length=2028; hdr=14; pts 31.560 sec; dts 31.520 sec
00e20014: sequence hdr: 720x576, a/f:33, bitrate=20000
00e20020: sequence extension hdr
00e2002a: GOP: 0:00:30.14, open
00e20032: picture hdr, frametype=I, temporal=0

Here is the "without".

00e11800: mpeg2 pack hdr, 30.280 sec
00e1180e: system header; length=18
00e11826: pes private2, PCI; length=980
00e11c00: pes private2, DSI; length=1018
00e12000: mpeg2 pack hdr, 30.281 sec
00e1202a: GOP: 0:00:30.00, open
00e12032: picture hdr, frametype=I, temporal=0
00e13a17: picture hdr, frametype=P, temporal=1
00e13b6d: picture hdr, frametype=P, temporal=2
00e13cc3: picture hdr, frametype=P, temporal=3
00e13e19: picture hdr, frametype=P, temporal=4
00e13f6f: picture hdr, frametype=P, temporal=5
00e170e7: picture hdr, frametype=P, temporal=6
00e1723d: picture hdr, frametype=P, temporal=7
00e17393: picture hdr, frametype=P, temporal=8
00e174e9: picture hdr, frametype=P, temporal=9
00e1763f: picture hdr, frametype=P, temporal=10
00e17795: picture hdr, frametype=P, temporal=11
00e1c000: mpeg2 pack hdr, 30.760 sec
00e1c00e: system header; length=18
00e1c026: pes private2, PCI; length=980
00e1c400: pes private2, DSI; length=1018
00e1c82a: GOP: 0:00:30.12, open
00e1c832: picture hdr, frametype=I, temporal=0

Up to the VOBU at 30.0 seconds, the VOBU/GOP structures of the two files are 
identical, but the mpeg2desc is not.  This appears to be because the "with" 
file has, in some places, twice as many line pairs of the form

007a1000: mpeg2 pack hdr, 13.252 sec
007a100e: pes video 0; length=2028; hdr=4

as the "without", but that's an impression: it's certainly the reason for the 
first difference between the files.

Is this sufficient to demonstrate to the ffmpeg (and probably mplayer) 
developers what I believe is the case: that the '-force_key_frames' option in 
ffmpeg, while doing exactly what its name says it does, does not thereby 
fulfil the requirement stated in the rationale for its inclusion?

That rationale was, as written by Nicolas George, who wrote the patch:

"I want to use it to ensure that there is a seek point exactly at a place I
will probably want to jump precisely sometime, the major example would be
the end of an opening and beginning of the program proper. The scene change
detection system will often make it happen, but not always if there is a
fade-in."

As I understand it the thing pointed at by a chapter mark is a VOBU, not a 
frame, although the result is that play will start at the first I-frame of 
that VOBU.  Forcing I-frames is snot enough.

Tom.

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

_______________________________________________
Dvdauthor-users mailing list
Dvdauthor-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/dvdauthor-users