James Almer (12021-12-14): > We add a const uint8_t* field to AVChannelCustom. If the user wants to > allocate the strings instead, and not worry about their lifetime, they can > provide the layout with a custom free() function that will take care of > cleaning anything they came up with on uninit().
I understood what you suggested, and it amounts to letting API users fend for themselves. We can do that, but I would prefer if we only did on last resort, if we do not find a more convenient solution. > Having something like this called on every copy sounds inefficient. And what What??? Ref-counting makes operations more efficient by avoiding new dynamic allocations. I grant you, the code currently tries to avoid dynamic allocations, but I do not think it is actually manageable without seriously limiting the features of the API. And you know me, I try to avoid dynamic allocations as much as possible. > will you refcount? The layout? Each channel's string? Can you be more > specific about how do you imagine implementing this? The whole layout structure, with all the possible custom layouts, dictionaries and strings. I do not think that sharing strings between layouts that are similar but not equal is worth the added complexity. (We may consider a ref-counted string type at some point, maybe, but that is another story.) Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
