[FFmpeg-trac] #9487(ffmpeg:open): FFmpeg -shortest not working when using -filter_complex with audio and video filters

[FFmpeg]

#9487: FFmpeg -shortest not working when using -filter_complex with audio and
video filters
-------------------------------------+-------------------------------------
             Reporter:               |                    Owner:  (none)
  pigeonburger                       |
                 Type:  defect       |                   Status:  open
             Priority:  important    |                Component:  ffmpeg
              Version:  git-master   |               Resolution:
             Keywords:  shortest     |               Blocked By:
  filter_complex audio video         |
  audio/video filters                |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by pigeonburger):

 Replying to [comment:5 Michael Koch]:
 > The amix filter has a "duration" option. It works if you set this option
 to "shortest".
 > But this doesn't explain why the -shortest option doesn't work.
 >
 > {{{
 > ffmpeg -i input.mp4 -i song.m4a -lavfi
 [0:a][1:a]amix=duration=shortest[s0];[0:v]null[s1] -map [s0] -map [s1] -y
 output.mp4
 > }}}

 Even with that command `-shortest` is still not actually getting triggered
 when adding `duration=shortest` to `amix`, because all that's doing is
 shortening the `m4a` back to the original video's audio stream, which is
 likely the same length as the video itself, so it's still reverting to
 default behaviour. In that case it just //appears// to be working.

 You can prove this by using an input video that has an audio stream
 //shorter// than the video stream and trying it with my original command.
 The `m4a` file will obey the `duration=shortest` and stop when the other
 audio stream finishes, but encoding will continue until the video stream,
 which in this case is the //longest// stream, stops. Of course, the
 expected behaviour here would be for FFmpeg to stop encoding once the
 shorter audio stream finishes, but that doesn't happen.

 There's some sort of deep-seated long-standing bug here that's never been
 fixed and has been a known issue since at least 2014 (in the ticket I
 linked originally). I've tried having a look at the source code and
 debugging it myself but I'm not too experienced with C.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9487#comment:6>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker