This byte represents 4 reserved bits followed by 4 alpha_channel_type bits.
alpha_channel_type currently has 3 differents defined values: 0 (no
alpha), 1 (8b alpha), and 2 (16b alpha), all the other values are
reserved. The 4 initial reserved bits are expected to be 0.
This byte represents 4 reserved bits followed by 4 alpha_channel_type bits.
alpha_channel_type currently has 3 differents defined values: 0 (no
alpha), 1 (8b alpha), and 2 (16b alpha), all the other values are
reserved. This part is correctly written (alpha_bits>>3 does the correct
thing), but the 4 initial bits are reserved.
Quoting SMPTE RDD 36:2015:
A decoder shall abort if it encounters a bitstream with an unsupported
bitstream_version value. If 0, the value of the chroma_format syntax
element shall be 2 (4:2:2 sampling) and the value of the
alpha_channel_type element shall be 0 (no encoded alpha); if 1, any
permissible value may be used for those syntax elements.
So if we're not in 4:2:2 or if there is alpha, we are not allowed to use
version 0.
Quoting SMPTE RDD 36:2015:
A decoder shall abort if it encounters a bitstream with an unsupported
bitstream_version value. If 0, the value of the chroma_format syntax
element shall be 2 (4:2:2 sampling) and the value of the
alpha_channel_type element shall be 0 (no encoded alpha); if 1, any
permissible value may be used for those syntax elements.
So if we're not in 4:2:2 or if there is alpha, we are not allowed to use
version 0.
FIx warnings (soon to be errors in GCC 14, already so in Clang 15):
```
src/libavcodec/vulkan_av1.c: In function ‘vk_av1_create_params’:
src/libavcodec/vulkan_av1.c:183:43: error: initialization of ‘long long unsigned int’ from ‘void *’ makes integer from pointer without a cast [-Wint-conversion]
183 | .videoSessionParametersTemplate = NULL,
| ^~~~
src/libavcodec/vulkan_av1.c:183:43: note: (near initialization for ‘(anonymous).videoSessionParametersTemplate’)
```
Use Vulkan's VK_NULL_HANDLE instead of bare NULL.
Fix Trac ticket #10724.
Was reported downstream in Gentoo at https://bugs.gentoo.org/919067.
Signed-off-by: Sam James <sam@gentoo.org>
These functions encode a slice of alpha (1 to 8 macroblocks) which are
expected to be encoded as a repeated sequence of "[diff][run-1]", where
diff is the running difference of the alpha value and run is how many
times that value is expected to be duplicated (within the limit of a
grand total of 2048 unpacked samples, corresponding to a slice of 8 MB).
Even when run==0 (the run variable semantic is actually "run minus 1"),
there is always a diff previously encoded that needs a counter of at
least 1. This means we need to call put_alpha_run() unconditionally at
the end of the bitstream to account for the last running diff.
This commit fixes glitchy playbacks on QuickTime with M2 and M3 hardware
(but not M1 for some mysterious reason) with files generated with
commands such as:
ffmpeg -f lavfi -i testsrc2=d=5:s=912x320,chromakey -c:v prores_aw -profile:v 4 -y aw.mov
ffmpeg -f lavfi -i testsrc2=d=5:s=912x320,chromakey -c:v prores_ks -profile:v 4444 -y ks.mov
The glitch expresses itself deterministically as blinking black
rectangles on random frames (for example on frame 21, 54, 71, 79, ...).
Even with the proresdec from FFmpeg, overreads actually happens while
reading the run-minus-1 value (around val = get_bits(gb, 4) in
unpack_alpha()). This doesn't seem to cause any particular issue because
it simply overreads into the next slice, and because the decoder is
resilient, but it's still a problem.
The investigation leading to this fix was made possible because of paid
work for Jitter (https://jitter.video).
Fixes ticket #10255.
In the mov muxer (in mov_write_video_tag()), bits_per_coded_sample will
be written under certain conditions and is required to be 32 for the
transparency to be honored in QuickTime.
prores_kostya already has this setting but prores_anatoliy and
prores_videotoolbox didn't.
This commit removes the follow warning and error:
D3D12 WARNING: ID3D12CommandList::ResourceBarrier: Called on the same subresource(s) of
Resource(0x000002236E0E00D0:'Unnamed ID3D12Resource Object') in separate Barrier Descs
which is inefficient and likely unintentional. Desc[0] and Desc[1] on (subresource :
4294967295). [RESOURCE_MANIPULATION WARNING #1008: RESOURCE_BARRIER_DUPLICATE_SUBRESOURCE_TRANSITIONS]
D3D12 ERROR: ID3D12CommandList::ResourceBarrier: Before state (0x0: D3D12_RESOURCE_STATE_[COMMON|PRESENT])
of resource (0x000002236E0E00D0:'Unnamed ID3D12Resource Object') (subresource: 0) specified
by transition barrier does not match with the state (0x20000: D3D12_RESOURCE_STATE_VIDEO_DECODE_WRITE)
specified in the previous call to ResourceBarrier [RESOURCE_MANIPULATION ERROR #527:
RESOURCE_BARRIER_BEFORE_AFTER_MISMATCH]
Tested-by: Tong Wu <tong1.wu@intel.com>
Signed-off-by: Wu Jianhua <toqsxw@outlook.com>
Previous assertion was not useful. Now a warning is added to replace it.
For get_surface_index, we should return a zero index in case the index is not found.
But a warning is necessary to notify.
Signed-off-by: Tong Wu <tong1.wu@intel.com>
