Quoting Carotti, Elias (2023-06-26 11:50:59) > We can do whatever you want. However I am not clear on how that<br> > would work. > > We could have a side data creation api with the standard parameters and > another method to allocate memory so that ownership is kept by > libavutil returns a pointer to the rectangles (with bounds checking and > so on on the caller): > > > > av_video_hint_create_side_data(AVFrame *frame, AVVideoHintType type); > > AVVideoRect* av_video_hint_set_number_of_rectangles( > AVVideoHint *video_hint, > size_t n_rects, > AVVideoHintType changed_flag); > (Names can change I just want to convey a possible api). > > Would that work for you? > > Or, do you prefer a creation api which already allocates memory and > sets the number of rectangles but doesn't copy them and that's > responsibility on the caller? > What I'd like in this latter case is that (like now) memory would be > flat with no need for specific custom deallocators. > Something along the lines: > > > AVVideoHint *av_video_hint_create_side_data(AVFrame *frame, > size_t n_rects, > AVVideoHintType type); > > AVVideoRect *av_video_hint_get_rects(AVVideoHint *video_hint); > > > Third option: side information creation api and the caller has to > alloc/realloc the rectangle buffer and hand out ownership to libavutil, > but I guess this is the worst one for various reasons. > > I do not see any further option.
What I'm proposing is this: AVVideoHint *av_video_hint_create_side_data(AVFrame *frame, size_t num_rects); AVVideoHint *av_video_hint_alloc(size_t nb_rects, size_t *out_size); The caller filles the type and the rectangles manually. > > AVVideoEncParams describes the block-level parameters of an encoded > > bitstream. Yes, it is currently used to export coded bitstream > > information from decoders. But there is no restriction or assumption > > in > > the API itself that it will be used in this way and it can just as > > well > > describe the information you want a coded bitstream to have. > > > > > Right, but in this case it's not something which is going to end up > into the bitstream, since this is *not* and api to set some bitstream > properties but really just provide some information which the encoder > can exploit. > > So it's definitely a different semantics and I do not think it fits > well into AVVideoEncParams (frankly I think it's wrong), however if we > are clear on this and that's what you really want and that's what we > need to do to get the patch in, well I have no issue changing the code. Ok, I see your point and drop my objection. -- Anton Khirnov _______________________________________________ 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".
