This commit adds support for VP8 bitstream read methods to the cbs
codec. This enables the trace_headers bitstream filter to support VP8,
in addition to AV1, H.264, H.265, and VP9. This can be useful for
debugging VP8 stream issues.
The CBS VP8 implements a simple VP8 boolean decoder using GetBitContext
to read the bitstream.
Only the read methods `read_unit` and `split_fragment` are implemented.
The write methods `write_unit` and `assemble_fragment` return the error
code AVERROR_PATCHWELCOME. This is because CBS VP8 write is unlikely to
be used by any applications at the moment. The write methods can be
added later if there is a real need for them.
TESTS: ffmpeg -i fate-suite/vp8/frame_size_change.webm -vcodec copy
-bsf:v trace_headers -f null -
Signed-off-by: Jianhui Dai <jianhui.j.dai@intel.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This avoids allocations and error checks etc. as well
as duplicate pointer lists in the CodedBitstreamFooContexts.
It also avoids casting const away for use as opaque,
as the RefStruct API supports const opaques.
The fact that some of the units are not refcounted
(i.e. they are sometimes part of an encoding context
like VAAPIEncodeH264Context) meant that CodedBitstreamUnit
still contains two pointers, one to the content
and another ownership pointer, replacing the AVBufferRef* pointer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Turn tracing into callbacks for each syntax element, with default
callbacks to match current trace_headers behaviour for debug. Move
the construction of bit strings into the trace callback, which
simplifies all of the read and write functions.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
These functions allow not only to read and write unsigned values,
but also to check ranges and to emit trace output which can be
beautified when processing arrays (indices like "[i]" are replaced
by their actual numbers).
Yet lots of callers actually only need something simpler:
Their range is only implicitly restricted by the amount
of bits used and they are not part of arrays, hence don't
need this beautification.
This commit adds specializations for these callers;
this is very beneficial size-wise (it reduced the size
of .text by 23312 bytes here), as a call is now cheaper.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add CodedBitstreamContext to parse VPS,SPS,PPS in VVC nal units.
Implement parsing and writing of SPS,PPS,VPS,PH,AUD,SEI and slices.
Add ff_cbs_type_h266 to cbs types tables and AV_CODEC_ID_H266
to cbs codec ids.
Co-authored-by: Thomas Siedel <thomas.ff@spin-digital.com>
Signed-off-by: James Almer <jamrial@gmail.com>
cbs_jpeg was the last user of CBS that didn't use
CodedBitstreamUnitTypeDescriptors.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use the unit type table to determine what we need to do to clone the
internals of the unit content when making copies for refcounting or
writeability. (This will still fail for units with complex content
if they do not have a defined clone function.)
Setup and naming from a patch by Andreas Rheinhardt
<andreas.rheinhardt@gmail.com>, but with the implementation changed
to use the unit type information if possible rather than requiring a
codec-specific function.
Unit types are split into three categories, depending on how their
content is managed:
* POD structure - these require no special treatment.
* Structure containing references to refcounted buffers - these can use
a common free function when the offsets of all the internal references
are known.
* More complex structures - these still require ad-hoc treatment.
For each codec we can then maintain a table of descriptors for each set of
equivalent unit types, defining the mechanism needed to allocate/free that
unit content. This is not required to be used immediately - a new alloc
function supports this, but does not replace the old one which works without
referring to these tables.
All cbs-functions to write units share a common pattern:
1. They check whether they have a write buffer (that is used to store
the unit's data until the needed size becomes known after writing the
unit when a dedicated buffer will be allocated).
2. They use this buffer for a PutBitContext.
3. The (codec-specific) writing takes place through the PutBitContext.
4. The return value is checked. AVERROR(ENOSPC) here always indicates
that the buffer was too small and leads to a reallocation of said
buffer.
5. The final buffer will be allocated and the data copied.
This commit factors this common code out in a single function in cbs.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The type of the result of a shift operation is unaffected by the type of
the right operand, so some existing code overflows with undefined behaviour
when the element length is 32. Add a helper macro to calculate the maximum
value correctly and then use it everywhere this pattern appears.
Found-by: Andreas Rheinhardt <andreas.rheinhardt@googlemail.com>
* commit 'ce5870a3a8f2b10668ee4f04c2ae0287f66f31b2':
cbs: Refcount all the things!
Some changes for bitstream API.
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '254e728d207c173a3714e6a01c9d68fcb3af8b73':
cbs: Minor comment fixes / cosmetics
Mostly already present, one small fix.
Merged-by: Mark Thompson <sw@jkqxz.net>
This makes it easier for users of the CBS API to get alloc/free right -
all subelements use the buffer API so that it's clear how to free them.
It also allows eliding some redundant copies: the packet -> fragment copy
disappears after this change if the input packet is refcounted, and more
codec-specific cases are now possible (but not included in this patch).
(cherry picked from commit 867381b8b51fa21fa2b8f071f508f3d39cc9c1f0)
(cherry picked from commit f763489364416bb6866adc4f4a96012dd2ca1bd0)
(cherry picked from commit 067a9ddeb8feff1f724856f0054930c55219f76b)
(cherry picked from commit acf06f45441be24c5cbae0920579cd69427326a1)
(cherry picked from commit 768eb9182e94a94bc2ef46f565a0dac7afef3b57)
(cherry picked from commit e7f64191b27bcf37cbf7006606f0f439c6cdc24f)
