Opened 10 years ago
Last modified 10 years ago
#2309 new defect
Continuing -async issues
|Reported by:||agni451||Owned by:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
Summary of the bug:
How to reproduce:
% ffmpeg.exe -v verbose -y -i "K:\!TEST\Dsmall.ts" -q:vscale 0 -mbd 2 -c:a ac3 -ab 448k -ac 6 -async 48000 "K:\!TEST\bad.avi" ffmpeg version f6fff8e (64-bit) built on Feb 26 2013
I downloaded both the 2-25-2013 and 2-26-2013 static builds and tested a bunch of files with them, and they all seemed to work great. Unfortunately, I stumbled upon a new glitch that doesn't occur in builds 066739f (2-24-2013) and earlier. I uploaded a 1:40min sample file along with short [-v verbose] and long [-v verbose -loglevel 99] outputs running under 066739f (1-29-2013) and f6fff8e (2-26-2013). Find this in "Ticket2210new.7z" in /incoming. The 1-29 build handles the error approx 11sec in just fine, but the 2-26 build goes crazy and adds too much silence (~12sec worth). Oddly enough, there is NO channel layout change in this sample to deal with, just a standard gap error and timestamp "drift".
The exact command I used was
ffmpeg.exe -v verbose -y -i "K:\!TEST\Dsmall.ts" -c:v mpeg2video -q:vscale 0 -mbd 2 -c:a ac3 -ab 448k -ac 6 -async 48000 "K:\!TEST\D_FIX.ts"
but outputting an avi shows the audio error immediately:
ffmpeg.exe -v verbose -y -i "K:\!TEST\Dsmall.ts" -q:vscale 0 -mbd 2 -c:a ac3 -ab 448k -ac 6 -async 48000 "K:\!TEST\bad.avi"
Basically ffmpeg now handles channel layout changes fine (as far as my testing has confirmed), but now it occasionally has problems with gap and timestamp drift errors. I say occasionally because I ran the sample I gave in comment 18 (it has channel changes AND gaps AND timestamp drift) and it didn't have a problem. I'm hoping you can see why one would have a problem and not the other. If you need a new copy of the sample from comment 18, I can re-upload it.
Change History (5)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
To make this a valid ticket, please provide a (one) failing command line together with complete, uncut console output.
by , 10 years ago
console output of failed commandline
comment:3 by , 10 years ago
I tested the following command line:
$ ffmpeg -i Dsmall.ts -qscale 2 out.avi
and the output file plays find here.
I also tested the following command line:
$ ffmpeg -async 1 -i Dsmall.ts -qscale 2 outasync.avi
and the output files play fine here.
What do I miss?
Unrelated: Please do not compress your uploads with 7z, see also http://ffmpeg.org/bugreports.html
comment:4 by , 10 years ago
I tried your commandline and it works for all of my samples as far as I can tell. The difference was that I used -async 48000 instead of -async 1, and that DOES result in errors. But I guess of async 1 works for all cases, I'll just use that. Might want to edit the documentation to reflect that only -async 1 works now.
I'm going to keep testing with all new video that I'm going to re-encode, and see how things go for a while. If I notice any issues around -async, I'll let you know. Sorry for creating a new, apparently unnecessary ticket.
I just created this ticket, but I'd like to add a new finding. I have a 1 hour TS file named "full.ts". I trimmed from this two files "change.ts" and "nochange.ts"
If you look closely, the files start at different times but end at the same time. This way, "change.ts" includes commercials that cause a 2ch--6ch change, while "nochange.ts" starts after this and so does not include a channel change.
I then used two different versions of ffmpeg: dc8dd2f (1-29-2013) and f6fff8e (2-26-2013) to create four avi files thus:
I expected "change_1_29.avi" to have failed because that version of ffmpeg did not yet have the fix from Ticket 2210. It did fail. I expected the "nochange_1_29.avi" to be just fine, and it was. I expected "change_2_26.avi" to be good since the fix had been released. It was just fine. I also expected "nochange_2_26.avi" to be fine, since it had no channel layout change and it worked fine for the older version. It failed.
For some reason the latest version works fine with a channel change AND any errors encountered after that (gaps, timestamp drift), but when there is NO channel change, it chokes on the gaps and timestamp drift errors that older versions handled just fine. Basically the fix for Ticket 2210 fixed the channel layout change confusion but partially broke the original function of -async.
Let me know if you want a copy of "change.ts" and "nochange.ts". They are large, together equaling about 815MB (the size is necessary to encompass all errors).