[FFmpeg-devel] [PATCH] avcodec.h: document padding requirements for get_buffer() callback.

[Ronald S. Bultje]

Hi,

On Thu, Jan 2, 2025 at 5:48 PM James Almer <jamrial at gmail.com> wrote:

> On 1/2/2025 7:39 PM, Ronald S. Bultje wrote:
> > ---
> >   libavcodec/avcodec.h | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 12e6e8749f..7ecb819dae 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -1199,7 +1199,8 @@ typedef struct AVCodecContext {
> >        * some other means.
> >        *
> >        * Each data plane must be aligned to the maximum required by the
> target
> > -     * CPU.
> > +     * CPU. In addition, each data plane must be padded by that same
> amount
> > +     * plus 15 bytes.
>
> IMO, remove the 15 bytes part. Even if the default allocator adds those,
> asking for max_cpu_align padding bytes should be more than enough.
>

I'm guessing part of the reason here is to codify (or remove) the 15. Our
default implementation explicitly uses 16 + STRIDE_ALIGN - 1. I think we
should document that as expected in application-provided implementations,
or remove it.


> And for that matter, see fuzz_video_get_buffer() in
> tools/target_dec_fuzzer.c, where no such thing is done precisely to
> simulate what a user reading this doxy might do with their own custom
> callback. This padding should in theory not be a requirement when
> avcodec_align_dimensions2() is documented as handling this stuff.
>

I assume the fuzzer runs on x86, so that doesn't expose behaviour in SIMD
on alternate platforms.


> Maybe avcodec_align_dimensions2() should be updated for VP9 to
> overallocate? I see it does for h264, vp6 and many other codecs where
> the native decoder overreads for different reasons.
>

That aligns, but doesn't pad. I mean literal buffer padding, like:

https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/get_buffer.c;h=b391adf24f45723ef994b133513a7b49b2fa3981;hb=HEAD#l122

Ronald