On systems which deliver SIGPIPE (Unices), a broken pipe will currently
result in the immediate termination of the ffmpeg process (the default
disposition as required by POSIX). This is undesirable, because while
the broken pipe is likely fatal to useful cleanup of whatever component
is writing to it, there might be other components which can do useful
cleanup - for example, a muxer on another stream may still need to write
indexes to complete a file. Therefore, set the signal disposition for
SIGPIPE to ignore the signal - the call which caused the signal will
fail with EPIPE and the error will be propagated upwards like any other
I/O failure on a single stream.
add return value check to supress the build warning message like
"warning: ignoring return value" when use attribute -Wunused-result.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Reviewed-by: 刘歧 <lq@chinaffmpeg.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
With there being two hwaccels that use the CUDA pix_fmt now, just
relying on the pix_fmt to identify the selected hwaccel is not enough
anymore.
So this checks if the user explicitly selected a hwaccel, and only
accepts that one.
Fixes looping files without audio or when using stream_copy, where
ist->nb_samples is not set since no decoding is done.
This fixes ticket #5719 and also fixes an endless loop with the sample
in ticket #6139.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since a7da134742, flush packets are passed
to process_input_packet() during stream copy. This modifies the input
timestamp handling to ignore them - since they contain no data, timestamps
should not be affected.
Otherwise the frame size of the codec is not set in the buffersink.
Fixes ticket #6603 and the following simpler case:
ffmpeg -c aac -filter_complex "sine=d=0.1,asetnsamples=1025" out.aac
Signed-off-by: Marton Balint <cus@passwd.hu>
This is required for FLV files, for which duration_pts comes out to be zero.
Signed-off-by: Sasi Inguva <isasi@google.com>
Reviewed-by: Thomas Mundt <tmundt75@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since af1761f7b5 ffmpeg waits for a frame in each
stream before writing the output header. If we are using threaded decoding for
attached pictures, we have to read till EOF to be able to finally flush the
decoder and output the decoded frame. This essentially makes ffmpeg buffer all
non-attached picture packets, which will cause a "Too many packets buffered for
output stream" eventually.
By forcing single threaded decoding, we get a frame from a single packet as
well and we can avoid the error.
Fixes part of ticket #6375:
ffmpeg -i 46564100.mp3 -acodec libmp3lame -ab 128k -ac 2 out.mp3
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Marton Balint
Mark Thompson
James Almer
Jun Zhao
Timo Rothenpieler
Peter Große
Michael Niedermayer
Carl Eugen Hoyos
Sasi Inguva