Missing aac audio after encoding to mpeg-ts with very high video bitrate

Description

When encoding from h264/aac mp4 to mpeg-ts, the audio stream is lost or corrupt. Mediainfo reports an audio stream but it appears to be empty. This *only* occurs when '-threads' set to 0. Using a specific thread size (e.g. -threads 4) prevents the issue.

I can consistently reproduce this with centos 5, but not with osx.

Note that both audio and video playback with -threads >0 as well as builds from August and earlier.

I recompiled without libx264 and without libfaac. Using "-vcodec copy -acodec copy" I am not able to reproduce the issue. The versions of both work with previous builds of ffmpeg though.

Also, as there were stream-specific changed to "-threads", I've also tested with "-threads:0 0 -threads:1 0" with also had the audio issue.

I cannot upload the file to datafilehost.com as the owner of the content does not want it made available to the general public. When I trim the file so that it is < 2.5Mb the bug is also not reproducible.

Please provide at least complete, uncut output of your failing command, the command should be as short as possible and please do not use an external library if it is not needed to reproduce the problem.

It does work at the moment, as does the previous command with -threads 4, but changing to -threads 0 causes the failure again. The behavior is non-deterministic when -threads 4, but will always fail with -threads 0 apparently.

Also, I'm using 'git bisect' to narrow down the changelist that introduced the problem. So far, I can say that it happened between sept 5 and sept 10. I'll provide more details on that when I narrow further.

I'm not so certain that I've found the bad changelist. I found that I hadn't completely uninstalled he previous version's libraries. I'm improved my regression script and re-running. I'll update with the correct changelist when I find it.

I've further narrowed down the change to the file libavcodec/libx264.c. There were quite a few changes to this file, so if anyone monitoring git who has some familiarity with this code has a chance to look at the diff, I'd welcome any input.

Is it possible that with the addition of new private options that one of the defaults is causing the stream corruption?

Something else that I found during testing just now ... "-threads 4" fails just like "-threads 0"

Is this still correct or not? If yes, could you confirm if -vcodec libx264 is needed to reproduce the problem or if it is also reproducible with -vcodec mpeg4 -qscale 2?

And please try to repeat what the problem is (no sound?), what the shortest command line is to trigger this problem and how output looks like. Please test the native aac, the native mp2 and an external aac encoder and different containers.
Finally, please post complete, uncut output for the failing command (together with the short command line).

I've provided a lot of other information, including isolating the changelist where this broke. Is any of this useful? It looks like it's triggered by the changes in sending qmin, qmax and sc_threshold. I disable scenecut detection with '-sc_threshold 0' which may also be related.

If you there is a private fpt host I could use to upload the file I would provide it so you can reproduce.

I've provided a lot of other information, including isolating the changelist where this broke. Is any of this useful?

I guess so, but you also provided the information that "-threads 4" fails just like "-threads 0", so I asked you to test -threads 4 -vcodec mpeg4 if (and only if) this information was correct.
It happens often to me that I test and reports something and it turns out that my report was not correct, in such a case it is important to test and report again, indeterministic behaviour is very, very unlikely (if your memory isn't broken).

No, I only have a couple files where this happens. Another interesting thing I've found is that if I only transcode the first 3 seconds of the video I do not see the issue. But if I go beyond that, it fails. The first few seconds of the video are silent because they are an intro screen before the video starts.

I ruled out recent changes to mpegts.c by reverting to changelist 2e15305b7088c9dfe1c8d29c248a9b49bcf0b0a3 which was checked in on 4/29/2011. I was able to reproduce the bug with this older version of mpegts.c.

Given that we were both able to reproduce the problem without using libx264 (and, in my case, without even compiling libx264.c). this seems very unlikely.
What is very likely, though, is that when reverting that patch, the original problem is not triggered any more because the bit rate changes for x264 encoding.

If you follow the code that relates to that change, it later touoches code that affects the threading model. Since we know that lowering the number of threads does work around the bug, it seems likely that there is a correlation.

Also, lowering the target bitrate from 7Mbps to, say, 5Mbps doesnt work around the bug for me. I can try other bitrates as well.