[FFmpeg-trac] #2210(undetermined:new): AC3 channel layout change midstream causes severe errors

[FFmpeg]

#2210: AC3 channel layout change midstream causes severe errors
-------------------------------------+-------------------------------------
             Reporter:  agni451      |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:  async        |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by agni451):

 I've managed to find a clip that contains both and 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.

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

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2210#comment:18>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker