At present, progress stats are updated at a hardcoded interval of
half a second. For long processes, this can lead to bloated
logs and progress reports.
Users can now set a custom period using option -stats_period
Default is kept at 0.5 seconds.
They add considerable complexity to frame-threading implementation,
which includes an unavoidably leaking error path, while the advantages
of this option to the users are highly dubious.
It should be always possible and desirable for the callers to make their
get_buffer2() implementation thread-safe, so deprecate this option.
We now have the possibility of getting AVFrames here, and we should
not touch the muxer's codecpar after writing the header.
Results of FATE tests change as the MXF and Matroska muxers actually
write down the field/frame coding type of a stream in their
respective headers. Before this change, these values in codecpar
would only be set after the muxer was initialized. Now, the
information is also available for encoder and muxer initialization.
Additionally, reap the first rewards by being able to set the
color related encoding values based on the passed AVFrame.
The only tests that seem to have changed their results with this
change seem to be the MXF tests. There, the muxer writes the
limited/full range flag to the output container if the encoder
is not set to "unspecified".
- For video, this means a single initialization point in do_video_out.
- For audio we unfortunately need to do it in two places just
before the buffer sink is utilized (if av_buffersink_get_samples
would still work according to its specification after a call to
avfilter_graph_request_oldest was made, we could at least remove
the one in transcode_step).
Other adjustments to make things work:
- As the AVFrame PTS adjustment to encoder time base needs the encoder
to be initialized, so it is now moved to do_{video,audio}_out,
right after the encoder has been initialized. Due to this,
the additional parameter in do_video_out is removed as it is no
longer necessary.
This way the old max queue size limit based behavior for streams
where each individual packet is large is kept, while for smaller
streams more packets can be buffered (current default is at 50
megabytes per stream).
For some explanation, by default ffmpeg copies packets from before
the appointed seek point/start time and puts them into the local
muxing queue. Before, it getting utilized was much less likely
since as soon as the filter chain was initialized, the encoder
(and thus output stream) was also initialized.
Now, since we will be pushing the encoder initialization to when the
first AVFrame is decoded and filtered - which only happens after
the exact seek point is hit as packets are ignored until then -
this queue will be seeing much more usage.
In more layman's terms, this attempts to fix cases such as where:
- seek point ends up being 5 seconds before requested time.
- audio is set to copy, and thus immediately begins filling the
muxing queue.
- video is being encoded, and thus all received packets are skipped
until the requested time is hit.
The AVFilterInOuts normally get freed in init_output_filter() when
the corresponding streams get created; yet if an error happens before
one reaches said point, they leak. Therefore this commit makes
ffmpeg_cleanup free them, too.
Fixes ticket #8267.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Threaded input can increase smoothness of e.g. x11grab significantly. Before
this patch, in order to activate threaded input the user had to specify a
"dummy" additional input, with this change it is no longer required.
Signed-off-by: Marton Balint <cus@passwd.hu>
This can support encoders which want frames and/or device contexts. For
the device case, it currently picks the first initialised device of the
desired type to give to the encoder - a new option would be needed if it
were necessary to choose between multiple devices of the same type.
Each time the sub2video structure is initialized, the sub2video
subpicture is initialized together with the first received heartbeat.
The heartbeat's PTS is utilized as the subpicture start time.
Additionally, add some documentation on the stages.
Fixes: signed integer overflow: -9223372036854775808 - 9223372036854775807 cannot be represented in type 'long'
Fixes: Ticket8142
Found-by: Suhwan
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For audio packets with dts != AV_NOPTS_VALUEs the dts was converted
twice to the muxer's timebase during streamcopy, once as a normal
packet and once specifically as an audio packet. This has been changed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
CPB side_data is copied when stream-copying (see init_output_stream_streamcopy()),
but it shall not be copied when the stream is decoded.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Freeing this was forgotten in ad899522.
Fixes#8315 and #8316.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
do_streamcopy() has a packet that gets zero-initialized first, then gets
initialized via av_init_packet() after which some of its fields are
oerwritten again with the actually desired values (unless it's EOF): The
side data is copied into the packet with av_copy_packet_side_data() and
if the source packet is refcounted, the packet will get a new reference
to the source packet's data. Furthermore, the flags are copied and the
timestamp related fields are overwritten with new values.
This commit replaces this by using av_packet_ref() to both initialize
the packet as well as populate its fields with the right values (unless
it's EOF again in which case the packet will still be initialized). The
differences to the current approach are as follows:
a) There is no call to a deprecated function (av_copy_packet_side_data())
any more.
b) Several fields that weren't copied before are now copied from the source
packet to the new packet (e.g. pos). Some of them (the timestamp related
fields) may be immediately overwritten again and some don't seem to be
used at all (e.g. pos), but in return using av_packet_ref() allows to forgo
the initializations.
c) There was no check for whether copying side data fails or not. This
has been changed: Now the program is exited in this case.
Using av_packet_ref() does not lead to unnecessary copying of data,
because the source packets are already always refcounted (they originate
from av_read_frame()).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch improves the logs when the message "cur_dts is invalid" appears.
If helps to identify which stream generates the trouble,
and the status of the stream.
A lot of users suffers with the message, and the origin varies.
The improved message can help to discover the cause.
Signed-off-by: Andreas Hakon <andreas.hakon@protonmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Right now, the code check for no filter description, but if we use a
filter_complex, the code will use the AVFrame.duration which could be
wrong in case of using fps filter.
How to reproduce the problem:
ffmpeg -f lavfi -i testsrc=duration=1 -vf fps=fps=50 -vsync 1 -f null -
output 50 frames
ffmpeg -f lavfi -i testsrc=duration=1 -filter_complex fps=fps=50 -vsync 1 -f null -
output 51 frames
With this commit, the same command will always output 50 frames.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
PTS is in microseconds, so correct field name is out_time_us.
Old field out_time_ms kept for now - will be removed after a suitable transition
period.
Fixes#7345
The input thread needs to be properly cleaned up and re-initalized before we
can start reading again in threaded mode. (Threaded input reading is used when
there is mode than one input file).
Fixes ticket #6121 and #7043.
Signed-off-by: Marton Balint <cus@passwd.hu>
Regression since: af1761f7
Fixes: Division by 0
Fixes: ffmpeg_crash_1
Found-by: Thuan Pham, Marcel Böhme, Andrew Santosa and Alexandru Razvan Caciulescu with AFLSmart
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Forced key frames generation functionality was assuming the first PTS
value as zero, but, when 'copyts' is enabled, the first PTS can be any
big number. This was eventually forcing all the frames as key frames.
To resolve this issue, update has been made to use first input pts as
reference pts.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes stream field order written by avformat_write_header when "top"
option is specified on the command-line.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Useful when transcoding videos at 29.97 fps because delivers a more accurate result for monitoring.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The -benchmark and -benchmark_all options now show user, system, and real time,
instead of just user time.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is used to signal that image should be stored in metadata
as cover image.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avdevice_register_all() is still required to register devices into
lavf (this is required due to lavd being somewhat of a hack).
Signed-off-by: Josh de Kock <josh@itanimul.li>
With certain types of input and the filter chain getting re-initialized
or re-configured, multiple nullptr AVSubtitles can get pushed into
sub2video_update() in a row from sub2video_heartbeat.
This causes end_pts, and on the next round pts, to become INT64_MAX,
latter of which signals EOF in framesync, leading to complete loss of
subtitles from that point on.
Thus, check that the sub2video.end_pts is smaller than INT64_MAX
in a similar fashion to sub2video_flush before sending out the
nullptr AVSubtitle. This keeps premature EOFs from happening in
framesync and the subtitle overlay is kept past the filter chain
re-initializations/configurations.
The generic code should be able to finish the streams just fine initializing
and flushing the filters and codecs properly.
Fixes the following command:
ffmpeg -f lavfi -i "testsrc=d=0.1[out0];aevalsrc=0:d=0[out1]" -af apad -shortest -f framecrc -
Signed-off-by: Marton Balint <cus@passwd.hu>
Should prevent unnecessary copy of data in cases where new references
to the packet are created within the muxer or a bitstream filter.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
It's been a noop for years, and it's been argued that in-band headers
should not be forcedly removed without the user's explicit request.
Also, as the FIXME line stated, this is a job for a bitstream filter
like extract_extradata, remove_extradata, dump_extradata, and
filter_units.
Signed-off-by: James Almer <jamrial@gmail.com>
When a decoded stream is being looped, after each post-EOF rewind,
decoders are flushed in seek_to_start(). This only drains 1 frame, and
thus the output has a few frames missing at the tail of each iteration
except the last.
With this patch, process_input is looped till process_input_packet
reaches EOF.
Fixes#7081
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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.
* commit 'a58873b11198d04670b7f98f5a8a749d742db7c5':
avconv: when using -loop option bail out if seek to start fails
Merged-by: James Almer <jamrial@gmail.com>
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.
* commit '91622f6446b463abe6507ad2cd5d1fbf7e49c424':
avconv: Always initialize the opkt struct on streamcopy
Merged-by: James Almer <jamrial@gmail.com>
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>
* commit 'c95169f0ec68bdeeabc5fde8aa4076f406242524':
build: Move cli tool sources to a separate subdirectory
Merged-by: James Almer <jamrial@gmail.com>
