The following commits will add a new buffering stage after bitstream
filters, which should not be taken into account for choosing next
output.
OutputStream.last_mux_dts is also used by the muxing code to make up
missing DTS values - that field is now moved to the muxer-private
MuxStream object.
The current placement of this free is historical - it used to be
followed by avcodec_close(), since removed.
The proper place for freeing the stats is currently right before the
encoder context itself is freed.
It is currently called from two places:
- output_packet() in ffmpeg.c, which submits the newly available output
packet to the muxer
- from of_check_init() in ffmpeg_mux.c after the header has been
written, to flush the muxing queue
Some packets will thus be processed by this function twice, so it
requires an extra parameter to indicate the place it is called from and
avoid modifying some state twice.
This is fragile and hard to follow, so split this function into two.
Also rename of_write_packet() to of_submit_packet() to better reflect
its new purpose.
The muxing queue currently lives in OutputStream, which is a very large
struct storing the state for both encoding and muxing. The muxing queue
is only used by the code in ffmpeg_mux, so it makes sense to restrict it
to that file.
This makes the first step towards reducing the scope of OutputStream.
Figure out earlier whether the output stream/file should be bitexact and
store this information in a flag in OutputFile/OutputStream.
Stop accessing the muxer in set_encoder_id(), which will become
forbidden in future commits.
The current code postpones closing the files until after printing the
final report, which accesses the output file size. Deal with this by
storing the final file size before closing the file.
Move the file size checking code to ffmpeg_mux. Use the recently
introduced of_filesize(), making this code consistent with the size
shown by print_report().
Move header_written into it, which is not (and should not be) used by
any code outside of ffmpeg_mux.
In the future this context will contain more muxer-private state that
should not be visible to other code.
This is a per-file input option that adjusts an input's timestamps
with reference to another input, so that emitted packet timestamps
account for the difference between the start times of the two inputs.
Typical use case is to sync two or more live inputs such as from capture
devices. Both the target and reference input source timestamps should be
based on the same clock source.
If either input lacks starting timestamps, then no sync adjustment is made.
These packets need not be writable (and are not modified by us),
so it is best to access them via const uint8_t*.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
regression since 13350e81fd
Fix looking for .ffmpeg subfolder in FFMPEG_DATADIR and inversely not in HOME.
Fix search order (documentation).
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Frame counters can overflow relatively easily (INT_MAX number of frames is
slightly more than 1 year for 60 fps content), so make sure we are always
using 64 bit values for them.
A live stream can easily run for more than a year and the framedup logic breaks
on an overflow.
Signed-off-by: Marton Balint <cus@passwd.hu>
GL and Metal cache the state at time of texture creation. GLES2 and
Direct3D 11 use the state at time of the render copy call.
So the only way we can get the correct behavior consistently is by
making sure the state is set for both the upload *and* the draw call.
This probably isn't our bug to fix (upstream should make itself behave
consistently and also document its functions), but as it stands,
`ffplay` is misrendering BT.709 as BT.601 on my stock Linux system, and
that leaves a bad taste in my mouth.
Signed-off-by: Niklas Haas <git@haasn.dev>
This enables printing to a resource specified with -o OUTPUT.
In case the output is not specified, prints to stdout as usual.
Address issue: http://trac.ffmpeg.org/ticket/8024
Signed-off-by: Marton Balint <cus@passwd.hu>
Option was added in commit 39aafa5ee9 but was never documented.
Also does not seem there are current use cases for it,
tests for which it was introduced are still working therefore we drop
it altogether.
Indirectly fix trac issue: http://trac.ffmpeg.org/ticket/1698
Signed-off-by: Marton Balint <cus@passwd.hu>
Fix JSON output in case a frame or packet section contains a nested section.
Fix trac issue http://trac.ffmpeg.org/ticket/8680.
Signed-off-by: Marton Balint <cus@passwd.hu>
This is a more appropriate place for this code, since the values we read
from AV_PKT_DATA_QUALITY_STATS side data are primarily written into
video stats. This ensures that the values written into stats actually
apply to the right packet.
Rename the function to update_video_stats() to better reflect its new
purpose.
It retrieves libavformat's internal dts value (contrary to the
function's name), which is not only incorrect in general, but also
unnecessary because we can access the packet directly.
Its use for muxing is not documented, in practice it is incremented per
each packet successfully passed to the muxer's write_packet(). Since
there is a lot of indirection between ffmpeg receiving a packet from the
encoder and it actually being written (e.g. bitstream filters, the
interleaving queue), using nb_frames here is incorrect.
Add a new counter for packets received from encoder instead.
Since every DLL can use an individual CRT on Windows, having
an exported function that opens a FILE* won't work if that
FILE* is going to be used from a different DLL (or from user
application code).
Internally within the libraries, the issue can be worked around
by duplicating the function in all libraries (this already happened
implicitly because the function resided in file_open.c) and renaming
the function to ff_fopen_utf8 (so that it doesn't end up exported from
the DLLs) and duplicating it in all libraries that use it.
This makes the avpriv_fopen_utf8 / ff_fopen_utf8 function work in
the exact same way as the existing avpriv_open / ff_open, with the
same setup as introduced in e743e7ae6e.
That mechanism doesn't work for external users, thus deprecate the
existing function.
Signed-off-by: Martin Storsjö <martin@martin.st>
Provide a header based inline reimplementation of it.
Using av_fopen_utf8 doesn't work outside of the libraries when built
with MSVC as shared libraries (in the default configuration, where
each DLL gets a separate statically linked CRT).
Signed-off-by: Martin Storsjö <martin@martin.st>
This field is currently used by checks
- skipping packets before the first keyframe
- skipping packets before start time
to test whether any packets have been output already. But since
frame_number is incremented after the bitstream filters are applied
(which may involve delay), this use is incorrect. The keyframe check
works around this by adding an extra flag, the start-time check does
not.
Simplify both checks by replacing the seen_kf flag with a flag tracking
whether any packets have been output by do_streamcopy().
Look for the generic "USR" labels instead of "?" to skip channels with no
known names, and actually print the decomposition of standard channel layouts.
Signed-off-by: James Almer <jamrial@gmail.com>
Especially useful when debugging subtitle output, but also shows
if values are set or not for demux and encoding.
Co-authored-by: Jan Ekström <jan.ekstrom@24i.com>
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
It allocates a dummy sws/swr context and tries setting options on it,
apparently to check if they are valid. This is redundant, since the
options will be checked if/when they are later applied on a context that
is actually used for conversion.
It tries to process any unhandled options as AVOptions. Handle this
directly in cmdutils.c, without resorting to a confusing fake option
definition (which is currently visible to the users in -help output).
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids including version.h in all source files, avoiding
unnecessary rebuilds when the version number is bumped. Only
version_major.h is included by the main header, which defines
availability of e.g. FF_API_* macros, and which is bumped much
less often.
This isn't done for libavutil/version.h, because that header needs
to be included essentially everywhere due to LIBAVUTIL_VERSION_INT
being used wherever an AVClass is constructed.
Signed-off-by: Martin Storsjö <martin@martin.st>
The earlier code has ignored it for all stream types except
video and subtitles, probably because audio was presumed
to only consist of keyframes. Yet this assumption is not true
for e.g. TrueHD.
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Bitstream filters inserted between the input and output were never drained,
resulting in packets being lost if the bsf had any buffered.
Signed-off-by: James Almer <jamrial@gmail.com>
A decoder is only opened if there is a decoder for the codec,
so every AVCodecContext here has AVCodecContext.codec set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is a prerequisite to continue using the decoder at all
to decode the next interval (if any).
This fixes a regression introduced in commit
2a88ebd096 and reported in ticket #8657.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes ticket 9086.
Since early 2021, some of YouTube's VP9 encodes have non-monotonous DTS.
This makes ffmpeg fatally fail when trying to copy or encode the V9 video.
ffmpeg already includes functionality to correct this, however it was
disabled without explanation for VP9 stream copies in
2e6636aa87
This patch restores the DTS correction logic, and allows ffmpeg to correctly
encode (invalid) videos produced by youtube.com. I have verified that frames
are NOT being cut (so it does not re-introduce 4313).
Reviwed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
At present, side data printing forces display for all levels i.e.
stream, packets and frames. This can bloat output and also force
decode of all frames in selected streams.
Now, stream_side_data[=type], packet_side_data[=type] &
frame_side_data[=type] can be used with -show_entries to specify carrier
element.
fftools now print info about what media type(s), if any, are provided by
sink and source avdevices.
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
The transpose filter has modes equivalent to "rotation by 90°/270°"
followed by horizontal flips.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In case of an orthogonal transformation av_display_rotation_get()
returns the (anticlockwise) degree that the unit vector in x-direction
gets rotated by; get_rotation in cmdutils.c makes a clockwise degree
out of this. So if one inserts a transpose filter corresponding to
this degree, then the x-vector gets mapped correctly and there are
two possibilities for image of the y-vector, namely the two unit
vectors orthogonal to the image of the x-vector.
E.g. if the x-vector gets rotated by 90° clockwise, then the two
possibilities for the y-vector are the unit vector in x direction
or its opposite. The latter case is a simple 90° rotation for both
vectors* whereas the former is a simple 90° clockwise rotation followed
by a horizontal flip. These two cases can be distinguished by looking
at the x-coordinate of the image of the y-vector, i.e. by looking
at displaymatrix[3]. Similarly for the case of a 270° clockwise
rotation.
These two cases were previously wrong (they were made to match
wrongly parsed exif rotation tag values).
*: For display matrices, the y-axis points downward.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If 'opts' could not be allocated, exiting the program to avoid crash when release it.
Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: Yu Yang <yuyang14@kuaishou.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If the input stream framerate is known, it will be configured on the
relevant filtergraph input and get propagated to the output stream in
the above line. That makes these assignments redundant.
Do this by switching from the dynamic buffer API to the AVBPrint API;
the former has no defined way to check for errors.
This also avoids allocating an AVIOContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by switching from the dynamic buffer API to the AVBPrint API;
the former has no defined way to check for errors.
This also avoids allocating an AVIOContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only caller of do_video_out() doesn't need the frame afterwards,
ergo one can replace an av_frame_ref() by av_frame_move_ref().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently, adding a (separately allocated) element to a list of pointers
works by first reallocating the array of pointers and (on success)
incrementing its size and only then allocating the new element.
If the latter allocation fails, the size is inconsistent, i.e.
array[nb_array_elems - 1] is NULL. Our cleanup code crashes in such
scenarios.
Fix this by adding an auxiliary function that atomically allocates
and adds a new element to a list of pointers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
choose_pix_fmts() used the dynamic buffer API to write strings;
as is common among uses of this API, only opening the dynamic buffer
was checked, but not the end result, leading to crashes in case
of allocation failure.
Furthermore, some static strings were duplicated; the allocations
performed here were not properly checked: Allocation failure would
be treated as "could not determine pixel format".
The first issue is fixed by switching to the AVBPrint API which allows
to easily perform checks at the end. Furthermore, the internal buffer
avoids almost all allocations in case the AVBPrint is used.
The AVBPrint also allows to solve the second issue in an elegant way,
because it allows to return the static strings directly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not really natural, it requires internal allocations
of its own and its error handling is horrible (i.e. the implicit
(re)allocations here are unchecked).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Don't mark all streams as finished, instead make sync_opts keep track of the
stream's duration, and set recording_time to it, same as in transcoding paths.
Fixes tickets #9512 and #9513.
Signed-off-by: James Almer <jamrial@gmail.com>
This was almost completely redundant. The only functionality that's no longer
available after this removal is the videotoolbox_pixfmt arg, which has been
obsolete for several years.
The types used by the AVFifo API are inconsistent:
av_fifo_(space|size)() returns an int; av_fifo_alloc() takes an
unsigned, other parts use size_t. This commit therefore ensures
that the size of the muxing_queue FIFO never exceeds INT_MAX.
While just at it, also make sure not to call av_fifo_size()
unnecessarily often.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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.
Anton Khirnov
Timo Rothenpieler
Gyan Doshi
Andreas Rheinhardt
Nicolas Gaullier
Marton Balint
Niklas Haas
Nil Admirari
softworkz
Stefano Sabatini
Martin Storsjö
James Almer
Jaakko Perttilä
Zhao Zhili
Limin Wang
Danny Wu
Jan Ekström
Diederick Niehorster
Yu Yang
rcombs
Chad Fraleigh
Paul B Mahol