AC3 channel layout change midstream causes severe errors

[agni451]

Summary of the bug:
How to reproduce:

% ffmpeg -v verbose -y -i "C:\PATH\ORIG.ts" -c:v mpeg2video -q:vscale 0 -flags +ilme+ildct -top 1 -c:a ac3 -ab 384k -ac 6 -async 48000 "C:\PATH\FIX.ts"
ffmpeg version N-46469-gc995644
built on Nov 5 2012

The input I'm using is a TV program recorded in Media Center, so it has an MPEG2 stream and a 6ch ac3 stream. I use the commandline above in an effort to correct for missing audio/video frames, and it works great if I've already removed the commercials from the stream (using DGIndexNV to copy the pieces I want). However, I've noticed that DGIndexNV does not compensate for the initial audio delay in the stream, so the end of the audio cuts out before the video. I want to start trimming at specific frames, and the only way to do that is to fix the stream first using the above commandline. Then I find the frames at which I need to cut, and use tsmuxer to do it. Since the commandline above also fixes the initial delay, I don't have to worry about the audio being off.

However, some of the recorded shows with commercials experience an audio channel number and layout change around the commercials, going from 6ch 48000 --> 2ch stereo, then switching back. This causes extreme problems with the fixed stream using the above commandline, as I suddenly start getting messages like " st:0 PTS: 100320 DTS: 100320 < 64387716 invalid, clipping" and adding very large segments of silent audio (like 10 minutes).

In the log I am attaching, you will see that the audio changes from 6ch to stereo or vice versa a total of 6 times. The one that takes place at 44:17.120 results in the entire rest of the clip being silent. I don't think I'm missing any features that might fix this, so I'm posting it as a bug.

[agni451]

the stderr and stdout in a text file, compressed with 7zip

[Carl Eugen Hoyos]

Please provide the input sample.

[agni451]

Replying to cehoyos:

Please provide the input sample.

The original file is 5.19GB and I can't seem to trim a piece off that gives the same result.

[agni451]

Okay, I've found a sample of the file that showcases the error, but not as severely as the entire file. I had to re-encode the video at a much lower bitrate to decrease the file size, but the audio was just copied. Can I upload it at ​http://upload.ffmpeg.org/upload/ and reference ticket #2210? Total size is 9.33MB.

Just out of curiosity, when it says "adding x audio samples of silence", how would you calculate "x" in ms? It doesn't seem to consistently be 48000sam/sec, because it said it was adding 34380288 samples of silence, which at 48000sam/sec would be just under 12 minutes. However, extracting the audio and putting it in Audacity to measure the silence puts it at just under 15 minutes. (This example is from the full clip, not the 10MB sample).

A little additional info about the full clip: the original video length is 01:05:57.440, and the original audio is is 01:04:24.320. The "fixed" video length is 01:05:58.355, but the "fixed" audio is 01:21:59.712.

[agni451]

Uploaded input sample as "ac3_channel_change_bug.ts" and description text file as "ac3_channel_change_bug.txt" using FileZilla at upload.ffmpeg.org/incoming/

[Carl Eugen Hoyos]

I tested the following command:
$ ffmpeg -i ac3_channel_change_bug.ts -vcodec mpeg2video -qscale 0 -flags +ilme+ildct -top 1 -acodec ac3 -ab 384k -ac 6 out.ts

The output file plays fine (no A/V sync issues) here. Why are you adding -async 48000?

[agni451]

I have to use async because I do not re-encode the video and audio together (I need to pass the video through Avisynth with QTGMC for deinterlacing, and I need to pad the end of the audio to match the video length). With TV streams, there are sometimes the odd gap in the audio stream. It plays fine as a TS because the timecodes keep it in line. When the video and audio streams are separated, re-encoded separately, and then muxed back together (in my case, in an mkv file) any gaps in audio disappear and this leads to the audio becoming increasingly out of sync with each error. I need to insert silence for those gaps to keep the audio in sync, and async does that for me. Unfortunately, it seems to be confused by the change in audio channel layout and adds far more than it should. Like I said, this generally happens during the commercials, but it has occurred during the actual program.

