Re: Chapter marks not where specified.

Lawrence,

> > It may be that dvdauthor cannot place the markers as specified if
> > they do not align with VOBU boundaries in the input file, in which
> > case, it should, at the very least, warn that it has not been able to
> > comply with its instructions.
> 
> I can certainly add messages for this. Should they be “WARN” or “INFO”
> messages, do you think?

I would definitely prefer "WARN": it amounts to a failure to do what's asked, 
even though the output is still clearly playable. "INFO" seems altogether too, 
well, slight.

> 
> > On the other hand it may be that dvdauthor is intended to be capable
> > of adjusting VOBU boundaries when necessary, so as to align with
> > chapter markers, but fails, for reasons at present unknown, to do so,
> > in which case it should be fixed.
> 
> Hmm, maybe an option to ignore existing VOBU placeholders and use the
> already-added capability to generate its own?

So long as ignoring the incoming VOBUs, or rather the creation of new ones, is 
as easy as you seem to suggest, then this would be very handy indeed.  
However, as you already noticed, in at least my worst test case, ffmpeg 
produced 5 I-frames in 320 ms, and "one VOBU per I-frame" would create illegal 
VOBUs, so you'd sometimes have to pack them together, and you could still end 
up with a short VOBU, if a maximum length gop (or EOF) turns up immediately 
following the creation of VOBU of less than 400 ms.

I presume you already have to check that the maximum size of a group of 
pictures on the input isn't exceeded: you won't be wanting to manufacture your 
own I-frames :-)

I just did a quick search on the "ffmpeg force_key_frames" and found that the 
-force_key_frames option was added to ffmepg and mplayer last October, and the 
stated aim from Nicolas George, who wrote the patch was:

"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."

However, the change was not implemented as a feature of the encoder, but in 
the file converter.  The fact that the forced I-frames are not always seekable 
managed to get past the regression tests.

So it looks like you preemptively patched dvdauthor so it can work around a 
"feature" that had not yet been added to ffmpeg (and mplayer).  It's 
encouraging that the root cause for this lies, in my case, with ffmpeg, very 
definitely not with dvdauthor.

I think (hope) I may have found a major clue.  Here is a snippet from the .idx 
file generated by avidemux from my initial problem case, an mpeg generated by 
ffmpeg.

A 7900 cf6380e :10d7e20 
# Timestamp 00:05:16,000
V 693 007902 12 I:0cf6380e,000d8,09765 P:0cf6e80e,0020f,02e01 
P:0cf7180e,000aa,020ab P:0cf7400e,001bf,01af0 P:0cf7580e,00501,02ab8 
P:0cf7980e,00053,0278b P:0cf7c80e,00060,011e2 P:0cf7e00e,0027c,018b4 
P:0cf8000e,00382,01978 P:0cf8280e,0054c,01dbe P:0cf8500e,00374,01e3b 
P:0cf8700e,00219,01de9
A 7902 cf8b80e :10df431 
# Timestamp 00:05:16,002
V 694 007914 12 I:0cf8b80e,00000,09478 P:0cf9500e,00632,024d2 
P:0cf9800e,00386,02ba8 P:0cf9b00e,007b0,00a01 P:0cf9c00e,001eb,019b1 
P:0cf9e80e,003ee,03147 P:0cfa180e,005cf,027b9 P:0cfa480e,0060a,031e9 
P:0cfa900e,000a5,033f6 P:0cfac80e,00535,02f58 P:0cfb000e,00527,03534 
P:0cfb400e,0030d,031b3
A 7914 cfb900e :10e5a84 
# Timestamp 00:05:16,014
V 695 007926 12 I:0cfb900e,00000,092e4 P:0cfc280e,0049e,02973 
P:0cfc500e,00693,02c95 P:0cfc880e,003c2,01754 P:0cfca80e,00368,0233a 
P:0cfcd80e,0070c,01fdb P:0cfd000e,00751,01ae0 P:0cfd280e,0029b,0210f 
P:0cfd500e,00414,024b5 P:0cfd800e,0014b,024ec P:0cfda80e,006a1,02df6 
P:0cfde00e,00531,02a00

I'd specified a chapter marker at 05:16.08 and dvdauthor placed it at 
05:16.00.  Notice that *both* times are VOBU starts, but the VOBU starting at 
05:16.00 contains 12 frames (the gop size I specified).  But the VOBU starting 
at 05:16.08 starts, of course only 2 frames later and also contains 12 frames. 
 ffmpeg is certainly starting a new VOBU at the forced-key-frame times (which 
is good), but isn't bothering to truncate the VOBU that it is in the middle 
of, presumably for fear of leaving an illegally short VOBU.

It seems plausible that dvdauthor saw the first VOBU, noticed that the 
specified chapter time was a P-frame and, quite reasonably, set the marker 
back to the start of the VOBU.  When it saw the second VOBU, it had already 
dealt with that chapter marker and so was oblivious of the specified time's 
turning up in a VOBU-start I-frame.  The output from dvdauthor, as I suppose 
one should expect, is identical, so I presume the structure is legal: It 
certainly plays in a domestic player.

If my assumptions are correct, then there are two obvious approaches, which 
could be selected with some suitably named option..

The first is to be strict and not implement a chapter marker unless and until 
it is seen as a VOBU-start I-frame, issuing warnings for any that it cannot 
implement.  This would be my favourite.

The second is to be greedy: to be prepared (possibly for a limited duration) 
to move a chapter mark iff it appears later on in the sequence as a VOBU-start 
I_frame.  The greedy method would issue no warnings unless a specified chapter 
time were simply out-of-bounds.

Tom.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

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