Continuing -async issues

[agni451]

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.

[agni451]

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"

ffmpeg -y -i "full.ts" -vcodec copy -acodec copy -ss 00:43:33.000 -t 270 "change.ts"

ffmpeg -y -i "full.ts" -vcodec copy -acodec copy -ss 00:45:13.000 -t 170 "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:

ffmpeg_1_29.exe -y -i "change.ts" -q:vscale 0 -mbd 2 -acodec ac3 -ab 384k -ac 6 -async 48000 "change_1_29.avi"

ffmpeg_1_29.exe -y -i "nochange.ts" -q:vscale 0 -mbd 2 -acodec ac3 -ab 384k -ac 6 -async 48000 "nochange_1_29.avi"

ffmpeg_2_26.exe -y -i "change.ts" -q:vscale 0 -mbd 2 -acodec ac3 -ab 384k -ac 6 -async 48000 "change_2_26.avi"

ffmpeg_2_26.exe -y -i "nochange.ts" -q:vscale 0 -mbd 2 -acodec ac3 -ab 384k -ac 6 -async 48000 "nochange_2_26.avi"

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.

Summary:

change_1_29.avi FAIL
nochange_1_29.avi SUCCESS
change_2_26.avi SUCCESS
nochange_2_26.avi FAIL

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).

[Carl Eugen Hoyos]

To make this a valid ticket, please provide a (one) failing command line together with complete, uncut console output.

[agni451]

console output of failed commandline

[Carl Eugen Hoyos]

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

[agni451]

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.