> On May 16, 2023, at 15:52, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > > On Tue, May 16, 2023 at 4:07 AM Xiang, Haihao > <haihao.xiang-at-intel....@ffmpeg.org> wrote: >> >> From: Haihao Xiang <haihao.xi...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ 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".
