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.

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.

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

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:

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.

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.

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

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:

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.

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

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.

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

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.

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

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.