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>
The PNGv3 Specification Draft [1] has changed the capitalization
of mDCV and cLLI chunks (formerly mDCv and cLLi). This patch updates
FFmpeg to work with the new chunk names while retaining decode-side
compatibility with files created using the old names.
[1]: https://w3c.github.io/png/
Signed-off-by: Leo Izen <leo.izen@gmail.com>
There is an issue with the constants used in YUV to YUV range conversion,
where the upper bound is not respected when converting to mpeg range.
With this commit, the constants are calculated at runtime, depending on
the bit depth. This approach also allows us to more easily understand how
the constants are derived.
For bit depths <= 14, the number of fixed point bits has been set to 14
for all conversions, to simplify the code.
For bit depths > 14, the number of fixed points bits has been raised and
set to 18, to allow for the conversion to be accurate enough for the mpeg
range to be respected.
The convert functions now take the conversion constants (coeff and offset)
as function arguments.
For bit depths <= 14, coeff is unsigned 16-bit and offset is 32-bit.
For bit depths > 14, coeff is unsigned 32-bit and offset is 64-bit.
x86_64:
chrRangeFromJpeg8_1920_c: 2127.4 2125.0 (1.00x)
chrRangeFromJpeg16_1920_c: 2325.2 2127.2 (1.09x)
chrRangeToJpeg8_1920_c: 3166.9 3168.7 (1.00x)
chrRangeToJpeg16_1920_c: 2152.4 3164.8 (0.68x)
lumRangeFromJpeg8_1920_c: 1263.0 1302.5 (0.97x)
lumRangeFromJpeg16_1920_c: 1080.5 1299.2 (0.83x)
lumRangeToJpeg8_1920_c: 1886.8 2112.2 (0.89x)
lumRangeToJpeg16_1920_c: 1077.0 1906.5 (0.56x)
aarch64 A55:
chrRangeFromJpeg8_1920_c: 28835.2 28835.6 (1.00x)
chrRangeFromJpeg16_1920_c: 28839.8 32680.8 (0.88x)
chrRangeToJpeg8_1920_c: 23074.7 23075.4 (1.00x)
chrRangeToJpeg16_1920_c: 17318.9 24996.0 (0.69x)
lumRangeFromJpeg8_1920_c: 15389.7 15384.5 (1.00x)
lumRangeFromJpeg16_1920_c: 15388.2 17306.7 (0.89x)
lumRangeToJpeg8_1920_c: 19227.8 19226.6 (1.00x)
lumRangeToJpeg16_1920_c: 15387.0 21146.3 (0.73x)
aarch64 A76:
chrRangeFromJpeg8_1920_c: 6324.4 6268.1 (1.01x)
chrRangeFromJpeg16_1920_c: 6339.9 11521.5 (0.55x)
chrRangeToJpeg8_1920_c: 9656.0 9612.8 (1.00x)
chrRangeToJpeg16_1920_c: 6340.4 11651.8 (0.54x)
lumRangeFromJpeg8_1920_c: 4422.0 4420.8 (1.00x)
lumRangeFromJpeg16_1920_c: 4420.9 5762.0 (0.77x)
lumRangeToJpeg8_1920_c: 5949.1 5977.5 (1.00x)
lumRangeToJpeg16_1920_c: 4446.8 5946.2 (0.75x)
NOTE: all simd optimizations for range_convert have been disabled.
they will be re-enabled when they are fixed for each architecture.
NOTE2: the same issue still exists in rgb2yuv conversions, which is not
addressed in this commit.
Also fix checks for sc->stts_count that assume it may not be in sync with
sample count.
Missed in 865c73c86f9d9d167be7e41ad6cef71eba92dadd. Fixes parsing durations in
some cases.
Signed-off-by: James Almer <jamrial@gmail.com>
The fate test reference changes are due to the conversion being a simple
lossless deinterleave, instead of going through a RGB -> YUV -> RGB roundtrip.
Signed-off-by: James Almer <jamrial@gmail.com>
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>
Ensure those bits are copied, which will result in the output being the same as
the input, where swscale set them to the equivalent of fully opaque.
Signed-off-by: James Almer <jamrial@gmail.com>
This made the output non binary reproducible across different versions of
zlib.
This reverts commit bce5855afb25d318e090c2e6c16117f065458356.
Signed-off-by: James Almer <jamrial@gmail.com>
The demuxer's 'missing_streams' private option is used to communicate
information from the demuxer to avformat_find_stream_info(). However,
that is not only unnecessarily complicated, it also leaks internal
information to users, e.g. this option appears in the results of the
fate-flv-demux test.
Use a new field in FFFormatContext to communicate this information
instead.
stddev and PSNR values change by the removal of format conversion and because
of the added sws_flags. Either or will have the same effect even on their own.
Signed-off-by: James Almer <jamrial@gmail.com>
