[FFmpeg-devel] [PATCH] Optimization: support for libx264's mb_info

[Anton Khirnov]

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