Commit Graph

19 Commits

Author SHA1 Message Date
Andreas Rheinhardt ac5d5046c8 avcodec/cbs: Fix potential double-free when adding unit fails
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>
2020-02-09 22:23:29 +00:00
Andreas Rheinhardt 7c92eaace2 avcodec/cbs: Factor out common code for writing units
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>
2019-11-17 23:31:44 +00:00
Andreas Rheinhardt 4e7e30bbe0 cbs: Don't set AVBuffer's opaque
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>
2019-07-29 22:25:10 +01:00
Andreas Rheinhardt 730e5be3aa cbs: ff_cbs_delete_unit: Replace return value with assert
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>
2019-07-08 22:59:41 +01:00
Andreas Rheinhardt 1e93f5060f cbs: Allow non-blank packets in ff_cbs_write_packet
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>
2019-07-07 22:17:06 +01:00
Andreas Rheinhardt b8c45bbcbc libavcodec/cbs: Stop needlessly reallocating the units array
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>
2019-02-25 21:40:13 +00:00
Mark Thompson b5df289eb7 lavc: Add coded bitstream read/write support for VP9 2018-05-02 01:21:33 +01:00
Mark Thompson d7786b66bd cbs: Fragment/unit data is always reference counted
Make this clear in the documentation and add some asserts to ensure
that it is always true.
2018-05-01 23:31:37 +01:00
Mark Thompson 84bb8327f5 cbs: Add a table of all supported codec IDs
Use it as the set of codec IDs supported by the trace_headers BSF.
2018-03-18 17:55:00 +00:00
Mark Thompson 0cc8e34a94 Merge commit 'ce5870a3a8f2b10668ee4f04c2ae0287f66f31b2'
* commit 'ce5870a3a8f2b10668ee4f04c2ae0287f66f31b2':
  cbs: Refcount all the things!

Some changes for bitstream API.

Merged-by: Mark Thompson <sw@jkqxz.net>
2018-02-21 22:22:54 +00:00
Mark Thompson ce5870a3a8 cbs: Refcount all the things!
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).
2018-02-20 22:04:12 +00:00
Mark Thompson 254e728d20 cbs: Minor comment fixes / cosmetics 2018-02-20 22:04:12 +00:00
Mark Thompson 1d12a545ce cbs: Add an explicit type for coded bitstream unit types
Also fix conversion specifiers used for the unit type.
2018-02-20 22:04:12 +00:00
Mark Thompson 2651352988 cbs: Allocate the context inside the init function
... instead of making callers allocate it themselves.  This is more
consistent with other APIs in libav.
2018-02-20 22:04:12 +00:00
Mark Thompson 686e388bbb lavc: Add coded bitstream read/write support for MPEG-2
(cherry picked from commit 2bc9ba8d3c)
(cherry picked from commit a41b69b5eb)
2017-10-17 20:56:29 +01:00
Mark Thompson 9b0c7aa0e4 lavc: Add coded bitstream read/write support for H.265
(cherry picked from commit 867381b8b5)
(cherry picked from commit f763489364)
(cherry picked from commit 067a9ddeb8)
2017-10-17 20:56:29 +01:00
Mark Thompson b4c915f4b3 lavc: Add coded bitstream read/write support for H.264
(cherry picked from commit acf06f4544)
(cherry picked from commit 768eb9182e)
(cherry picked from commit e7f64191b2)
2017-10-17 20:56:29 +01:00
Mark Thompson 6734eef6b8 lavc: Add coded bitstream read/write API
(cherry picked from commit 18f1706f33)
(cherry picked from commit 44cde38c8a)
2017-10-17 20:56:29 +01:00
Mark Thompson 18f1706f33 lavc: Add coded bitstream read/write API 2017-08-12 22:17:20 +01:00