Sort options by name, review formatting, apply consistency fixes and
fill the gaps (e.g. missing value for constants or flags), and review
and extend content.
The C library function double atan2(double y, double x) takes y as the first
parameter and x as the second parameter.
Signed-off-by: Haixia Shi <hshi@meta.com>
Signed-off-by: Marth64 <marth64@proxyid.net>
Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
used open source tool for processing 608/708 closed caption (CC) sources.
It can be used to archive the original, raw CC bitstream and to produce
a source file file for later CC processing or conversion. As a result,
it also allows for interopability with ccextractor for processing CC data
extracted via ffmpeg. The format is simple to parse and can be used
to retain all lines and variants of CC.
A free specification of RCWT can be found here:
https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT
This muxer implements the specification as of 01/05/2024, which has
been stable and unchanged for 10 years as of this writing.
This muxer will have some nuances from the way that ccextractor muxes RCWT.
No compatibility issues when processing the output with ccextractor
have been observed as a result of this so far, but mileage may vary
and outputs will not be a bit-exact match.
Specifically, the differences are:
(1) This muxer will identify as "FF" as the writing program identifier, so
as to be honest about the output's origin.
(2) ffmpeg's MPEG-1/2, H264, HEVC, etc. decoders extract closed captioning
data differently than ccextractor from embedded SEI/user data.
For example, DVD captioning bytes will be translated to ATSC A53 format.
This allows ffmpeg to handle 608/708 in a consistant way downstream.
This is a lossless conversion and the meaningful data is retained.
(3) This muxer will not alter the extracted data except to remove invalid
packets in between valid CC blocks. On the other hand, ccextractor
will by default remove mid-stream padding, and add padding at the end
of the stream (in order to convey the end time of the source video).
This was accidentally removed in a prior revision of the series,
alongside the corresponding (separate) version bump. Instead coalesce it
into the follow-up commit's entry, since that's the lowest version
actually supporting the new fields.
Move section to the top of the file, use table in place of subsection
to list the comprising muxers, and show media type information and
extensions in the item entry names.
To allow adding proper negotiation, in particular, to fftools.
These values will simply be negotiated downstream for YUV formats, and
ignored otherwise.
Motivated by YUVJ removal. This change will allow full negotiation
between color ranges and matrices as needed. By default, all ranges and
matrices are marked as supported.
Because grayscale formats are currently handled very inconsistently (and
in particular, assumed as forced full-range by swscale), we exclude them
from negotiation altogether for the time being, to get this API merged.
After filter negotiation is available, we can relax the
grayscale-is-forced-jpeg restriction again, when it will be more
feasible to do so without breaking a million test cases.
Note that this commit updates one FATE test as a consequence of the
sanity fallback for non-YUV formats. In particular, the test case now
writes rgb24(pc, gbr/unspecified/unspecified) to the matroska file,
instead of rgb24(unspecified/unspecified/unspecified) as before.
Some encoders (e.g., libx264) dump encoder configuration as user
data unregistered SEI message. This option try to print it as
ascii character when possible.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This can be used to run tests multple times, with e.g. differing
QEMU settings, by adding something like this to the FATE configuration
file:
target_exec="qemu-aarch64-static"
fate_targets="fate-checkasm fate-cpu"
fate_environments="sve128 sve256 sve512"
sve128_env="QEMU_CPU=max,sve128=on"
sve256_env="QEMU_CPU=max,sve256=on"
sve512_env="QEMU_CPU=max,sve512=on"
It's also possible to customize the target_exec command further
by injecting a sufficiently quoted variable into it, which then can
be updated for each run, e.g. target_exec="\$(CUR_EXEC_CMD)".
For each of the environment names in fate_environments, the tests
that are run get the name suffixed on the fate tests in the
test log and fate report, e.g. "fate-checkasm-h264dsp_sve128".
Signed-off-by: Martin Storsjö <martin@martin.st>
This can be useful if doing testing of uncommon CPU extensions by
running tests with QEMU (by configuring with e.g.
"target_exec=qemu-aarch64"), by only running the checkasm tests,
to get a reasonable test coverage without excessive test runtime.
For such a config, setting fate_targets="fate-checkasm fate-cpu"
can be a good tradeoff.
Signed-off-by: Martin Storsjö <martin@martin.st>
The {br}/{abr} directives are not limited to post-encoding, they can
also be used pre-muxing. The already-present {packet} tag describes this
more accurately, so just drop the assertions.
x11grab can capture windows by their ID, but gdigrab can only capture
windows by their names, internally calling FindWindowW to lookup its
handle.
This patch simply allows the user to specify a window handle directly.
Signed-off-by: Lena <lena@nihil.gay>
3d29724c00 removed the doc entry for the option pool while adding
a parser function for it at the same time!
The option remains available and undeprecated.
Fixes trac #10693
Texinfo 7.0 produces quite different HTML to Texinfo 6.8. Without
this change, enumerated option flags (i.e. Possible values of x
are...) render as white text on a white background with Texinfo 7.0
and are unreadable. This change removes a style for the selector
`.table .table` which causes the background to turn white for these
elements. As far as I can tell, it is not actually used anywhere in
files generated by Texinfo 6.8.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Resolves trac ticket #10636 (http://trac.ffmpeg.org/ticket/10636).
Texinfo 7.0, released in November 2022, changed the names of various
functions. Compiling docs with Texinfo 7.0 resulted in warnings and
improperly formatted documentation. More old names appear to have
been removed in Texinfo 7.1, released October 2023, which causes docs
compilation to fail.
This commit addresses the issue by adding logic to switch between the old
and new function names depending on the Texinfo version. Texinfo 6.8
produces identical documentation before and after the patch.
CC
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1938238.htmlhttps://bugs.gentoo.org/916104
Signed-off-by: Frank Plowman <post@frankplowman.com>
By intent, and in practice, the "active contributor" criterion applies
to the person authoring the commits, not the one pushing them into the
repository.
Partially fixes ticket #798
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Peter Ross <pross@xvid.org>
The `-caption_encoding` option was reported as having a default value of
'ass', whereas it's actually 'auto'.
Signed-off-by: zheng qian <xqq@xqq.im>
Signed-off-by: Gyan Doshi <ffmpeg@gyani.pro>
There are already several places in the codebase that match desc->name
against "xyz", and many downstream clients replicate this behavior.
I have no idea why this is not just a flag.
Motivated by my desire to add yet another check for XYZ to the codebase,
and I'd rather not keep copy/pasting a string comparison hack.
This should hopefully clarify that the option only affects MSZ
full-width characters, and not all full-width ASCII. Additionally,
this matches the prefix with the upstream option.
Signed-off-by: TADANO Tokumei <aimingoff@pc.nifty.jp>
This patch adds two MSZ (Middle Size; half width) character
related options, mapping against newly added upstream
functionality:
* `replace_msz_japanese`, which was introduced in version 1.0.1
of libaribcaption.
* `replace_msz_glyph`, which was introduced in version 1.1.0
of libaribcaption.
The latter option improves bitmap type rendering if specified
fonts contain half-width glyphs (e.g., BIZ UDGothic), even
if both ASCII and Japanese MSZ replacement options are set
to false.
As these options require newer versions of libaribcaption, the
configure requirement has been bumped accordingly.
Signed-off-by: TADANO Tokumei <aimingoff@pc.nifty.jp>
Mapping to ITU-R BS.2051-3 "Sound System J" and ITU-R BS.1196-8 "Channel
Configuration 19".
Signed-off-by: Will Wolcott <wwolcott@netflix.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8 "Channel
Configuration 14", and it being the first layout with top layer channels, it's
best to use a different scheme to properly convey the presence and amount of said
channels.
The new name will also be a better fit for the additions in the following commits.
Signed-off-by: James Almer <jamrial@gmail.com>
The vidstab library added support in Nov 2020 for writing/reading
the transforms data in binary in addition to ASCII. The library default
was changed to binary format but no changes were made to the AVfilters
resulting in data file for writing or reading being always opened as text.
This effectively broke the filters.
Option added to vidstabdetect to specify file format and open files in
both filters with the correct attributes.
It is unnecessary since the removal of non-thread-safe callbacks
in e0786a8eeb. Since then, the
AVCodecContext has only been used as logcontext.
Removing ff_thread_release_buffer() allowed to remove AVCodecContext*
parameters from several other functions (not only unref functions,
but also e.g. ff_h264_ref_picture() which calls ff_h264_unref_picture()
on error).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fix rendering of int values within a side data element, which was
broken since commit d2d3a83ad9, where the side data element was
correctly marked as a variable fields element. Logic to render a
string variable was implemented already, but it was not implemented
for the int fields path, which was enabled by that commit.
Also, code and schema is changed in order to account for multiple
variable-fields elements - such as side data, contained within the
same parent. Previously it was assumed that a single variable-fields
element was contained within the parent, which was the case for tags,
but is not the case for side-data.
Previously data was rendered as:
<side_data_list>
<side_data side_data_type="CPB properties" max_bitrate="0" min_bitrate="0" avg_bitrate="0" buffer_size="327680" vbv_delay="-1"/>
</side_data_list>
Now as:
<side_data_list>
<side_data type="CPB properties">
<side_datum key="side_data_type" value="CPB properties"/>
<side_datum key="max_bitrate" value="0"/>
<side_datum key="min_bitrate" value="0"/>
<side_datum key="avg_bitrate" value="0"/>
<side_datum key="buffer_size" value="49152"/>
<side_datum key="vbv_delay" value="-1"/>
</side_data>
</side_data_list>
Variable-fields elements are rendered as a containing element wrapping
generic key/values elements, enabling use of strict XML schema.
Fix trac issue:
https://trac.ffmpeg.org/ticket/10613
Always use the functionality of the latter, which makes more sense as it
avoids losing keyframes due to vsync code dropping frames.
Deprecate the 'source_no_drop' value, as it is now redundant.
Deprecate AVStream.side_data and its helpers in favor of the AVStream's
codecpar.coded_side_data.
This will considerably simplify the propagation of global side data to decoders
and from encoders. Instead of having to do it inside packets, it will be
available during init().
Global and frame specific side data will therefore be distinct.
Signed-off-by: James Almer <jamrial@gmail.com>
This will simplify the propagation of side data to decoders and from encoders.
Global side data will now reside in the AVCodecContext, thus be available
during init(), removing the need to propagate it inside packets.
Global and frame specific side data will therefore be distinct.
Signed-off-by: James Almer <jamrial@gmail.com>
Handling AVPacketSideData directly, which can used on structs other than
AVPacket.
This will be useful in the following commits.
Signed-off-by: James Almer <jamrial@gmail.com>
Drop reference to constants removed in 94eed68ace.
In particular, rename me_method to me_quality and add description for
supported values.
Address trac issue:
http://trac.ffmpeg.org/ticket/10003
In particular, clarify that it can either be set as a field of
AVCodecContext or as an x264 option, using a different specification.
Should address trac issue:
http://trac.ffmpeg.org/ticket/3947
It dates back to pre-2005 days, when people generally tended to commit
their work directly without going through the mailing list. Few
developers do it today, and never outside of their standalone modules.
This item is thus confusing and misleading and is better removed.
The section consistes of a single short paragraph linking to other
chapters. The enclosing chapter also has no other sections, all other
text is placed in the chapter directly.
Keeping a separate section for this paragraph just adds more clutter.
It is also used by AVCodecContext.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is of no value to the user, because every muxer can always
be flushed with a NULL packet. As its documentation shows
("If not set, the muxer will not receive a NULL packet in
the write_packet function") it is actually an internal flag
that has been publically exposed because there was no internal
flags field for output formats for a long time. But now there is
and so use it by replacing the public flag with a private one.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They were replaced by TX from libavutil; the tremendous work
to get to this point (both creating TX as well as porting
the users of the components removed in this commit) was
completely performed by Lynne alone.
Removing the subsystems from configure may break some command lines,
because the --disable-fft etc. options are no longer recognized.
Co-authored-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ISO C++ forbids compound-literals. It's not available with MSVC.
This is a known issue from 10 years ago, and that's why there is a
av_get_time_base_q().
Since we have no plan to remove AV_TIME_BASE_Q, just make it
available in C++.
There are multiple choices:
1. Use C++11 syntax: AVRational{1, AV_TIME_BASE}
Users may still use C++98 to write new code. So no.
2. Use av_get_time_base_q().
It's for this purpose. But it's not compile time constants as
AV_TIME_BASE_Q in C.
So I choose av_make_q() as Anton's suggestion.
https://libav-devel.libav.narkive.com/ZQCWfTun/patch-0-2-fix-avutil-h-usage-from-c
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
It is badly named (should have been -top_field_first, or at least -tff),
underdocumented and underspecified, and (most importantly) entirely
redundant with the setfield filter.
It was added in cb114ed464 with the comment
"This will allow fixing several bugs with the -shortest option".
Since
* there is no explanation of what these bugs are
* libavformat is not the place to work around ffmpeg CLI bugs
* there is no indication that this feature is actually in use
deprecate it without replacement.
For badly interleaved files, interleave packets from multiple tracks
at the demuxer level can trigger seeking back and forth, which can be
dramatically slow depending on the protocol. Demuxer level interleave
can be useless sometimes, e.g., reading mp4 via http and then
transcoding/remux to DASH. Disable this option when you don't need the
demuxer level interleave, and want to avoid the IO penalizes.
Co-authored-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
av_image_copy() accepts const uint8_t* const * as source;
lots of user have uint8_t* const * and therefore either
cast (the majority) or copy the array of pointers.
This commit changes this by adding a static inline wrapper
for av_image_copy() that casts between the two types
so that we do not need to add casts everywhere else.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also constify AVAudioFifo* in the peek functions
besides constifying intermediate pointers (void**->void * const *).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is done immediately without waiting for the next major bump
just as in 9546b3a1cb and
4eaaa38d3d.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are currently non-const for reasons unknown, although
avio_write() accepts a const buffer.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These defines are also used in other contexts than just AVCodecContext
ones, e.g. in libavformat. Furthermore, given that these defines are
public, the AV-prefix is the right one, so deprecate (and not just move)
the FF-macros.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This reverts commit eb88ccb92e.
AVCodecContext fields are the proper place for a decoder to export such values.
This change is in preparation for the following commits.
add option named rtmp_enhanced_codec,
it would support hvc1,av01,vp09 now,
the fourcc is using Array of strings.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
These are in-place transforms, required for DCT-I and DST-I.
Templated as the mod2 variant requires minor modifications, and is
required specifically for DCT-I/DST-I.
Can be used to configure libplacebo's underlying raw options, which
sometimes includes new or advanced / in-depth settings not (yet) exposed
by vf_libplacebo.
C++ doesn't support designated initializers until C++20. We have
a bunch of pre-defined channel layouts, the gains to make them
usable in C++ exceed the losses.
Bump minor version so C++ project can check before use these defines.
Also initialize .opaque field explicitly to reduce warning in C++.
Signed-off-by: James Almer <jamrial@gmail.com>
The commits eac4324bfb and
cd8211527e renamed the examples, but the
targets were not updated. Hence, the builds are missing -lm.
Signed-off-by: Sebastian Ramacher <sramacher@debian.org>
Signed-off-by: James Almer <jamrial@gmail.com>
Stefano Sabatini
Connor Worley
Haihao Xiang
Anton Khirnov
Haixia Shi
Marth64
Niklas Haas
Thilo Borgmann
Zhao Zhili
Vittorio Giovara
Wu Jianhua
Martin Storsjö
James Almer
hung kuishing
Lena
Marton Balint
Jean-Baptiste Kempf
Paul B Mahol
Gyan Doshi
Michael Niedermayer
Dawid Kozinski
Diederik de Haas via ffmpeg-devel
Frank Plowman
Peter Ross
zheng qian
TADANO Tokumei
Will Wolcott
Andreas Rheinhardt
Kyle Swanson
Roman Arzumanyan
Chema Gonzalez
Fei Wang
Steven Liu
Nuo Mi
Lynne
Elias Carotti
Sebastian Ramacher
Tobias Rapp