Tom Bird <[EMAIL PROTECTED]> added the comment: dcbill wrote: > dcbill <[EMAIL PROTECTED]> added the comment: > > Tom, see if the sync problem is still there with revision 9983 or before (as > in > the same as the Timestamp bug recently entered). > > Also, do you use 32-bit or 64-bit machines?
Hi, I've tried rev 9983 and the latest on 32 and 64 bit (native, not a 32 bit compile on a 64 bit box, not that it should matter) machines, 32 bit one was a Sun X2100 AMD Opteron 2.2GHz running Debian Sarge i386, 64 bit was a Sun X4200 AMD Opteron 2.8GHz running Debian Etch amd64. Standard Debian gccs both times, 32 bit gcc version 3.3.5 (Debian 1:3.3.5-13) and 64 bit gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21). I've got a sample file that really shows up the bugs, created from a source file that had already experienced packet loss by: $ dd if=482706.ts of=lazytown-sample-mpeg2.ts bs=188 skip=450000 count=150000 150000+0 records in 150000+0 records out 28200000 bytes (28 MB) copied, 0.738861 seconds, 38.2 MB/s Firstly as you can see, I've not made any attempt to line up the file with any MPEG boundary (just the transport stream packet size, 188 bytes), this seems to bring out one other bug - unless you actually specify the number of audio channels and sample rate, it won't transcode. It successfully detects the channels but seems variable on whether it works with them. File is here: http://g.bbcredux.com/static/lazytown-sample-mpeg2.ts The following command line works to transcode it: ffmpeg -i lazytown-sample-mpeg2.ts -ac 2 -ar 48000 test.avi When you play test.avi you will see that the video remains true to the time line but the audio is now very much ahead. thanks, Tom ______________________________________________________ FFmpeg issue tracker <[EMAIL PROTECTED]> <https://roundup.mplayerhq.hu/roundup/ffmpeg/issue152> ______________________________________________________
