[FFmpeg-devel] [PATCH v4 1/2] libavcodec/libaomenc.c: Support gray input

[James Zern]

On Tue, Apr 14, 2020 at 3:57 AM Ryo Hirafuji <ryo.hirafuji at link-u.co.jp> wrote:
>
> Thanks for the review!
>
> This should bump the micro version number in libavcodec/version.h.
>
>
> OK, I will bump up the version when the problem below is solved.
>

If we want to go for compatibility with different versions of the
library we could move forward with the patch as is, though it would be
simpler to just treat this as a bug fix in libaom.

>
> > That's annoying. I filed a bug to track [1]. The monochrome flag
> > itself seems unnecessary for the library rather than just an image
> > format, but that's another discussion.
> >
>
>  Thanks for creating the issue.
>
> You might be right.
> I just need this line to set  the monochrome flag to 1 in Sequence Header
> OBU:
> > enccfg->monochrome = 1u;
>
> This reads a little strangely to me, maybe something like: U and V
> > information is ignored, but must point to valid buffers...?
> > [1] https://crbug.com/aomedia/2639
>
>
> I pasted the stack trace when V plane and U plane are NULL and ffmpeg
> crashes:
> https://bugs.chromium.org/p/aomedia/issues/detail?id=2639#c1
> (ryoh at ... is also my account)
>

Thanks for adding the detail.

> If we allocate aom_image with aom_img_alloc function, allocated V plane and
> U plane are filled with 0 (not 128, 512 or 2048).
> And I don't have to fill them to 128 to obtain a gray image.
> (I tried it in https://github.com/link-u/cavif )
> So I think these planes are just ignored (but not sure).
>

They should be. From the stack trace it looks like a simple fix when
dealing with border extension, though that may uncover other issues.