As for the file I provided, it really only demonstrates the audio change confusion, but not really why I use async. According to ffprobe, there is a gap in the audio of 32ms just as it changes from stereo back to 6ch. If you were to demux the TS file and remux into mkv for example, that gap would disappear and the rest of the clip would be 32ms out of sync. That might not be noticeable, but I've seen gaps of 768ms, which would be a huge problem. Even half a dozen 32ms gaps spread over a clip would cause real sync problems by the end, so I need to fill those gaps with silence as they come. Async works very well for that (except in this case).

[agni451]

any updates?

[Elon Musk]

No way to reproduce -> no way to know you fixed it.

[agni451]

How large of a file can I upload to your FTP server? I'm fully willing to upload the full original file that has two very obvious errors, but it's 5.19GB. Let me know.

[Carl Eugen Hoyos]

I suspect a shorter sample that allows to reproduce the >= 500ms gap would be sufficient.

[agni451]

Okay, I'm going to upload a 2.5 minute (205MB) clip copied from the original in a 7z file. I am also uploading the ffprobe -show_frames csv file in which I have indicated (with '-->') where the audio changes from 6ch to stereo and vice versa. ffmpeg gets confused a bit by the 6ch-->stereo, but REALLY gets confused by the stereo-->6ch. To reproduce the problem, and what you should see:

1. run command

   ffmpeg -v verbose -y -i "C:\PATH\ORIG_short.ts" -c:v mpeg2video -q:vscale 0 -flags +ilme+ildct -top 1 -c:a ac3 -ab 384k -ac 6 -async 48000 "C:\PATH\FIX.ts"
   

2. Demux FIX.ts with dgindex, tsmuxer, whatever to get mpeg2 video and ac3 audio files.

3. Mux them in mkvmerge

4. Play in mpc

Between steps 2 and 3 are where I would normally re-encode to x264 and pad the audio, etc.

You should notice that the fixed video file duration is 00:02:30.050. However, the length of the audio is 00:03:44.032, and putting it in audacity clearly shows that an unnecessary 6sec (approx) of silent audio has been added where the channels change from 6ch to stereo. A further 1 minute and 9 seconds (approx) of silent audio have been added where the audio changes from stereo back to 6ch.

Playing the FIX.ts file in mpc should result in a pause of the video and silence around 5 secs in. If you just let it sit there and continue playing, it would remain "paused" for the 6sec mentioned above as it plays the audio with no video. The same thing happens again at 1:07 for 1min 9 secs. Seeking through the video makes it seem as if it plays normally, so please just let the thing play until it's done (mpc says 2:30, which is the true duration of the video, but it's actually the length of the "fixed" audio, 3:44). However, when it's demuxed, re-encoded and brought back together, the extra silent audio is still there, causing a massive sync problem.

Files included in "Ticket 2210 AC3 Channel Change.7z":
ORIG_short.ts [the 2.5min clip]
probeOrigShort.csv [the stdout when running ORIG_short.ts through ffprobe -show_frames]
fix_short_log.txt [the stderr and stdout that I get when running the command listed in step 1]
Bad Audio Fix.png [audacity screenshot showing errors]

I'll begin upload as soon as I post, so it will take a while for the 7z file to appear.

EDIT: Should be in /incoming

[agni451]

Any updates?

[Carl Eugen Hoyos]

Sorry for the delay, I missed your sample!

I tested the following three command lines:
$ ffmpeg -i ORIG_short.ts -qscale 2 -acodec ac3 -ac 6 out.avi
$ ffmpeg -i ORIG_short.ts -qscale 2 -mbd 2 -ac 2 -acodec mp2 out.ts
$ ffmpeg -i ORIG_short.ts -qscale 2 -mbd 2 -ac 6 -acodec ac3 out6.ts
All three output files play in-sync here (there at least is no 500ms desync, and no silence).
What do I miss?

