Reads color_primaries, color_trc and color_space from mxf
headers. ULs are from https://registry.smpte-ra.org/ site.
Signed-off-by: Harry Mallon <harry.mallon@codex.online>
The default for the chromaoffset field in AVCodecContext
is zero, which until now always ended up overriding the
AVOption-set value, thus leading to the AVOption not working.
Additionally, the previous usage prevented the usage of
negative values, while both the variable as well as x264's
API would successfully handle such.
Thus, the default value of the AVOption is changed to match
the default of x264 (and what is currently the default for
the AVCodecContext chromaoffset field), and the checks are
changed to check for nonzero values.
This way:
1. the library default is still utilized if the value is zero.
2. both negative and positive values are correctly passed to
x264.
For historical context, this was initially similarly
implemented in 5764d38173, and
then b340bd8a58 broke the
value.
Partially reverts commit b340bd8a58.
Signed-off-by: Takio Yamaoka <y.takio@gmail.com>
Fixes: shift exponent 32 is too large for 32-bit type 'int'
Fixes: 24566/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6033783737024512
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Gautam Ramakrishnan <gautamramk@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch allows the encoder to use SOP and EPH
markers. This would be useful as these markers
provide better error detection mechanisms.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit avoids allocating a DVDemuxContext when demuxing raw DV by
making it part of the demuxer's context. This also allows to remove
dv_read_close().
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Respecting the framerate in the libopenh264enc codec context.
Both the libx264 and libx265 encoders already contain similar logic
to first check the framerate before falling back to the timebase.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Fixes: 24457/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5760093644390400
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This differs from the MPEG specification as the actual real world
files do compute their CRC over variable areas and not the fixed
ones listed in the specification. This is also the reason for
the complexity of this code and the need to perform the CRC
check for layer2 in the middle of layer2 decoding.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Only this sub-set of channels actually follows the bit mask order
in the official 22.2 channel mapping. Additionally, the 5.1 channels
are there for backwards compatibility with the previous system.
This enables the utilization of 22.2 content until a proper down/up
matrix is added into swresample.
These bits are utilized by channel layouts such as 22.2. If those
are dropped, the returned channel layout is no longer a match
against the AV_CH_LAYOUT define when returned from this function.
Requires some extraneous top side and bottom front channels to be
defined.
According to STD-B59v2, the defined channel layout is:
- FL
- FR
- FC
- LFE1
- BL
- BR
- FLc
- FRc
- BC
- LFE2
- SiL
- SiR
- TpFL
- TpFR
- TpFC
- TpC
- TpBL
- TpBR
- TpSiL
- TpSiR
- TpBC
- BtFC
- BtFL
- BtFR
Previously, the hls-fmp4 and hls-fmp4_ac3 tests used the same file
names for init and segment files, which occasionally could cause
corruption and failed tests, if the input files for both tests are
generated in parallel, as they could overwrite each other.
This happened to work some of the time, as the fmp4_ac3 test actually
only checked the init segment file (which the fmp4 test case never
wrote, due to using the incorrect hls_segment_type option) and the
fmp4 test case always regenerated the input files due to mismatched
target and file names.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, with the file name not matching the target, the files
were regenerated every time fate is rerun - contrary to the other
test targets in the same file. (While regenerating it every time
might be desireable, as that's what the test is about, the file
at least has a dependency on the ffmpeg executable, making them
regenerated every time the executable is updated - and this change
at least makes it consistent with the rest.)
Signed-off-by: Martin Storsjö <martin@martin.st>
Layers 1 and 2 use lengths in bits which are not a multiple of 8,
and our CRC works on a per-byte basis.
Based on b48397e7b8
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit b48397e7b8.
The change did not disable crc checks for layer 1 & 2, it removed reading
the CRC field.
Fixes decoding some mp2 samples and FATE test failures.
Signed-off-by: James Almer <jamrial@gmail.com>
Will prevet FATE from breaking once LIBAVCODEC_VERSION_MINOR is bumped to 100.
Reported-by: zane
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The process space is guaranteed to be aligned to the page size, hence we're
never going to map outside of our address space.
There are more optimizations to do with respect to chroma plane alignment and
buffer offsets, but that can be done later.
If a bit is reserved, it matters very much what value it has, because
otherwise a decoder conforming to a future version of the standard might
interpret the output file in an unintended manner. This implies that
one must not use skip_put_bits() for it (which does not give any
guarantees wrt what ends up in the output (in case of a little-endian
bitstream writer (as here) it writes a 0 bit)); given that the reference
encoder as well as the earlier code write a zero bit at this place, the
new code does, too.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
flush_put_bits() already fills the bitstream with zeroes, so it is
unnecessary to align the bitstream before.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Dimensions are normally specified as width x height, and this will match
the same option to libaom-av1.
Remove the indirection through the private context at the same time.
The tile_rows/cols options currently do a confusingly different thing to
the options of the same name on other encoders like libvpx and libaom.
There is no backward-compatibility reason to implement the log2 behaviour
as there was for libaom, so just get rid of them entirely.
