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

[Ryo Hirafuji]

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.


> 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)

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).

2020年4月14日(火) 6:25 James Zern <jzern-at-google.com at ffmpeg.org>:

> Hi,
>
> On Tue, Apr 7, 2020 at 5:14 PM Ryo Hirafuji <ryo.hirafuji at gmail.com>
> wrote:
> >
> > From: Ryo Hirafuji <psi at 7io.org>
> >
> > AV1 decoders, libaomdec and libdav1d, both support grayscale image.
> > However, libaomenc does not support it yet.
> > In this patch, I add a grayscale image support also to libaomenc.
> >
> > Fixes ticket #7599
> > ---
> >  libavcodec/libaomenc.c | 40 +++++++++++++++++++++++++++++++++-------
> >  1 file changed, 33 insertions(+), 7 deletions(-)
> >
>
> This should bump the micro version number in libavcodec/version.h.
>
> > [...]
> > @@ -979,12 +986,27 @@ static int aom_encode(AVCodecContext *avctx,
> AVPacket *pkt,
> >
> >      if (frame) {
> >          rawimg                      = &ctx->rawimg;
> > -        rawimg->planes[AOM_PLANE_Y] = frame->data[0];
> > -        rawimg->planes[AOM_PLANE_U] = frame->data[1];
> > -        rawimg->planes[AOM_PLANE_V] = frame->data[2];
> > -        rawimg->stride[AOM_PLANE_Y] = frame->linesize[0];
> > -        rawimg->stride[AOM_PLANE_U] = frame->linesize[1];
> > -        rawimg->stride[AOM_PLANE_V] = frame->linesize[2];
> > +        if (frame->format == AV_PIX_FMT_GRAY8 ||
> > +            frame->format == AV_PIX_FMT_GRAY10 ||
> > +            frame->format == AV_PIX_FMT_GRAY12) {
> > +            rawimg->monochrome = 1;
> > +            // Information of U and V planes are ignored,
> > +            // but must point some valid pointer to avoid SIGSEGV of
> 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.
> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".