On 9/25/2024 4:27 PM, Marton Balint wrote:
On Wed, 25 Sep 2024, Nicolas George wrote:Anton Khirnov (12024-09-25):Because AVFilterLink is internal state of the filtergraph and should not be exposed at all.Anyway, if you cannot come up with an API that does not require dynamic allocations and all the boilerplate code it requires just to retrieve a few integers, then drop the series altogether.I kind of agree. It is suboptimal that the buffersink stores all its parameters already in a public struct, but you can only access them if you get yourself an owned copy with all the overhead of copying / referencing, plus now you have to do extra allocation for the results and error checking as well.Also I don't like that you are misusing an AVFrame struct to pass parameters. How the user should know which parameters are set in AVFrame and which are not? A dedicated struct would be better, or just use AVFilterLink.
There is AVBufferSrcParameters, which could be renamed and reused here. Exact same fields, but for the opposite purpose. It still requires allocating it before using it, but since a normal filterchain will have buffersrc -> [...] -> buffersink, the same allocated struct can be used for both.
The main benefit i see from doing this is that, much like you don't create references/copies for the fields you put in AVBufferSrcParameters because av_buffersrc_parameters_set() is what internally will do that, buffersink wouldn't need to create references/copies to store anything there either, leaving that to the caller (who will be informed the fields in the output struct are still owned by the library).
OpenPGP_signature.asc
Description: OpenPGP digital 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".
