libgsm never installed more than a single header, the headers installed into
the gsm/ subdirectory by some distros are private. Who started this nonsense
is a mystery, but it got cargo-culted around ever since.
Build h2645_parse.o with it, as every hevc_ps dependency also needs it.
This is more in line with h264's h264parse module.
Signed-off-by: James Almer <jamrial@gmail.com>
Whether the udu string should be freed depends on whether the SEI it
gets added to was created internally by cbs or externally by the bsf.
The current code frees it twice in the former case.
In binutils 2.29, the behavior of the ADR instruction changed so that 1 is
added to the address of a Thumb function (previously nothing was added). This
allows the loaded address to be passed to a BLX instruction and the correct
mode change will occur.
See: https://sourceware.org/bugzilla/show_bug.cgi?id=21458
By using adr with a label that isn't annotated as a thumb function,
we avoid the new behaviour in binutils 2.29 and get the same behaviour
as in prior releases, and as in other assemblers (ms armasm.exe,
clang's built in assembler) - an idea that Janne Grunau came up with.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids having to use pseudo relocations.
The version script used for exporting functions is skipped as soon
as the set of object files contains symbols marked with dllexport,
therefore we need to use makedef to produce the full list of symbols
to be exported.
Signed-off-by: Martin Storsjö <martin@martin.st>
We currently only have exported data symbols within libavcodec, but
the concept is easy to extend to other libraries if necessary.
The attribute declaration needs to be in a private header though,
since we can't use CONFIG_SHARED in public installed headers.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since there is no information about the source format, "unspecified"
is the correct value to write here.
All tests using the MPEG-2 encoder are updated, as this changes the
header on all outputs.
DDS1 chunks are decoded in 2x2 blocks, odd chunk width or height is not
allowed in that case. Also ensure that the decode buffer is big enough
for all blocks being processed.
Bug-Id: CVE-2017-9992
CC: libav-stable@libav.org
It is not necessary to pad to the CTU size. The CB size of 8x8 should be
sufficient, but due to constraints in the Intel driver (the one usable
implementation of this) it has to be padded to 16x16 like in H.264.
This applies a specific fixup to some Bluray streams which contain
redundant PPSs modifying irrelevant parameters of the stream which
confuse other transformations which require correct extradata.
A new single global PPS is created, and all of the redundant PPSs
within the stream are removed.
The use of this SEI is for backward compatibility in HLG HDR systems:
older devices that cannot interpret the "arib-std-b67" transfer will
get the compatible transfer (usually bt709 or bt2020) from the VUI,
while newer devices that can interpret HDR will read the SEI and use
its value instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Use AVCodecContext.compression_level rather than a private option,
replacing the H.264-specific quality option (which stays only for
compatibility).
This now works with the H.265 encoder in the i965 driver, as well as
the existing cases with the H.264 encoder.
Add comments to describe the sources of the constraint values expressed here,
and add some more related values which will be used in following patches.
Fix the incorrect values for SPS and PPS count (they are not the same as those
used for H.264), and remove HEVC_MAX_CU_SIZE because it is not used anywhere.
Diego Biurrun
James Almer
Mark Thompson
Luca Barbato
Martin Storsjö
Anton Khirnov
Piotr Bandurski
Vittorio Giovara