On Di, 2023-05-16 at 16:22 +0800, zhilizhao(赵志立) wrote: > > > 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. >
Thanks all for the comments, I'll fix this in qsv with a new patchset. BRs Haihao _______________________________________________ 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".
