[FFmpeg-trac] #8917(undetermined:new): Exit on SIGPIPE or SIGHUP - "-xerror" not working as expected

FFmpeg trac at avcodec.org
Sun Oct 4 13:42:37 EEST 2020


#8917: Exit on SIGPIPE or SIGHUP - "-xerror" not working as expected
-------------------------------------+-------------------------------------
             Reporter:  atom         |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:  4.2
  undetermined                       |
             Keywords:  sigpipe      |               Blocked By:
  sighup error xerror                |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Expectation: ffmpeg process should die on errors and certain signals, when
 "-xerror" option is used.

 Behaviour: Even with  "-xerror", ffmpeg continues to run after receiving a
 SIGPIPE or SIGHUP signal.

 Use cases: Using a pipe to test for "non monotonically increasing dts". In
 these cases, "grep" immediately (or almost immediately) matches the string
 "non monotonically increasing dts" and exits, closing the pipe. This
 should cause ffmpeg to die, but it keeps running and processing the entire
 input file, even with the "-xerror" option.

 In the first example, this would send a SIGPIPE signal to ffmpeg, which
 should reasonably stop the ffmpeg process:

 `ffmpeg -xerror -i test.mkv -f null - 2>&1 | grep -m 1 'non monotonically
 increasing dts'`

 In the second example, the closed pipe stops "cat", and the coprocess
 receives a SIGHUP signal. Again, this should reasonably stop ffmpeg.

 `cat < <( ffmpeg   -xerror  -i test.mkv -f null - 2>&1 ) | grep -m 1 'non
 monotonically increasing dts'`

 If it's not reasonable that "-xerror" kills the ffmpeg process on these
 signals, then there should probably be one or more options to kill ffmpeg
 on various signals (eg an "-xsignal" option) or specific signals (eg an
 "-xpipe", and "-xhup" options).

 As it is now, ffmpeg can consume incredible resources after it should have
 died. In many cases, eg processing streams and/or continuing "hidden"
 after a SIGHUP signal, can run indefinitely, and somewhat hidden.

 nb, for duplicating this behaviour with good files, change the string that
 grep is matching to something such as "fps", or "mapping", or "Stream".
 This will match almost immediately with most/all video files, and
 duplicate the described behaviour.

 No doubt there are countless other use cases where it would be desirable
 for ffmpeg to exit when receiving a SIGPIPE, SIGHUP, or other signals.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/8917>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list