send_frame_to_filters() sends a frame to all the filters that
need said frame; for every filter except the last one this involves
creating a reference to the frame, because
av_buffersrc_add_frame_flags() by default takes ownership of
the supplied references. Yet said function has a flag which
changes its behaviour to create a reference itself.
This commit uses this flag and stops creating the references itself;
this allows to remove the spare AVFrame holding the temporary
references; it also avoids unreferencing said frame.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
As well as the custom get_buffer2() implementation which would become a
redundant wrapper for avcodec_default_get_buffer2() after this
Signed-off-by: James Almer <jamrial@gmail.com>
Treat values returned from av_dict_get() as const, since they are
internal to AVDictionary.
Signed-off-by: Chad Fraleigh <chadf@triularity.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently, the code doing this is spread over several places and may
behave in unexpected ways. E.g. automatic 'default' marking is only done
for streams fed by complex filtergraphs. It is also applied in the order
in which the output streams are initialized, which is effectively
random.
Move processing the dispositions at the end of open_output_file(), when
we already have all the necessary information.
Apply the automatic default marking only if no explicit -disposition
options were supplied by the user, and apply it to the first stream of
each type (excluding attached pics) when there is more than one stream
of that type and no default markings were copied from the input streams.
Explicitly document the new behavior.
Changes the results of some tests, where the output file gets a default
disposition, while it previously did not.
When viewing logs, it's sometimes useful to be able to see whether
execution was ended via q command.
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
avcodec_receive_packet() already unreferences the packet on its own.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The output stream's packet may not have been allocated
at that point. This happens when quitting in the following command line:
$ ./ffmpeg -lavfi abuffer=sample_fmt=u8:sample_rate=48000:channel_layout=stereo -f null -
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Unnecessary since 1f63665ca5, because
the value the option is set to coincides with the default value.
Found-by: Soft Works <softworkz@hotmail.com>
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This reverts commit 628a73f8f3.
At the time of said commit there was talk of removing the audio bitrate
"ab" option to bring FFmpeg in line with what Libav has done in 2012 in
commit 041cd5a0c5. By having different
option flags for the "ab" and the ordinay bitrate "b" option is is
possible to have different default bitrates for audio and video. In
order to maintain this behaviour and not break user scripts the commit
to be reverted added code to ffmpeg.c that set the bitrate value to the
audio default for audio codecs, but only if AVCodec.defaults didn't
exist (as in this case the default would be codec-default and not
affected by the "ab" removal).
This had the downside of being an API violation, because
AVCodec.defaults is not a public field. Given that the "ab" option
and its audio-specific default value have never been removed,
said API violation can be simply fixed by reverting said commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This way the CLI accepts for "filter_threads" the same values as for the
libavcodec specific option "threads".
Fixes FATE with THREADS=auto which was broken in bdc1bdf3f5.
Signed-off-by: James Almer <jamrial@gmail.com>
These were intended to pass options to auto-inserted avresample
resampling filters. Yet FFmpeg uses swresample for this purpose
(with its own AVDictionary swr_opts similar to resample_opts).
Therefore said options were not forwarded any more since commit
911417f0b34e611bf084319c5b5a4e4e630da940; moreover since commit
420cedd497 avresample options are
not even recognized and ignored any more. Yet there are still
remnants of all of this. This commit gets rid of them.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Having the override before autodetection meant that the overridden
value got overwritten by the autodetected result each time,
effectively disabling the ability to utilize the `-top` option
for override purposes.
Somehow I missed this in fbb44bc51a ,
even though the lines were within the context. Probably the code
originally being after this logic had something to do with it,
but previously it only touched the avformat context's codecpar,
which did not affect the encoder codec context whatsoever.
Fixes#9320Fixes#9339
Read rate enforcement delayed till first decoded frame is obtained, to
speed up init of output streams.
Thanks to Linjie Fu <linjie.justin.fu@gmail.com> for the initial patch.
if input start time is not 0 -t is inaccurate doing stream copy,
will record extra duration according to input start time.
it should base on following cases:
input video start time from 60s, duration is 300s,
1. stream copy:
ffmpeg -ss 40 -t 60 -i in.mp4 -c copy -y out.mp4
open_input_file() will seek to 100 and set ts_offset to -100,
process_input() will offset pkt->pts with ts_offset to make it 0,
so when do_streamcopy() with -t, exits when ist->pts >= recording_time.
2. stream copy with -copyts:
ffmpeg -ss 40 -t 60 -copyts -i in.mp4 -c copy -y out.mp4
open_input_file() will seek to 100 and set ts_offset to 0,
process_input() will keep raw pkt->pts as ts_offset is 0,
so when do_streamcopy() with -t, exits when
ist->pts >= (recording_time+f->start_time+f->ctx->start_time).
3. stream copy with -copyts -start_at_zero:
ffmpeg -ss 40 -t 60 -copyts -start_at_zero -i in.mp4 -c copy -y out.mp4
open_input_file() will seek to 120 and set ts_offset to -60 as start_to_zero option,
process_input() will offset pkt->pts with input file start time,
so when do_streamcopy() with -t, exits when ist->pts >= (recording_time+f->start_time).
0 60 40 60 360
|_______|_____|_______|_______________________|
start -ss -t
This fixes ticket #9141.
Signed-off-by: Shiwang.Xie <shiwang.xie666@outlook.com>
Otherwise the rate emulation logic in `transcode_step` never gets
hit, and the unavailability flag never gets reset, leading to an
eternal loop with some rate emulation use cases.
This change was missed during the rework of ffmpeg.c, in which
encoder initialization was moved further down the time line in
commit 67be1ce0c6 . Previously,
as the encoder initialization had happened earlier, this state was
not possible (flow getting as far as hitting the rate emulation logic,
yet not having the encoder initialized yet).
Fixes#9160
The obstacle to do so was in filter_codec_opts: It uses searches
the AVCodec for options via the AV_OPT_SEARCH_FAKE_OBJ method, which
requires using a void * that points to a pointer to a const AVClass.
When using const AVCodec *, one can not simply use a pointer that points
to the AVCodec's pointer to its AVClass, as said pointer is const, too.
This is fixed by using a temporary pointer to the AVClass.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It only affects the old and deprecated avcodec_decode_(video2|audio4)
API which is no longer used here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
As per signal() help (man 2 signal) the semantics of using signal may
vary across platforms. It is suggested to use sigaction() instead.
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
The first stats is printed after the initial stats_period has elapsed. With a large period,
it may appear that ffmpeg has frozen at startup.
The initial stats is now printed after the first transcode_step.
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>
