Wolfram Gloger wrote: > 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. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel at mplayerhq.hu > http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel > I'm a bigtime newbie to development at this low-level, i.e. I'm not exactly sure how to apply patches. Here's what I did. Tell me if I did it wrong. I first got the most recent svn to my home directory. Then, I copied the patch file to my home directory. I used the command "patch -p0 < patch.diff" to apply the patch, then ran configure --enable-mp3lame and then make. Is that right? Cyrus
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