see https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9503377

passed files:
    GDR_A_ERICSSON_2.bit
    GDR_B_NOKIA_2.bit
    GDR_C_NOKIA_2.bit
    VIRTUAL_A_MediaTek_3.bit
    VIRTUAL_B_MediaTek_3.bit

it's mismatched with the ff_vvc_sao_filter function declaration

avcodec/vvcdec: refact, unify {horizontal, vertical}_bs, {horizontal, vertical}_p, {horizontal, vertical}_q

Previously, the code allowed overwriting on 16-aligned blocks, which was suitable when there were
no picture's virtual boundaries because both CTU sizes and strides were 16-aligned. However, with
picture's virtual boundaries, each CTU is divided into four ALF blocks, leading to potential issues
with overwriting later CTUs.

In cases involving picture virtual boundaries, each ALF block is 8-pixel aligned.
For luma, we consistently ensure an 8-aligned width. For chroma in 4:2:0 format,
we need to account for a 4-aligned width.

A picture's virtual boundaries will split a CTU into 4 ALF blocks.
The ALF virtual boundary may cross or not cross a ALF block.

It's not part of the libavutil ABI.
Signed-off-by: James Almer <jamrial@gmail.com>

It's not part of the libavutil ABI.
Signed-off-by: James Almer <jamrial@gmail.com>

It's not part of the libavutil ABI.
Signed-off-by: James Almer <jamrial@gmail.com>

av_stereo3d_alloc() is not useful in scenarios where you need to know the
runtime size of AVStereo3D.
Signed-off-by: James Almer <jamrial@gmail.com>

Same as every other rational printed in this file.
Signed-off-by: James Almer <jamrial@gmail.com>

This avoids hardcoding any implementation-specific limitiations as
part of the API, and allows for future expandability.

This also allows API users to more conveniently convert the
values into floats without hardcoding specific conversion constants.

The API was committed a few days ago, so changing this field now
is within the realms of acceptable.

Currently, any unrecognised platform is treated as 32-bit. This should
detect *most* 64-bit platforms, namely LP64 and LLP64 ones.
Unfortunately this will not work for ILP32 ABIs on 64-bit ISAs, but
still better than nothing.

now that we are reading ext_mapping_idc as the upper 8 bits of
el_bit_depth_minus8 we need to use get_ue_golomb_long rather than
get_ue_golomb_31 for reading it

p0_10.j2k is one of the reference codestreams included in Rec. ITU-T T.803 | ISO/IEC 15444-4.
Adding this test was made possible by commit 6f4a95cf.

Fixes for example rtmps streaming over schannel.

The C code was silently ignoring the second chroma line on yuv422p
input.

The C code for some pixel formats (rgb555, rgb565, rgb444, and monob)
was not converting the last pixels on widths not aligned to 8.

NOTE: the last pixel for odd widths is still not converted for any of
      the pixel formats in the C code for yuv2rgb except for monob.

This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)

This results in a file where the mdat atom contains (and hides)
all the moof atoms that were part of the fragmented file structure
initially.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Currently, no eSBR features are supported.
Thankfully, no encoders exist for it yet.