Many filters modify certain aspects of frame data, e.g. through resizing
(vf_*scale* family), color volume mapping (vf_lut*, vf_tonemap*), or
possibly others.
When this happens, we should strip all frame side data that will no
longer be correct/relevant after the operation. For example, changing
the image size should invalidate AV_FRAME_DATA_PANSCAN because the crop
window (given in pixels) no longer corresponds to the actual image size.
For another example, tone-mapping filters (e.g. from HDR to SDR) should
strip all of the dynamic HDR related metadata.
Since there are a lot of different side data types that are affected by such
operations, it makes sense to establish this information in a common, easily
accessible way. The existing side data properties enum is a perfect fit for
this.
This setting can be used to infuence the type of tone and gamut mapping used
internally when color space conversions are required. As discussed at VDD'24,
the default was set to relative colorimetric clipping, which is approximately
associative, surjective and idempotent. As such, it roundtrips well, although
it is strictly speaking not associative on out-of-gamut colors.
This can be useful in other places, e.g. it can replace objpool in
fftools.
The API is modified in the following nontrivial ways:
* opaque pointers can be passed through to all user callbacks
* read and write were previously separate callbacks in order to
accomodate the caller wishing to write a new reference to the FIFO and
keep the original one; the two callbacks are now merged into one, and
a flags argument is added that allows to request such behaviour on a
per-call basis
* new peek and drain functions
Currently, ffprobe has two stream-level fields that do not work,
closed_captions and film_grain).
Their value is always 0 because ffprobe cannot access the internal
codec properties when it is setting up its stream contexts.
In this commit, add the new option -analyze_frames to ffprobe,
allowing the user to read frames up to the interval they have defined
and fill these fields based on what is exposed in AVPacketSideData.
Additionally, in the same commit, don't write these fields to
the output unless analyze_frames is enabled. Finally, fix the
FATE test refs accordingly and update the docs.
Signed-off-by: Marth64 <marth64@proxyid.net>
If running tests with "make -j<N> fate", the execution will stop
after the first failing test. To get an overview of the whole
test suite, one rather would run "make -k -j<N> fate", which then
again buries the results about what tests actually failed further
up in the console log.
Add a target so one can run "make fate-list-failing", to see a list
of all tests that failed the last time they were executed.
Also add a companion target "fate-clear-reports" which removes all
the old test reports. (When executing a subset of tests, the report
files of all tests that aren't executed stay untouched. This also
allows getting rid of reports for tests that no longer are present
in the testsuite.)
Co-authored-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Martin Storsjö <martin@martin.st>
The existing av_csp_trc_func_from_id() mostly implements the OETF, except for
PQ. As such, we are currently missing a precise definition of an ITU-R EOTF.
Introduce the new functions av_csp_itu_eotf() and av_csp_itu_eotf_inv(), to fill
this void. Note that this is not possible in all cases, e.g. AVCOL_TRC_LOG which
has no corresponding EOTF definition in any ITU-R standard.
Note that we cannot implement the proper HLG and SMPTE 428 OOTFs without access
to all three color channels, because they are not independent per channel. As a
result, we need to define them on double[3] instead of double (*func)(double).
Makes it easier to immediately see if the code examples given in the
style documentation are good or bad examples, making it harder to
accidentally confuse a bad example for a good one.
Given the frequency that new developers, myself included, get the
code style wrong, it is useful to add some examples to clarify how
things should be done.
As part of a larger, ongoing effort to modernize and partially rewrite
libswscale, it was decided and generally agreed upon to introduce a new
public API for libswscale. This API is designed to be less stateful, more
explicitly defined, and considerably easier to use than the existing one.
Most of the API work has been already accomplished in the previous commits,
this commit merely introduces the ability to use sws_scale_frame()
dynamically, without prior sws_init_context() calls. Instead, the new API
takes frame properties from the frames themselves, and the implementation is
based on the new SwsGraph API, which we simply reinitialize as needed.
This high-level wrapper also recreates the logic that used to live inside
vf_scale for scaling interlaced frames, enabling it to be reused more easily
by end users.
Finally, this function is designed to simply copy refs directly when nothing
needs to be done, substantially improving throughput of the noop fast path.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Group them into an enum rather than random #defines, and document their
behavior a bit more obviously.
Of particular note, I discovered that SWS_DIRECT_BGR is not referenced
anywhere else in the code base. As such, I have moved it to the deprecated
section, alongside SWS_ERROR_DIFFUSION.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Following in the footsteps of the work in the previous commit, it's now
relatively straightforward to expose the options struct publicly as
SwsContext. This is a step towards making this more user friendly, as
well as following API conventions established elsewhere.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This avoids unpleasant surprises to av_frame_get_buffer callers
that explicitly specified 64-byte alignment and didn't get
AVFrame.data pointers that are 64-byte aligned.
For example, see https://github.com/sekrit-twc/zimg/issues/212
Although the zscale issue has already been resolved by other means
it would still be prudent to improve the behavior of av_frame_get_buffer
to fix any unknown and future instances of similar issues.
Co-authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The "auto" mode serves no functional purpose except for logging
a message and setting the value to 1. The documentation clearly
explains what the option is for.
Signed-off-by: Marth64 <marth64@proxyid.net>
Menu 0 is the VIDEO_TS root menu, which does not appear to be used
commonly for menu segments. Instead, default to the menu of VTS 1.
Signed-off-by: Marth64 <marth64@proxyid.net>
Menus are generally segmented by cell, so use them as the
marker delimiters. Requires preindex option to be enabled.
Signed-off-by: Marth64 <marth64@proxyid.net>
The default "auto" mode is effectively useless; the reasonable
default use case is to use the first PG (segment) of the
selected PGC for both menus and standard titles. Just
default the value to 1, since the option is irrelevant
unless -pgc is also set.
Note that this should not break users using this advanced option.
The "auto" mode errored and asked for a PG number regardless
for non-menus, and for menus the mode simply defaulted to 1.
Signed-off-by: Marth64 <marth64@proxyid.net>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Peter Ross <pross@xvid.org>
Much like XV30 and XV36 in d75c4693fef51e8f0a1b88798530f4c5147ea906,
XV48 is added to support 16bit 4:4:4 as defined by Microsoft.
Signed-off-by: James Almer <jamrial@gmail.com>
-disposition:
Clarify the meaning of the default value, and how the '+' and '-'
prefixes work. Add more examples.
-stats:
Clarify that it appears as an "info"-level log.
-progress:
Add info about the "progress" key's value being "continue" or "end".
Add an example of logging to stdout.
Signed-off-by: Soma Lucz <luczsoma@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Replacing the old sws_isSupported* API with a more consistent family
of functions that follows the same signature and naming convention,
including a placeholder for testing the color space parameters that
we don't currently implement conversions for.
These functions also perform some extra basic sanity checking.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Merely a convenience wrapper around sws_freeContext(). The name change is for
parity with the other sws_* functions.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
If 'sname:*' is set in the var_stream_map variable, use it as
the NAME attribute for subtitles. This improves the naming of
subtitle streams in HTML players, providing clearer and more
descriptive labels for users.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Split it into sections that describe in detail
* the components of the transcoding pipeline
* the main features it handles, in order of complexity
* streamcopy
* transcoding
* filtering
Replace the current confusing/misleading diagrams with new ones that
actually reflect the program components and data flow between them.
