[FFmpeg-devel] [PATCH 1/7] avutil: add an API to handle 3D Reference Displays Information

James Almer jamrial at gmail.com
Mon Jun 16 15:54:10 EEST 2025


On 6/9/2025 7:09 PM, Andreas Rheinhardt wrote:
> James Almer:
>> On 6/9/2025 5:59 PM, Timo Rothenpieler wrote:
>>> On 08.06.2025 17:45, James Almer wrote:
>>>> On 6/8/2025 11:29 AM, Andreas Rheinhardt wrote:
>>>>> Timo Rothenpieler:
>>>>>> From: James Almer <jamrial at gmail.com>
>>>>>>
>>>>> I don't like that you add another allocator for this; instead we should
>>>>> add a generic allocator for the frame side-data types.
>>>>
>>>> Wont work for packet side data. And i purposely didn't add yet
>>>> another allocator that inserts the result into a frame, like there's
>>>> in so many other modules, because eventually the generic one would be
>>>> introduced.
>>>>
>>>> You said you wanted to take over my work on the generic allocator,
>>>> but not sure if you did anything with it. The core issue was handling
>>>> more complex types that didn't just have an extra nb_blocks argument.
>>>
>>> So, what is the conclusion here?
>>> I'd like to push this set if you can come to an agreement.
>>>
>>> I haven't looked into it much, but implementing av_tdrdi_alloc() in a
>>> generic way does seem a bit hacky. And other types might need even
>>> more info for the allocation.
>>
>> The set LGTM. A custom frame side data allocator does not imply an
>> allocator is required for this struct. Frames are not the only user.

Meant to say "isn't" here.

>>
> 
> I was thinking about a generic side data allocator (for the
> AVFrameSideDataType stuff, but it is not meant to be AVFrame specific),
> so that it can be used by more than just AVFrames. Will write one tomorrow.
> 
> - Andreas

Frame side data, be it inside frames or not, is not the only user. An 
allocator for this struct is needed regardless of what we do with that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20250616/7cd00149/attachment.sig>


More information about the ffmpeg-devel mailing list