[FFmpeg-devel] [PATCH v4 06/21] cbs: Add support functions for handling unit content references
Mark Thompson
sw at jkqxz.net
Mon Feb 24 23:46:42 EET 2020
On 24/02/2020 01:55, Andreas Rheinhardt wrote:
> Mark Thompson:
>> 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 at googlemail.com>, but with the implementation
>
> You may use my new email here.
Done.
>> changed to use the unit type information if possible rather than
>> requiring a codec-specific function.
>> ---
>> libavcodec/cbs.c | 172 ++++++++++++++++++++++++++++++++++++++
>> libavcodec/cbs.h | 29 +++++++
>> libavcodec/cbs_internal.h | 1 +
>> 3 files changed, 202 insertions(+)
>>
>> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
>> index 6cc559e545..91788f6dfb 100644
>> --- a/libavcodec/cbs.c
>> +++ b/libavcodec/cbs.c
>> @@ -881,3 +881,175 @@ int ff_cbs_alloc_unit_content2(CodedBitstreamContext *ctx,
>>
>> return 0;
>> }
>> +
>> +static int cbs_clone_unit_content(AVBufferRef **clone_ref,
>> + CodedBitstreamUnit *unit,
>> + const CodedBitstreamUnitTypeDescriptor *desc)
>> +{
>> + uint8_t *src, *copy;
>> + uint8_t **src_ptr, **copy_ptr;
>> + AVBufferRef **src_buf, **copy_buf;
>> + int err, i;
>> +
>> + av_assert0(unit->content);
>> + src = unit->content;
>> +
>> + copy = av_malloc(desc->content_size);
>> + if (!copy)
>> + return AVERROR(ENOMEM);
>> +
>> + memcpy(copy, src, desc->content_size);
>
> One can use av_memdup() for malloc+memcpy.
Yep, changed.
>> +
>> + for (i = 0; i < desc->nb_ref_offsets; i++) {
>> + src_ptr = (uint8_t**)(src + desc->ref_offsets[i]);
>> + src_buf = (AVBufferRef**)(src_ptr + 1);
>> + copy_ptr = (uint8_t**)(copy + desc->ref_offsets[i]);
>> + copy_buf = (AVBufferRef**)(copy_ptr + 1);
>
> In patch #2 you intend to make the AVBufferRef * directly follow the
> pointer so that the above works. This has two drawbacks: It probably
> works on all systems we care about, but it is not spec-compliant as a
> compiler may add padding between these two elements. And furthermore
> it forces you to make these ugly casts above.
You would have to have a very weird ABI to cause problems here, so I'm not too worried - we already disallow differently-sized pointer types (see av_freep()), so it would have to be some extremely bizarre struct packing rule.
> How about the following approach: The *data pointer and the *data_ref
> pointer will always be put into a dedicated structure (maybe even with
> the size field?) ChildBuf (better name welcome) or whatever and the
> descriptor contains the offset of these ChildBufs. Here is a scetch:
>
> struct ChildBuf {
> uint8_t *data;
> AVBufferRef *data_ref;
> } ChildBuf;
>
> const ChildBuf *src_child = (const ChildBuf *)(src +
> desc->child_offsets[i]);
> ChildBuf *copy_child = (ChildBuf *)(copy + desc->ref_offsets[i]);
>
> if (!src_child->data) {
> av_assert0(!src_child->data_ref);
> continue;
> }
> ...
> copy_child->data_ref = av_buffer_ref(src_child->data_ref);
>
> I admit it would probably involve more writing (unless you can come up
> with a really short name).
Adding the extra layer in the name is annoyingly inelegant for both the declaration (extra structure) and the use (extra layer of indirection in the name). Given that, I'm inclined to stay with the current approach without a stronger reason to change, because it isolates the ugliness to this one function.
I was thinking of adding a unit test which would go through all of the descriptor tables and structures to make sure that the offsets in the entries actually match. Would that reassure you that the result is ok?
>> +
>> + if (!*src_ptr) {
>> + av_assert0(!*src_buf);
>> + continue;
>> + }
>> + if (!*src_buf) {
>> + // We can't handle a non-refcounted pointer here - we don't
>> + // have enough information to handle whatever structure lies
>> + // at the other end of it.
>> + err = AVERROR(EINVAL);
>> + goto fail;
>> + }
>> +
>> + // src_ptr is required to point somewhere inside src_buf. If it
>> + // doesn't, there is a bug somewhere.
>> + av_assert0(*src_ptr >= (*src_buf)->data &&
>> + *src_ptr < (*src_buf)->data + (*src_buf)->size);
>> +
>> + *copy_buf = av_buffer_ref(*src_buf);
>> + if (!*copy_buf) {
>> + err = AVERROR(ENOMEM);
>> + goto fail;
>> + }
>> +
>> + err = av_buffer_make_writable(copy_buf);
>
> Making the child buf writable is neither necessary for fixing the
> original problem, because h264_redundant_pps does not modifiy the
> child buffer; nor is there any benefit to it: If unit->content_ref is
> already writable, the child buffers will not be made writable, so that
> a caller can not rely on the child buffers being writable after
> ff_cbs_make_unit_writable() so that if he wants to modify them, a
> further av_buffer_make_writable() for them is necessary.
> Furthermore, if one only wants to modify e.g. a slice header that is
> currently not writable (for whatever reason), one would also make the
> internal ref (i.e. the unit's data) writable, which is expensive, but
> one has no real choice because ff_cbs_make_unit_writable() does it
> automatically.
You are right; I clearly didn't think about this carefully enough, thank you for your care in spotting that. Removed.
>> + if (err < 0) {
>> + av_buffer_unref(copy_buf);
>> + goto fail;
>> + }
>> +
>> + *copy_ptr = (*copy_buf)->data + (*src_ptr - (*src_buf)->data);
>> + }
>> +
>> + *clone_ref = av_buffer_create(copy, desc->content_size,
>> + desc->content_free ? desc->content_free :
>> + cbs_default_free_unit_content,
>> + (void*)desc, 0);
>> + if (!*clone_ref) {
>> + err = AVERROR(ENOMEM);
>> + goto fail;
>> + }
>> +
>> + return 0;
>> +
>> +fail:
>> + for (--i; i >= 0; i--)
>> + av_buffer_unref((AVBufferRef**)(copy + desc->ref_offsets[i]));
>> + av_freep(©);
>> + *clone_ref = NULL;
>> + return err;
>> +}
>> ...
Thanks,
- Mark
More information about the ffmpeg-devel
mailing list