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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4