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

["Xiang, Haihao" <haihao.xiang-at-intel.com@ffmpeg.org>]

On Di, 2023-05-16 at 16:22 +0800, zhilizhao(赵志立) wrote:
> 
> > On May 16, 2023, at 15:52, Hendrik Leppkes <h.leppkes@gmail.com> wrote:
> > 
> > On Tue, May 16, 2023 at 4:07 AM Xiang, Haihao
> > <haihao.xiang-at-intel.com@ffmpeg.org> wrote:
> > > 
> > > From: Haihao Xiang <haihao.xiang@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-request@ffmpeg.org with subject "unsubscribe".