Re: [FFmpeg-devel] [PATCH v6 1/2] avcodec/avutil: move dynamic HDR10+ metadata parsing to libavutil

["Raphaël Zumer" <raphael.zumer@vimeo.com>]

On 3/13/23 20:44, Andreas Rheinhardt wrote:
>> diff --git a/libavutil/hdr_dynamic_metadata.h b/libavutil/hdr_dynamic_metadata.h
>> index 2d72de56ae..3d327241c1 100644
>> --- a/libavutil/hdr_dynamic_metadata.h
>> +++ b/libavutil/hdr_dynamic_metadata.h
>> @@ -340,4 +340,15 @@ AVDynamicHDRPlus *av_dynamic_hdr_plus_alloc(size_t *size);
>>   */
>>  AVDynamicHDRPlus *av_dynamic_hdr_plus_create_side_data(AVFrame *frame);
>>  
>> +/**
>> + * Parse the user data registered ITU-T T.35 to AVbuffer (AVDynamicHDRPlus).
>> + * @param s A pointer containing the decoded AVDynamicHDRPlus structure.
>> + * @param data The byte array containing the raw ITU-T T.35 data.
>> + * @param size Size of the data array in bytes.
> The implementation of this function uses the GetBit-API which requires
> the buffer to be padded; yet the documentation does not mention this.
>
> Looking at the calculation in av_dynamic_hdr_plus_to_t35(), it seems
> that the maximum bitlength of a valid ITU-T T.35 payload is
> 48+2×937+27+1+10+25×25×4+3×82+(3×15×24)+(1+10+25×25×4+3×1)+(3×(28+15×10))+3+3×6
> = 8855 bits (please double-check this). This means we can just copy that
> much into a padded buffer on the stack and ignore the padding. We may
> then remove the padding from the serialization function, too.
>
> (The GetBit-API btw actually does not need AV_INPUT_BUFFER_PADDING_SIZE
> bytes of padding, but way less (I think 8 bytes or so). I don't really
> like using AV_INPUT_BUFFER_PADDING_SIZE here.)

Hi,

From get_bits.h (init_get_bits()): "buffer, must be AV_INPUT_BUFFER_PADDING_SIZE bytes larger than the actual read bits". Is this wrong? If so, what is the correct value and is it defined anywhere? What about "other places where one needed a padded buffer" as mentioned in your previous comment?

Why is copying the buffer to the stack in the parsing function preferable to padding it when serializing? The vast majority of HDR10+ payloads will be well below the max size.

RZ

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".