progressive delay

[lo]

$ ffmpeg -version
ffmpeg version 0.8.1-4:0.8.1-0ubuntu1, Copyright (c) 2000-2011 the Libav developers
  built on Mar 22 2012 05:09:06 with gcc 4.6.3

i have this multiple audio stream (dvdmux) file ​https://anonfiles.com/file/762eac57843686d48931eab79d571d9c
and i'm not able to strip out the foreign language.

the command i used is:

ffmpeg -i input.avi -map 0:0 -vcodec copy -map 0:1 -acodec copy output.avi

and i tried many ffmpeg versions, newer and older ones.

i also tried with avconv:

avconv -i input.avi -map 0:0 -c copy -map 0:1 -c copy output.avi

i did this many times before, but now i keep on getting a progressive delay: the file starts with audio and video synchronized but, going on watching, they divert.

thank you.

[Carl Eugen Hoyos]

The version you tested is intentionally broken and contains several hundred known bugs (some of them security relevant), please understand that it cannot be supported here.
Please test current FFmpeg git head - ​http://ffmpeg.org/download.html - and post command line together with complete, uncut console output.

[lo]

same progressive delay result:

$ ../ffmpeg/ffmpeg -i 01.avi -map 0:0 -vcodec copy -map 0:1 -acodec copy output.avi
ffmpeg version git-2012-06-11-20e46aa Copyright (c) 2000-2012 the FFmpeg developers
  built on Jun 11 2012 10:49:59 with gcc 4.4.3
  configuration: 
  libavutil      51. 57.100 / 51. 57.100
  libavcodec     54. 25.100 / 54. 25.100
  libavformat    54.  6.101 / 54.  6.101
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     2. 78.101 /  2. 78.101
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
Input #0, avi, from '01.avi':
  Metadata:
    encoder         : VirtualDubMod 1.5.10.2 (build 2540/release)
  Duration: 00:21:12.64, start: 0.000000, bitrate: 1281 kb/s
    Stream #0:0: Video: mpeg4 (DX50 / 0x30355844), yuv420p, 704x528 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 25 tbn, 30k tbc
    Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16, 128 kb/s
    Stream #0:2: Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, stereo, s16, 128 kb/s
Output #0, avi, to 'output.avi':
  Metadata:
    ISFT            : Lavf54.6.101
    Stream #0:0: Video: mpeg4 (DX50 / 0x30355844), yuv420p, 704x528 [SAR 1:1 DAR 4:3], q=2-31, 25 fps, 25 tbn, 25 tbc
    Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, 128 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=31816 fps=14090 q=-1.0 Lsize=  178474kB time=00:21:12.64 bitrate=1148.8kbits/s    
video:157503kB audio:18957kB global headers:0kB muxing overhead 1.141271%

[lo]

removing stream #0:1 gives a working file instead...

[lo]

Replying to lo:

same progressive delay result:

$ ../ffmpeg/ffmpeg -i 01.avi -map 0:0 -vcodec copy -map 0:1 -acodec copy output.avi
ffmpeg version git-2012-06-11-20e46aa Copyright (c) 2000-2012 the FFmpeg developers
  built on Jun 11 2012 10:49:59 with gcc 4.4.3
  configuration: 
  libavutil      51. 57.100 / 51. 57.100
  libavcodec     54. 25.100 / 54. 25.100
  libavformat    54.  6.101 / 54.  6.101
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     2. 78.101 /  2. 78.101
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
Input #0, avi, from '01.avi':
  Metadata:
    encoder         : VirtualDubMod 1.5.10.2 (build 2540/release)
  Duration: 00:21:12.64, start: 0.000000, bitrate: 1281 kb/s
    Stream #0:0: Video: mpeg4 (DX50 / 0x30355844), yuv420p, 704x528 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 25 tbn, 30k tbc
    Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16, 128 kb/s
    Stream #0:2: Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, stereo, s16, 128 kb/s
