[Ffmpeg-devel] corrupt audio when cut

[Wolfram Gloger]

Hi,

> Unfortunately, the patch actually made things worse. The "error, non 
> monotone timestamps" stuff was still there on the 16,48,80 (problematic) 
> values and the audio was still messed up.

That is very strange!  I have just verified with "test.avi" downloaded
this morning (md5: 27ae5c7454f9c7960e5a508a3f41006a):

Without the patch, I can reproduce your problems exactly.

With the patched version, I get (note especially the "after seek
timestamp" message):

% /tmp/ffmpeg/ffmpeg -ss 48.0 -t 25.8 -y -vcodec copy -acodec copy -i test.avi cutfile.avi
FFmpeg version SVN-r7541, Copyright (c) 2000-2006 Fabrice Bellard, et al.
  configuration:  --enable-a52 --enable-mp3lame --enable-gpl --enable-libogg --enable-vorbis 
  libavutil version: 49.1.0
  libavcodec version: 51.28.0
  libavformat version: 51.7.0
  built on Jan 16 2007 11:04:22, gcc: 2.95.4 20011002 (Debian prerelease)
tag: tag=LIST size=0x2276
...
tag: tag=LIST size=0x4cf802
list: tag=movi size=0x0
movi end=4d1eb4
movi_end=0x4d1eb4
tag=idx1 size=0x16ad0
*** after seek timestamp= 48014633

Seems stream 0 codec frame rate differs from container frame rate: 30000.00 (30000/1) -> 29.97 (30000/1001)
Input #0, avi, from 'test.avi':
  Duration: 00:01:25.0, start: 0.000000, bitrate: 484 kb/s
  Stream #0.0: Video: mpeg4, yuv420p, 480x384, 29.97 fps(r)
  Stream #0.1: Audio: mp3, 44100 Hz, stereo, 192 kb/s
Output #0, avi, to 'cutfile.avi':
  Stream #0.0: Video: mpeg4, yuv420p, 480x384, q=2-31, 29.97 fps(c)
  Stream #0.1: Audio: mp3, 44100 Hz, stereo, 192 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1
Press [q] to stop encoding
frame=  774 q=1181175.9 Lsize=    1515kB time=25.8 bitrate= 480.9kbits/s    
video:858kB audio:604kB global headers:0kB muxing overhead 3.575189%

And the resulting file is fine AFAICS, no corruption.

> Furthermore, non-problematic 
> values caused ffmpeg to *transcode* from test.avi into cutfile.avi 
> instead of just cutting. Whereas before the cut command was almost 
> instantaneous (which makes sense under the -acodec copy -vcodec copy 
> conditions), the patched ffmpeg now takes much, much longer as if I were 
> transcoding from one format to another.

That is practically impossible given the non-intrusiveness of the
patch.  I tried "non-problematic" start values as well and everything
is fine..  Please try again, something must have gone terribly wrong
while applying the patch.

Regards,
Wolfram.