[agni451]

the -async 48000 flag is missing. I need it because there are often gaps in the audio, and that corrects them. This particular sample doesn't have gaps like that, but it does have the audio channel layout change, and that causes massive confusion when it's determining how many extra audio samples to add (it adds too many).

Please use the full commandline listed above in comment 12, then play the file without seeking at all. You should see the "pause" phenomenon that I mention, and if you really want to see the desync, demux the output ts file and then remux the audio and video into an mkv and try playing that. It won't just "pause" it will be completely out of sync.

EDIT: I just tested out your first commandline attempt. Just add -async 48000 and the result is obvious. No need to demux/remux and all that. Check ORIG_short.ts' duration against the new out.avi duration: the video is 2.5 min long, while the new "fixed" audio is 3:44.

ffmpeg -i ORIG_short.ts -q:vscale 2 -acodec ac3 -ac 6 -async 48000 out.avi

[Carl Eugen Hoyos]

Replying to agni451:

the -async 48000 flag is missing. I need it because there are often gaps in the audio, and that corrects them. This particular sample doesn't have gaps like that

Could you upload a sample with such gaps that needs -async ?

I have DVB receivers myself and changes between Dolby Stereo and Dolby Surround happen often, and I know that -async does not work well with channel changes (your original sample showed that already, but it was known before). What we do not have is a sample that needs -async (because audio plays out-of-sync without) and fails at the same time with it (because it contains channel count changes).

[agni451]

I'll do my best to find one that has both problems, but it could take a while to check a bunch of files for errors.

[agni451]

I've managed to find a clip that contains both an audio change and several large gaps. To include both, I have to send a fairly large (400MB) clip uploaded as "Ticket2210.7z". Please do three things with it:

1. Run it through ffmpeg thus:

ffmpeg -i "Ticket2210.ts" -q:vscale 2 -acodec ac3 -ab 384k -ac 6 -async 48000 "out.avi"

The resulting avi file will be completely out of sync after the first ten seconds (which is approx where the 2ch-->6ch occurs). The original video file should be 3:35, but the final avi is 3:45 with 10 secs of unnecessary silent audio added.

2. To get a file that only contains the audio gaps, use the following cmd:

   ffmpeg -i "Ticket2210.ts" -vcodec copy -acodec copy -ss 00:01:33.000 "gaps.ts"
   

Then run the following cmd on "gaps.ts":

ffmpeg -i "gaps.ts" -q:vscale 2 -acodec ac3 -ab 384k -ac 6 -async 48000 "out.avi"

This should result in a perfectly synced avi and is a good example of why I need to use -async in the first place.

3. Take the previously created "gaps.ts" and run it without async:

   ffmpeg -i "gaps.ts" -q:vscale 2 -acodec ac3 -ab 384k -ac 6 "out2.avi"
   

That file will have out of sync audio that ends before the video does. It demonstrates why I need -async.

Is it possible to fix the channel change confusion, since -async is obviously so useful for other errors but fails in that situation?

[Carl Eugen Hoyos]

Thank you for the sample! (I did not realize -async helps with transport streams that have reception errors.)

The following command line produces an output file with heavy A/V desync (several seconds) because of decoding errors after ~5 seconds:

$ ffmpeg -skip_initial_bytes 170M -i Ticket2210.ts -qscale 2 -t 25 out.avi
ffmpeg version N-50203-g73fce25 Copyright (c) 2000-2013 the FFmpeg developers
  built on Feb 23 2013 22:41:12 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --disable-indev=jack
  libavutil      52. 17.103 / 52. 17.103
  libavcodec     54. 92.100 / 54. 92.100
  libavformat    54. 63.100 / 54. 63.100
  libavdevice    54.  3.103 / 54.  3.103
  libavfilter     3. 39.101 /  3. 39.101
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
[mpeg2video @ 0x294b060] 0x0 is invalid
    Last message repeated 11 times
