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

[James Almer <jamrial-at-gmail.com@ffmpeg.org>]

[-- Attachment #1.1.1: Type: text/plain, Size: 1242 bytes --]

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@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.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".