[FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_get_buffer2

["zhilizhao(赵志立)"]

> On May 16, 2023, at 15:52, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> 
> On Tue, May 16, 2023 at 4:07 AM Xiang, Haihao
> <haihao.xiang-at-intel.com at ffmpeg.org> wrote:
>> 
>> From: Haihao Xiang <haihao.xiang at intel.com>
>> 
>> Intel MediaSDK and oneVPL expect contiguous allocation for data[i],
>> however there are mandatory padding bytes between data[i] and data[i+1].
>> when calling av_frame_get_buffer. So adding av_frame_get_buffer2 to
>> allow caller to specify the length of padding bytes.
>> 
> 
> get_video_buffer will also pad the height to a multiple of 32, won't
> that again cause issues?
> I don't think the API even necessarily guarantees that its going to be
> one contiguous buffer, it just happens to be the way its made right
> now.
> 
> If a new API is introduced, maybe it should be very tailor designed to
> offer these guarantees, and named appropriate, not introducing any
> padding - padded height or extra padding, or otherwise.

If there is more use cases, the new API should be more general.
Current use case isn’t a strong reason for the new API.

It looks like the internal implementation of hwcontext_qsv and
qsvenc use AVFrame as temporary variables for convenience. They
can be replaced by internal defined struct or POD, and copy data
by av_image_copy. Although it’s more code to change.

> 
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".