> On May 16, 2023, at 15:52, Hendrik Leppkes <[email protected]> wrote: > > On Tue, May 16, 2023 at 4:07 AM Xiang, Haihao > <[email protected]> wrote: >> >> From: Haihao Xiang <[email protected]> >> >> 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 > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
