[FFmpeg-devel] [PATCH] frame: Simplify the video allocation

Maxym Dmytrychenko maxim.d33 at gmail.com
Tue Sep 11 22:31:40 EEST 2018


On Tue, Sep 11, 2018 at 6:43 PM James Almer <jamrial at gmail.com> wrote:

> On 9/3/2018 6:03 AM, Maxym Dmytrychenko wrote:
> > On Mon, Sep 3, 2018 at 10:17 AM Michael Niedermayer
> <michael at niedermayer.cc>
> > wrote:
> >
> >> On Sun, Sep 02, 2018 at 09:34:23PM -0300, James Almer wrote:
> >>> From: Luca Barbato <lu_zero at gentoo.org>
> >>>
> >>> Merged-by: James Almer <jamrial at gmail.com>
> >>> ---
> >>> This is the next merge in the queue. It's a critical part of the
> AVFrame
> >> API,
> >>> so even if FATE passes I'd rather have others look at it and test in
> case
> >>> something breaks.
> >>>
> >>> The only difference compared to the libav commit is the "32 - 1"
> padding
> >> per
> >>> plane when allocating the buffer, which was only in our tree.
> >>
> >> why is the STRIDE_ALIGN (which is a thing in units of bytes along the
> >> horizontal axis) added to padded_height which is vertical axis ?
> >> This is not done prior to the change
> >>
> >> Also if this changes how buffers are structured or sized it requires a
> more
> >> detailed commit message than "frame: Simplify the video allocation"
> >>
> >>
> > If can help:
> > Use of av_image_fill_pointers() helps to allocate planes continuously
> > instead of separate allocation for each plane,
> > which can end up in very different start locations of the allocated
> memory.
> >
> > Continuous allocation can be better for performance and/or functional
> sides
> > of the operations,
> > example of Intel's HW - QSV,
> > which is assuming Y/UV planes to be continuously allocated.
>
> I just merged this commit and the next, "qsv: enforcing continuous
> memory layout" of your authoring, where one line checks the distance
> between frame->data[1] and frame->data[0] to ensure the buffer is
> continuous. This check, with the padding in our av_frame_get_buffer()
> implementation, will probably always fail, but i can't test it.
>
> Can you look into it, if that's indeed the case?
>

just finished my test cases and it seems to be just fine,
fixes the original, non-deterministic problem.

distance between frame->data[1] and frame->data[0]  is not always
non-continuous(and causes the problem)
where now av_frame_get_buffer()  fixes such corner case.

thanks, James

regards
Max


More information about the ffmpeg-devel mailing list