Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#1432 closed defect (fixed)

progressive delay

Reported by: lo Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: avi mp3 desync
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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

Attachments (2)

avi-mp3-v1.patch (2.7 KB ) - added by Mike 12 years ago.
avi-mp3-v2.patch (3.7 KB ) - added by Mike 12 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 by Carl Eugen Hoyos, 13 years ago

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.

comment:2 by lo, 13 years ago

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%

comment:3 by lo, 13 years ago

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

in reply to:  2 comment:4 by lo, 13 years ago

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

comment:5 by Carl Eugen Hoyos, 13 years ago

Component: FFmpegundetermined
Keywords: avi mp3 desync added; progressive delay removed
Reproduced by developer: set
Status: newopen
Version: unspecifiedgit-master

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

comment:6 by Mike, 13 years ago

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.

comment:7 by Mike, 13 years ago

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?

comment:8 by Mike, 13 years ago

Component: undeterminedavformat
Priority: normalimportant

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.

comment:9 by Mike, 13 years ago

Priority: importantnormal

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.

by Mike, 12 years ago

Attachment: avi-mp3-v1.patch added

comment:10 by Mike, 12 years ago

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.

comment:11 by Mike, 12 years ago

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

Version 0, edited 12 years ago by Mike (next)

by Mike, 12 years ago

Attachment: avi-mp3-v2.patch added

comment:12 by Mike, 12 years ago

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

comment:13 by Carl Eugen Hoyos, 12 years ago

Resolution: fixed
Status: openclosed

Fixed in current git head.

comment:14 by Mike, 12 years ago

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.

comment:15 by Carl Eugen Hoyos, 12 years ago

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?

comment:16 by Carl Eugen Hoyos, 12 years ago

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

Note: See TracTickets for help on using tickets.