Output #0, avi, to 'output.avi':
  Metadata:
    ISFT            : Lavf54.6.101
    Stream #0:0: Video: mpeg4 (DX50 / 0x30355844), yuv420p, 704x528 [SAR 1:1 DAR 4:3], q=2-31, 25 fps, 25 tbn, 25 tbc
    Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, 128 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=31816 fps=14090 q=-1.0 Lsize=  178474kB time=00:21:12.64 bitrate=1148.8kbits/s    
video:157503kB audio:18957kB global headers:0kB muxing overhead 1.141271%

totem 2.30.2: progressive audio deley
vlc 1.0.6 goldeneye: extremely hiccuping audio track

[Carl Eugen Hoyos]

I don't think this is a regression, also reproducible with the following command:
$ ffmpeg -i 1339188407320.avi -acodec copy -qscale 2 -map 0:0 -map 0:1 out.avi

[Mike]

I've tried a few experiments with this sample file, and the results are just weird. I'm using ffmpeg built from git on June 8.

Muxing to .mp4 or .ts container gives a file that seems to play correctly in ffplay.

ffmpeg -i 133*.avi -vcodec copy -acodec copy -map 0:0 -map 0:1 out.ts

The out.avi file created by ffmpeg app does not play correctly in ffplay: the video plays slower than it should (maybe 1/3 rate?). Audio seems to be playing correctly in ffplay.

For out.avi, the video timestamps shown by ffprobe look ok, assuming it's supposed to be 25 frame/sec video.

When ffplay is run, the header information read from the out.avi file by the avidec demux looks reasonable.

More investigation is required.

[Mike]

It looks like there is something wrong with the audio time stamps of stream 1. The video plays too slow because, by default, ffplay uses audio timestamps as the master clock, and ffplay is slowing down the video to align it to the (bad) audio timestamps.

The output of 'ffprobe -show_packets out.avi' shows one symptom: every audio timestamp is duplicated once. ffprobe does show the correct duration for duration_time (in this stream, each audio frame should be 24 milliseconds).

The out.avi file has an index, which is being used by the avi demux. Using gdb on avi_read_packet() shows messed up values in the index of stream 1. Another problem: the timestamp difference between index entry [n] and [n+1] is not constant, as it should be.

Maybe the index is being calculated or written wrong by the avi mux?

[Mike]

To anyone reading this: this feels like a serious regression to me, but I have only a small amount of time each day to work on things like this. Help from others is welcome, either to identify the commit that caused the problem, or to submit a patch to fix it.

[Mike]

OK: I'm reducing priority back to 'normal', because this does NOT appear to be a regression.

I went back several years, and this 133*.avi file can't be remultiplexed in any version of ffmpeg.

[Mike]

The root cause of the problem is incorrect calculation of audio timestamps for mp3 in the avi demux.

The attached 'avi-mp3-v1.patch' fixes the problem for the 133*.avi sample.

[Mike]

fate shows that my patch has a problem when the avi contains index entries with len=0, which are used for emulating variable frame rate. I'm investigating.

[Mike]

avi-mp3-v2.patch has an updated fix, with more extensive testing.

[Carl Eugen Hoyos]

Fixed in current git head.

[Mike]

Michael N's patch is inadequate, and does not fix this bug in the correct place. My 2nd patch does.

For example, ffplay does not play the 133*.avi file correctly (video frames are displayed too slowly; use the '-an' option to observe correct playback speed.)

His patch fixed exactly one speical case: stream copy using ffmpeg.c. All other applications which use the avi demuxer are still broken.

[Carl Eugen Hoyos]

I just tested ffplay -ast 1 and ffplay -ast 2 with the sample and both work fine for me, both play video with the same speed as ffplay -an.
Could you elaborate what works badly for you?

[Carl Eugen Hoyos]

mplayer -demuxer lavf also seems to play the sample fine, I tested with both -aid 0 and -aid 1.