| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Used to reset the codec's private internal state.
Signed-off-by: James Almer <jamrial@gmail.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.
|
| | |
|
| |
|
|
|
|
|
|
| |
Several cbs-functions had an unused CodedBitstreamContext parameter.
This commit removes these.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ff_cbs_insert_unit_data() has two modes of operation: It can insert a
unit with a newly created reference to an already existing AVBuffer; or
it can take a buffer and create an AVBuffer for it. Said buffer will
then become owned by the unit lateron.
A potential memleak/double-free exists in the second case, because if
creating the AVBuffer fails, the function immediately returns, but when
it fails lateron, the supplied buffer will be freed. The caller has no
way to distinguish between these two outcomes. The only such caller
(cbs_jpeg_split_fragment() in cbs_jpeg.c) opted for a potential
double-free.
This commit changes this by explicitly stating that a non-refcounted
buffer will be freed on error. The aforementioned caller has been
brought in line with this.
Fixes CID 1452623.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cbs is currently inconsistent regarding the opaque field that can be
used as a special argument to av_buffer_create in order to be used
during freeing the buffer: ff_cbs_alloc_unit_content and all the free
functions used name this parameter as if it should contain a pointer to
the unit whose content is about to be created; but both
ff_cbs_alloc_unit_content as well as ff_cbs_h264_add_sei_message
actually use a pointer to the CodedBitstreamContext as opaque. It should
actually be neither, because it is unneeded (as is evidenced by the fact
that none of the free functions use this pointer at all) and because it
ties the unit's content to the lifetime of other objects, although a
refcounted buffer is supposed to have its own lifetime that only ends
when its reference count reaches zero. This problem manifests itself in
the pointer becoming dangling.
The pointer to the unit can become dangling if another unit is added to
the fragment later as happens in the bitstream filters; in this case,
the pointer can point to the wrong unit (if the fragment's unit array
needn't be relocated) or it can point to where the array was earlier.
It can also become dangling if the unit's content is meant to survive
the resetting of the fragment it was originally read with. This applies
to the extradata of H.264 and HEVC.
The pointer to the context can become dangling if the context is closed
before the content is freed. Although this doesn't seem to happen right
now, it could happen, in particular if one uses different
CodedBitstreamContexts for in- and output.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
ff_cbs_delete_unit never fails if the index of the unit to delete is
valid, as it is with all current callers of the function. So just assert
in ff_cbs_delete_unit that the index is valid and change the return
value to void in order to remove the callers' checks for whether
ff_cbs_delete_unit failed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Up until now, ff_cbs_write_packet always initialized the packet
structure it received without documenting this behaviour; furthermore,
the packet's buffer would (on success) be overwritten with the new
buffer without unreferencing the old. This meant that the input packet
had to be either clean (otherwise there would be memleaks) in which case
the initialization is redundant or uninitialized. ff_cbs_write_packet
was never used with uninitialized packets, so the initialization was
redundant. Worse yet, it forced callers to use more than one packet and
made it difficult to add side-data to a packet designated for output,
because said side-data could only be attached after the call to
ff_cbs_write_packet.
This has been changed. It is now allowed to use a non-blank packet.
The currently existing buffer will be unreferenced and replaced by
the new one, as will be the accompanying fields (i.e. data and size).
The rest isn't touched at all.
This change will enable us to use only one packet in the bitstream
filters that rely on CBS.
This commit also updates the documentation of ff_cbs_write_extradata
and ff_cbs_write_packet (to better describe existing behaviour and in
the latter case to also describe the new behaviour).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, a fragment's unit array is constantly reallocated during
splitting of a packet. This commit changes this: One can keep the units
array by distinguishing between the number of allocated and the number
of valid units in the units array.
The more units a packet is split into, the bigger the benefit.
So MPEG-2 benefits the most; for a video coming from an NTSC-DVD
(usually 32 units per frame) the average cost of cbs_insert_unit (for a
single unit) went down from 6717 decicycles to 450 decicycles (based
upon 10 runs with 4194304 runs each); if each packet consists of only
one unit, it went down from 2425 to 448; for a H.264 video where most
packets contain nine units, it went from 4431 to 450.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@googlemail.com>
|
| | |
|
| |
|
|
|
| |
Make this clear in the documentation and add some asserts to ensure
that it is always true.
|
| |
|
|
| |
Use it as the set of codec IDs supported by the trace_headers BSF.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'ce5870a3a8f2b10668ee4f04c2ae0287f66f31b2':
cbs: Refcount all the things!
Some changes for bitstream API.
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).
|
| | | |
|
| | |
| |
| |
| | |
Also fix conversion specifiers used for the unit type.
|
| | |
| |
| |
| |
| | |
... instead of making callers allocate it themselves. This is more
consistent with other APIs in libav.
|
| | |
|
| |
|
|
|
| |
(cherry picked from commit 2bc9ba8d3c41f3a8e56484bd67b05040c7909a01)
(cherry picked from commit a41b69b5eb950c10d8ede472bcc4e88ce4246db9)
|
| |
|
|
|
|
| |
(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)
|
|
|
(cherry picked from commit 18f1706f331bf5dd565774eae680508c8d3a97ad)
(cherry picked from commit 44cde38c8acbef7d5250e6d1b52b1020871e093b)
|
