Hi,
On Thu, Jan 2, 2025 at 5:48 PM James Almer <jamr...@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
_______________________________________________
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".
