[FFmpeg-devel] Problem with DVD VOB encoding - NAV packets not included properly.

[Michael Niedermayer]

Hi

On Sun, Jul 15, 2007 at 03:26:35PM +0200, V?ctor Paesa wrote:
> Hi,
> 
> Michael Niedermayer dijo:
> > Hi
> >
> > On Sun, Jul 15, 2007 at 10:39:07AM +0200, V?ctor Paesa wrote:
> >> Hi,
> >>
> >> V?ctor Paesa said:
> >> > Hi,
> >> >
> >> > Michael Niedermayer said:
> >> >> Hi
> >> >>
> >> >> On Sun, Jul 15, 2007 at 04:09:49PM +1000, Neil Brown wrote:
> >> >>>
> >> >>> Hi,
> >> >>>  I've been working with kdenlive (which uses the MLT framework
> >> which
> >> >>> uses the ffmpeg libraries) to make a DVD and found that the VOB
> >> created does not have the correct NAV packets.
> >> >>>  This shows up when I run dvdauthor as it cannot find places to
> >> put
> >> >>> chapter links, and when viewing the DVD on a DVD player as
> >> >>>  fast-forward and rewind don't work properly.
> >> >>>
> >> >>>  The "dvd" format is being requested by kdenlive, but the NAV
> >> packets
> >> >>> don't get produced - well to be fair, a 22 minute VOB had 6 NAV
> >> packets rather than the expected 2600 odd.
> >> >>>
> >> >>>  I looked through the code and found that in
> >> libavformat/mpegenc.c,
> >> >>> in
> >> >>> mpeg_mux_write_packet, towards the end, is this code fragment:
> >> >>>
> >> >>>     if (s->is_dvd){
> >> >>>         if (is_iframe && (s->packet_number == 0 || (pts -
> >> >>> stream->vobu_start_pts >= 36000))) { // min VOBU length 0.4
> >> >>> seconds (mpucoder)
> >> >>>             stream->bytes_to_iframe = av_fifo_size(&stream->fifo);
> >> >>> stream->align_iframe = 1;
> >> >>>             stream->vobu_start_pts = pts;
> >> >>>         } else {
> >> >>>             stream->align_iframe = 0;
> >> >>>         }
> >> >>>     }
> >> >>>
> >> >>>
> >> >>>  If I remove the assignment of 0 to align_iframe in the 'else'
> >> >>> clause,
> >> >>> the code appears to work.  i.e. I get lots of NAV packets,
> >> dvdauthor correctly sets all of the chapter points, and FF/REW
> >> works properly in my DVD player.
> >> >>>
> >> >>>  I confess that I only have a shallow understanding of this code,
> >> and
> >> >>> it could be that my change has some unintended consequences.  I
> >> would appreciate if it someone more familiar with the code would
> >> check if this is an appropriate change and hopefully get the
> >> problem fixed.
> >> >>>
> >> >>>  I am quite happy to test any alternate changes to make sure they
> >> >>> still do the right thing on my files if that will help.
> >> >>>
> >> >>>  (Yes, I have checked current SVN code).
> >> >>
> >> >> if it is reproduceable with (unmodified) command line ffmpeg then
> >> please provide full uncut output + used command line of it
> >> >>
> >> >> also the code you change is there since 2004, could you try some
> >> old svn versions to check if they generated nav packets properly
> >> >> and if not then iam a little curious why noone complained yet but
> >> ignoring that, your suggested fix looks correct but i first would
> >> like to understand the issue better also iam not maintainer of the
> >> mpeg muxer code, so i wont approve this change ...
> >> >>
> >> >> also did nav packet generation/dvd encoding work for anyone?
> >> >
> >> > I recall vaguely a problem involving reading from a VOB with NAVs
> >> using vcodec copy that would fail to pass on the proper number of
> >> NAVs.
> >> >
> >> > I'll try to find it.
> >>
> >> Here it is:
> >> http://thread.gmane.org/gmane.comp.video.ffmpeg.user/8662
> >
> > does it work if the above mentioned align_iframe = 0 is removed?
> 
> Yes, it worked: all the 160 NAV packets were passed on (the scenario is
> the worst case at the previous to last mail in that thread).

great, then i think we should just remove that else align_iframe = 0

mans, if you are ok with that i can remove it

it doesnt look correct anyway, as the insertion of nav packets happens
delayed relative to setting align_iframe, which is set when a new packet
is passed to the muxer
setting align_iframe to 0 when a non i frame is passed to the muxer but
before a nav packet has been stored for the previous i frame can hardly
be correct ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070715/439042c4/attachment.pgp>