Input #0, mpegts, from 'Ticket2210.ts':
  Duration: 00:02:19.09, start: 77.403367, bitrate: 26800 kb/s
  Program 1
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x101](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 448 kb/s
Please use -q:a or -q:v, -qscale is ambiguous
Output #0, avi, to 'out.avi':
  Metadata:
    ISFT            : Lavf54.63.100
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 tbn, 29.97 tbc
    Stream #0:1(eng): Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 448 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video -> mpeg4)
  Stream #0:1 -> #0:1 (ac3 -> ac3)
Press [q] to stop, [?] for help
frame CRC mismatch0 q=2.0 size=   10877kB time=00:00:02.91 bitrate=30598.0kbits/s
[ac3 @ 0x294b9a0] frame sync error
Error while decoding stream #0:1: Operation not permitted
[mpeg2video @ 0x294b060] ac-tex damaged at 82 17
[mpeg2video @ 0x294b060] Warning MVs not available
[mpeg2video @ 0x294b060] concealing 6087 DC, 6087 AC, 6087 MV errors in I frame
frame=  555 fps=175 q=2.0 Lsize=   40535kB time=00:00:25.02 bitrate=13269.3kbits/s
video:39452kB audio:1038kB subtitle:0 global headers:0kB muxing overhead 0.113509%

The same desync can be seen when transcoding from the beginning:

$ ffmpeg -i Ticket2210.ts -qscale 2 -t 100 out100.avi
ffmpeg version N-50203-g73fce25 Copyright (c) 2000-2013 the FFmpeg developers
  built on Feb 23 2013 22:41:12 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --disable-indev=jack
  libavutil      52. 17.103 / 52. 17.103
  libavcodec     54. 92.100 / 54. 92.100
  libavformat    54. 63.100 / 54. 63.100
  libavdevice    54.  3.103 / 54.  3.103
  libavfilter     3. 39.101 /  3. 39.101
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
Input #0, mpegts, from 'Ticket2210.ts':
  Duration: 00:03:35.09, start: 1.403367, bitrate: 17330 kb/s
  Program 1
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x101](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, stereo, fltp, 192 kb/s
Please use -q:a or -q:v, -qscale is ambiguous
Output #0, avi, to 'out100.avi':
  Metadata:
    ISFT            : Lavf54.63.100
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 tbn, 29.97 tbc
    Stream #0:1(eng): Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, stereo, fltp, 192 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video -> mpeg4)
  Stream #0:1 -> #0:1 (ac3 -> ac3)
Press [q] to stop, [?] for help
Input stream #0:1 frame changed from rate:48000 fmt:fltp ch:2 chl:stereo to rate:48000 fmt:fltp ch:6 chl:5.1(side)
ac-tex damaged at 44 54.0 size=  118160kB time=00:00:57.08 bitrate=16955.7kbits/s
[mpeg2video @ 0x2e920a0] Warning MVs not available
[mpeg2video @ 0x2e920a0] concealing 1680 DC, 1680 AC, 1680 MV errors in I frame
frame CRC mismatch9 q=2.0 size=  158309kB time=00:01:18.41 bitrate=16539.2kbits/s
[ac3 @ 0x2e929e0] frame sync error
Error while decoding stream #0:1: Operation not permitted
[mpeg2video @ 0x2e920a0] ac-tex damaged at 82 17
[mpeg2video @ 0x2e920a0] concealing 6087 DC, 6087 AC, 6087 MV errors in I frame
frame= 2816 fps=180 q=2.0 Lsize=  188541kB time=00:01:40.03 bitrate=15440.1kbits/s
video:186184kB audio:2202kB subtitle:0 global headers:0kB muxing overhead 0.082094%

The following command line produces an output file that plays without visible desync:

$ ffmpeg -async 1 -skip_initial_bytes 170M -i Ticket2210.ts -qscale 2 -t 25 outasync1.avi
ffmpeg version N-50203-g73fce25 Copyright (c) 2000-2013 the FFmpeg developers
  built on Feb 23 2013 22:41:12 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --disable-indev=jack
  libavutil      52. 17.103 / 52. 17.103
  libavcodec     54. 92.100 / 54. 92.100
  libavformat    54. 63.100 / 54. 63.100
  libavdevice    54.  3.103 / 54.  3.103
  libavfilter     3. 39.101 /  3. 39.101
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
[mpeg2video @ 0x2911080] 0x0 is invalid
    Last message repeated 11 times
Input #0, mpegts, from 'Ticket2210.ts':
  Duration: 00:02:19.09, start: 77.403367, bitrate: 26800 kb/s
  Program 1
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x101](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 448 kb/s
Please use -q:a or -q:v, -qscale is ambiguous
-async is forwarded to lavfi similarly to -af aresample=async=1:min_hard_comp=0.100000.
Output #0, avi, to 'outasync1.avi':
  Metadata:
    ISFT            : Lavf54.63.100
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 tbn, 29.97 tbc
    Stream #0:1(eng): Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 448 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video -> mpeg4)
  Stream #0:1 -> #0:1 (ac3 -> ac3)
Press [q] to stop, [?] for help
frame CRC mismatch0 q=2.0 size=   11174kB time=00:00:02.94 bitrate=31093.9kbits/s
[ac3 @ 0x29119c0] frame sync error
Error while decoding stream #0:1: Operation not permitted
[mpeg2video @ 0x2911080] ac-tex damaged at 82 17
[mpeg2video @ 0x2911080] Warning MVs not available
[mpeg2video @ 0x2911080] concealing 6087 DC, 6087 AC, 6087 MV errors in I frame
frame=  555 fps=174 q=2.0 Lsize=   40866kB time=00:00:25.02 bitrate=13377.6kbits/s
video:39452kB audio:1368kB subtitle:0 global headers:0kB muxing overhead 0.112589%

The following does not work due to channel count switch after a few seconds:

$ ffmpeg -async 1 -i Ticket2210.ts -qscale 2 -t 100 out100async.avi
ffmpeg version N-50203-g73fce25 Copyright (c) 2000-2013 the FFmpeg developers
  built on Feb 23 2013 22:41:12 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --disable-indev=jack
  libavutil      52. 17.103 / 52. 17.103
  libavcodec     54. 92.100 / 54. 92.100
  libavformat    54. 63.100 / 54. 63.100
  libavdevice    54.  3.103 / 54.  3.103
  libavfilter     3. 39.101 /  3. 39.101
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
Input #0, mpegts, from 'Ticket2210.ts':
  Duration: 00:03:35.09, start: 1.403367, bitrate: 17330 kb/s
  Program 1
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x101](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, stereo, fltp, 192 kb/s
Please use -q:a or -q:v, -qscale is ambiguous
-async is forwarded to lavfi similarly to -af aresample=async=1:min_hard_comp=0.100000.
Output #0, avi, to 'out100async.avi':
  Metadata:
    ISFT            : Lavf54.63.100
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 tbn, 29.97 tbc
    Stream #0:1(eng): Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, stereo, fltp, 192 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video -> mpeg4)
  Stream #0:1 -> #0:1 (ac3 -> ac3)
Press [q] to stop, [?] for help
frame=  120 fps=0.0 q=2.0 size=    6285kB time=00:00:04.13 bitrate=12444.3kbits/s
frame=  228 fps=226 q=2.0 size=   14514kB time=00:00:07.74 bitrate=15359.5kbits/s
Input stream #0:1 frame changed from rate:48000 fmt:fltp ch:2 chl:stereo to rate:48000 fmt:fltp ch:6 chl:5.1(side)
-async is forwarded to lavfi similarly to -af aresample=async=1:min_hard_comp=0.100000.
[avi @ 0x2bf4a60] st:0 PTS: 0 DTS: 0 < 295 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 1 DTS: 1 < 296 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 2 DTS: 2 < 297 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3 DTS: 3 < 298 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 4 DTS: 4 < 299 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 5 DTS: 5 < 300 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 6 DTS: 6 < 301 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 7 DTS: 7 < 302 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 8 DTS: 8 < 303 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 9 DTS: 9 < 304 invalid, clipping

...

[avi @ 0x2bf4a60] st:0 PTS: 3100 DTS: 3100 < 3395 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3101 DTS: 3101 < 3396 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3102 DTS: 3102 < 3397 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3103 DTS: 3103 < 3398 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3104 DTS: 3104 < 3399 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3105 DTS: 3105 < 3400 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3106 DTS: 3106 < 3401 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3107 DTS: 3107 < 3402 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3108 DTS: 3108 < 3403 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3109 DTS: 3109 < 3404 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3110 DTS: 3110 < 3405 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3111 DTS: 3111 < 3406 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3112 DTS: 3112 < 3407 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3113 DTS: 3113 < 3408 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3114 DTS: 3114 < 3409 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3115 DTS: 3115 < 3410 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3116 DTS: 3116 < 3411 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3117 DTS: 3117 < 3412 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3118 DTS: 3118 < 3413 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3119 DTS: 3119 < 3414 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3120 DTS: 3120 < 3415 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3121 DTS: 3121 < 3416 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3122 DTS: 3122 < 3417 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3123 DTS: 3123 < 3418 invalid, clipping
[avi @ 0x2bf4a60] st:0 PTS: 3124 DTS: 3124 < 3419 invalid, clipping
frame= 2816 fps=177 q=2.0 Lsize=  188911kB time=00:01:49.44 bitrate=14140.7kbits/s
video:186184kB audio:2565kB subtitle:0 global headers:0kB muxing overhead 0.085587%

The output file starts with 10sec desync after the channel count change at ~10s.

[agni451]

Looks like you're getting the same results as me. I noticed you tried

ffmpeg -async 1 -skip_initial_bytes 170M -i Ticket2210.ts -qscale 2 -t 25 outasync1.avi

with -async 1. I've found that it does the exact same thing as -async 48000 (fills in the odd gap) even though the documentation says it is a special case that only corrects the initial delay and nothing else.

That -async command is a real timesaver; until I discovered that it worked to fill gaps I had to use a combination of an MPEG2 repair tool to log errors and a small piece of software of my own design to add the silence to fill the gaps. Unfortunately, it was only correct maybe 80% of the time so I would end up taking a lot of time to make sure everything was correct and manually crop/pad the audio when it wasn't. -Async works perfectly every time EXCEPT when a channel change is encountered. If I was more than an amateur at programming I would try to find out which which library is responsible for the confusion and suggest a correction. I am not, however, so all I can do is give the experts a decent sample. I'm glad I finally found one, and I hope it helps find the source of the error. Let me know if there's anything else I can do.

[Carl Eugen Hoyos]

Replying to agni451:

Unfortunately, it was only correct maybe 80% of the time

Did you ever report this?
We have a sample now (and while a significantly shorter file may be good, it is not absolutely necessary) but generally, bugs that are not reported are less likely to get fixed than bugs that are listed on this tracker (or at least reported on the user mailing list).

[agni451]

Replying to cehoyos:

Replying to agni451:

Unfortunately, it was only correct maybe 80% of the time

Did you ever report this?

Sorry for the confusion; the 80% correct was referring to the combination of the MPEG2 repair software and my own little program that I was using to fill audio gaps before I discovered ffmpeg's -async. They are both completely unrelated to ffmpeg.

[Carl Eugen Hoyos]

Fixed by Michael.

[agni451]

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

ffmpeg64.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:

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

[Carl Eugen Hoyos]

Replying to agni451:

Unfortunately, I stumbled upon a new glitch that doesn't occur in builds 066739f (2-24-2013) and earlier.

Then please open a new ticket, please do not forget to add the failing command line together with complete, uncut console output to the new ticket.