diff mbox series

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

Message ID 20200408001341.65204-1-ryo.hirafuji@gmail.com
State New
Headers show
Series [FFmpeg-devel,v4,1/2] libavcodec/libaomenc.c: Support gray input
Related show

Checks

Context Check Description
andriy/ffmpeg-patchwork pending
andriy/ffmpeg-patchwork success Applied patch
andriy/ffmpeg-patchwork success Configure finished
andriy/ffmpeg-patchwork success Make finished
andriy/ffmpeg-patchwork success Make fate finished

Commit Message

Ryo Hirafuji April 8, 2020, 12:13 a.m. UTC
From: Ryo Hirafuji <psi@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(-)

Comments

Ryo Hirafuji April 11, 2020, 3:23 p.m. UTC | #1
Hi!

I would like to discuss this patch, but I can't find who is the maintainer
of this codec.
https://github.com/FFmpeg/FFmpeg/blob/master/MAINTAINERS
Does anyone know?

If something was BAD, I would like to rewrite it better.
If splitting this patch into gray support and lossless support patch is
better, I will do so.

Best,
Ryo.

2020年4月8日(水) 9:14 Ryo Hirafuji <ryo.hirafuji@gmail.com>:

> From: Ryo Hirafuji <psi@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(-)
>
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 096aadbe1c..ff79c0af9f 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -154,7 +154,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
>      av_log(avctx, level, "aom_codec_enc_cfg\n");
>      av_log(avctx, level, "generic settings\n"
>                           "  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n"
> -                         "  %*s%u\n  %*s%u\n"
> +                         "  %*s%u\n  %*s%u\n  %*s%u\n"
>                           "  %*s{%u/%u}\n  %*s%u\n  %*s%d\n  %*s%u\n",
>             width, "g_usage:",           cfg->g_usage,
>             width, "g_threads:",         cfg->g_threads,
> @@ -163,6 +163,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
>             width, "g_h:",               cfg->g_h,
>             width, "g_bit_depth:",       cfg->g_bit_depth,
>             width, "g_input_bit_depth:", cfg->g_input_bit_depth,
> +           width, "monochrome:",        cfg->monochrome,
>             width, "g_timebase:",        cfg->g_timebase.num,
> cfg->g_timebase.den,
>             width, "g_error_resilient:", cfg->g_error_resilient,
>             width, "g_pass:",            cfg->g_pass,
> @@ -276,7 +277,9 @@ static int set_pix_fmt(AVCodecContext *avctx,
> aom_codec_caps_t codec_caps,
>      AOMContext av_unused *ctx = avctx->priv_data;
>      enccfg->g_bit_depth = enccfg->g_input_bit_depth = 8;
>      switch (avctx->pix_fmt) {
> +    case AV_PIX_FMT_GRAY8:
>      case AV_PIX_FMT_YUV420P:
> +        enccfg->monochrome = avctx->pix_fmt == AV_PIX_FMT_GRAY8;
>          enccfg->g_profile = FF_PROFILE_AV1_MAIN;
>          *img_fmt = AOM_IMG_FMT_I420;
>          return 0;
> @@ -288,9 +291,13 @@ static int set_pix_fmt(AVCodecContext *avctx,
> aom_codec_caps_t codec_caps,
>          enccfg->g_profile = FF_PROFILE_AV1_HIGH;
>          *img_fmt = AOM_IMG_FMT_I444;
>          return 0;
> +    case AV_PIX_FMT_GRAY10:
> +    case AV_PIX_FMT_GRAY12:
>      case AV_PIX_FMT_YUV420P10:
>      case AV_PIX_FMT_YUV420P12:
>          if (codec_caps & AOM_CODEC_CAP_HIGHBITDEPTH) {
> +            enccfg->monochrome = avctx->pix_fmt == AV_PIX_FMT_GRAY10 ||
> +                                 avctx->pix_fmt == AV_PIX_FMT_GRAY12;
>              enccfg->g_bit_depth = enccfg->g_input_bit_depth =
>                  avctx->pix_fmt == AV_PIX_FMT_YUV420P10 ? 10 : 12;
>              enccfg->g_profile =
> @@ -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.
> +            rawimg->planes[AOM_PLANE_Y] = frame->data[0];
> +            rawimg->planes[AOM_PLANE_U] = frame->data[0];
> +            rawimg->planes[AOM_PLANE_V] = frame->data[0];
> +            rawimg->stride[AOM_PLANE_Y] = frame->linesize[0];
> +            rawimg->stride[AOM_PLANE_U] = frame->linesize[0];
> +            rawimg->stride[AOM_PLANE_V] = frame->linesize[0];
> +        } else {
> +            rawimg->monochrome = 0;
> +            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];
> +        }
>          timestamp                   = frame->pts;
>          switch (frame->color_range) {
>          case AVCOL_RANGE_MPEG:
> @@ -1025,6 +1047,7 @@ static int aom_encode(AVCodecContext *avctx,
> AVPacket *pkt,
>  }
>
>  static const enum AVPixelFormat av1_pix_fmts[] = {
> +    AV_PIX_FMT_GRAY8,
>      AV_PIX_FMT_YUV420P,
>      AV_PIX_FMT_YUV422P,
>      AV_PIX_FMT_YUV444P,
> @@ -1032,6 +1055,9 @@ static const enum AVPixelFormat av1_pix_fmts[] = {
>  };
>
>  static const enum AVPixelFormat av1_pix_fmts_highbd[] = {
> +    AV_PIX_FMT_GRAY8,
> +    AV_PIX_FMT_GRAY10,
> +    AV_PIX_FMT_GRAY12,
>      AV_PIX_FMT_YUV420P,
>      AV_PIX_FMT_YUV422P,
>      AV_PIX_FMT_YUV444P,
> --
> 2.20.1
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
James Zern April 13, 2020, 8:56 p.m. UTC | #2
Hi,

On Tue, Apr 7, 2020 at 5:14 PM Ryo Hirafuji <ryo.hirafuji@gmail.com> wrote:
>
> From: Ryo Hirafuji <psi@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
Ryo Hirafuji April 14, 2020, 10:51 a.m. UTC | #3
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@... 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@ffmpeg.org>:

> Hi,
>
> On Tue, Apr 7, 2020 at 5:14 PM Ryo Hirafuji <ryo.hirafuji@gmail.com>
> wrote:
> >
> > From: Ryo Hirafuji <psi@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@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
James Zern April 15, 2020, 12:26 a.m. UTC | #4
On Tue, Apr 14, 2020 at 3:57 AM Ryo Hirafuji <ryo.hirafuji@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@... 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.
James Almer April 15, 2020, 3:08 p.m. UTC | #5
On 4/14/2020 9:26 PM, James Zern wrote:
> On Tue, Apr 14, 2020 at 3:57 AM Ryo Hirafuji <ryo.hirafuji@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.

Once a new version of libaom is tagged (Hopefully soon, since it's been
almost two years since 1.0.0), we could set it as the minimum
requirement and forget about 1.0.0, since that version is by now
essentially unusable.

> 
>>
>>> 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@... 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.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
James Zern April 15, 2020, 5:58 p.m. UTC | #6
On Wed, Apr 15, 2020 at 8:14 AM James Almer <jamrial@gmail.com> wrote:
>
> On 4/14/2020 9:26 PM, James Zern wrote:
> > On Tue, Apr 14, 2020 at 3:57 AM Ryo Hirafuji <ryo.hirafuji@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.
>
> Once a new version of libaom is tagged (Hopefully soon, since it's been
> almost two years since 1.0.0), we could set it as the minimum
> requirement and forget about 1.0.0, since that version is by now
> essentially unusable.
>

Thanks, that was my hope. I just wasn't sure how long we wanted to
wait before changing the minimum. You're right though, the only tags
are old and were more for bitstream compatibility rather than encoder
functionality. A full release should be coming soon [1] and with more
regular frequency after that.

[1] https://crbug.com/aomedia/2545
Ryo Hirafuji May 9, 2020, 3:59 p.m. UTC | #7
Hi.

https://crbug.com/aomedia/2545

This bug is resolved and we no longer need these lines to avoid crash in
libaom.

> -        rawimg->planes[AOM_PLANE_U] = frame->data[1];
> -        rawimg->planes[AOM_PLANE_V] = frame->data[2];
> -        rawimg->stride[AOM_PLANE_U] = frame->linesize[1];
> -        rawimg->stride[AOM_PLANE_V] = frame->linesize[2];

I can create and send a new patch without these workaround lines, but of
course, it will crash if the ffmpeg will be built with older versions of
libaom.
How should I resolve this backward compatibility issue? or I don't have to
consider it?

Please give me some advice.


2020年4月16日(木) 2:58 James Zern <jzern-at-google.com@ffmpeg.org>:

> On Wed, Apr 15, 2020 at 8:14 AM James Almer <jamrial@gmail.com> wrote:
> >
> > On 4/14/2020 9:26 PM, James Zern wrote:
> > > On Tue, Apr 14, 2020 at 3:57 AM Ryo Hirafuji <
> ryo.hirafuji@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.
> >
> > Once a new version of libaom is tagged (Hopefully soon, since it's been
> > almost two years since 1.0.0), we could set it as the minimum
> > requirement and forget about 1.0.0, since that version is by now
> > essentially unusable.
> >
>
> Thanks, that was my hope. I just wasn't sure how long we wanted to
> wait before changing the minimum. You're right though, the only tags
> are old and were more for bitstream compatibility rather than encoder
> functionality. A full release should be coming soon [1] and with more
> regular frequency after that.
>
> [1] https://crbug.com/aomedia/2545
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Ryo Hirafuji May 9, 2020, 4:05 p.m. UTC | #8
Sorry,

Resolved bug is this:
https://bugs.chromium.org/p/aomedia/issues/detail?id=2639

and we no longer need these lines:

+            rawimg->planes[AOM_PLANE_U] = frame->data[0];
+            rawimg->planes[AOM_PLANE_V] = frame->data[0];
+            rawimg->stride[AOM_PLANE_U] = frame->linesize[0];
+            rawimg->stride[AOM_PLANE_V] = frame->linesize[0];

2020年5月10日(日) 0:59 Ryo Hirafuji <ryo.hirafuji@link-u.co.jp>:

> Hi.
>
> https://crbug.com/aomedia/2545
>
> This bug is resolved and we no longer need these lines to avoid crash in
> libaom.
>
> > -        rawimg->planes[AOM_PLANE_U] = frame->data[1];
> > -        rawimg->planes[AOM_PLANE_V] = frame->data[2];
> > -        rawimg->stride[AOM_PLANE_U] = frame->linesize[1];
> > -        rawimg->stride[AOM_PLANE_V] = frame->linesize[2];
>
> I can create and send a new patch without these workaround lines, but of
> course, it will crash if the ffmpeg will be built with older versions of
> libaom.
> How should I resolve this backward compatibility issue? or I don't have to
> consider it?
>
> Please give me some advice.
>
>
> 2020年4月16日(木) 2:58 James Zern <jzern-at-google.com@ffmpeg.org>:
>
>> On Wed, Apr 15, 2020 at 8:14 AM James Almer <jamrial@gmail.com> wrote:
>> >
>> > On 4/14/2020 9:26 PM, James Zern wrote:
>> > > On Tue, Apr 14, 2020 at 3:57 AM Ryo Hirafuji <
>> ryo.hirafuji@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.
>> >
>> > Once a new version of libaom is tagged (Hopefully soon, since it's been
>> > almost two years since 1.0.0), we could set it as the minimum
>> > requirement and forget about 1.0.0, since that version is by now
>> > essentially unusable.
>> >
>>
>> Thanks, that was my hope. I just wasn't sure how long we wanted to
>> wait before changing the minimum. You're right though, the only tags
>> are old and were more for bitstream compatibility rather than encoder
>> functionality. A full release should be coming soon [1] and with more
>> regular frequency after that.
>>
>> [1] https://crbug.com/aomedia/2545
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
>
Moritz Barsnick June 8, 2020, 9:56 a.m. UTC | #9
On Sun, May 10, 2020 at 00:59:25 +0900, Ryo Hirafuji wrote:
> I can create and send a new patch without these workaround lines, but of
> course, it will crash if the ffmpeg will be built with older versions of
> libaom.

Actually, it depends on the runtime version of the library, not which
version it was built against. (They can differ.)

You could encapsulate the code into a check of aom_codec_version() >
(1<<16|0<<8|0). Assuming 1.0.0 is the current, buggy release.

> How should I resolve this backward compatibility issue? or I don't have to
> consider it?

Having a workaround for a known issue does not hurt, IMO, especially
since a fixed version is not available yet (or is it?).

Moritz
James Zern June 8, 2020, 6:12 p.m. UTC | #10
On Mon, Jun 8, 2020 at 2:56 AM Moritz Barsnick <barsnick@gmx.net> wrote:
>
> On Sun, May 10, 2020 at 00:59:25 +0900, Ryo Hirafuji wrote:
> > I can create and send a new patch without these workaround lines, but of
> > course, it will crash if the ffmpeg will be built with older versions of
> > libaom.
>
> Actually, it depends on the runtime version of the library, not which
> version it was built against. (They can differ.)
>
> You could encapsulate the code into a check of aom_codec_version() >
> (1<<16|0<<8|0). Assuming 1.0.0 is the current, buggy release.
>
> > How should I resolve this backward compatibility issue? or I don't have to
> > consider it?
>
> Having a workaround for a known issue does not hurt, IMO, especially
> since a fixed version is not available yet (or is it?).
>

2.0.0 is out. libaomenc.c just got an update to remove the
experimental flag when it's present:
https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/49d37b4b618b20669bbd7081e6af2aecf9c09745?hp=4bc5eb27a74e3eb1805f21a33d4ef08f8f7026e4
diff mbox series

Patch

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 096aadbe1c..ff79c0af9f 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -154,7 +154,7 @@  static av_cold void dump_enc_cfg(AVCodecContext *avctx,
     av_log(avctx, level, "aom_codec_enc_cfg\n");
     av_log(avctx, level, "generic settings\n"
                          "  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n"
-                         "  %*s%u\n  %*s%u\n"
+                         "  %*s%u\n  %*s%u\n  %*s%u\n"
                          "  %*s{%u/%u}\n  %*s%u\n  %*s%d\n  %*s%u\n",
            width, "g_usage:",           cfg->g_usage,
            width, "g_threads:",         cfg->g_threads,
@@ -163,6 +163,7 @@  static av_cold void dump_enc_cfg(AVCodecContext *avctx,
            width, "g_h:",               cfg->g_h,
            width, "g_bit_depth:",       cfg->g_bit_depth,
            width, "g_input_bit_depth:", cfg->g_input_bit_depth,
+           width, "monochrome:",        cfg->monochrome,
            width, "g_timebase:",        cfg->g_timebase.num, cfg->g_timebase.den,
            width, "g_error_resilient:", cfg->g_error_resilient,
            width, "g_pass:",            cfg->g_pass,
@@ -276,7 +277,9 @@  static int set_pix_fmt(AVCodecContext *avctx, aom_codec_caps_t codec_caps,
     AOMContext av_unused *ctx = avctx->priv_data;
     enccfg->g_bit_depth = enccfg->g_input_bit_depth = 8;
     switch (avctx->pix_fmt) {
+    case AV_PIX_FMT_GRAY8:
     case AV_PIX_FMT_YUV420P:
+        enccfg->monochrome = avctx->pix_fmt == AV_PIX_FMT_GRAY8;
         enccfg->g_profile = FF_PROFILE_AV1_MAIN;
         *img_fmt = AOM_IMG_FMT_I420;
         return 0;
@@ -288,9 +291,13 @@  static int set_pix_fmt(AVCodecContext *avctx, aom_codec_caps_t codec_caps,
         enccfg->g_profile = FF_PROFILE_AV1_HIGH;
         *img_fmt = AOM_IMG_FMT_I444;
         return 0;
+    case AV_PIX_FMT_GRAY10:
+    case AV_PIX_FMT_GRAY12:
     case AV_PIX_FMT_YUV420P10:
     case AV_PIX_FMT_YUV420P12:
         if (codec_caps & AOM_CODEC_CAP_HIGHBITDEPTH) {
+            enccfg->monochrome = avctx->pix_fmt == AV_PIX_FMT_GRAY10 ||
+                                 avctx->pix_fmt == AV_PIX_FMT_GRAY12;
             enccfg->g_bit_depth = enccfg->g_input_bit_depth =
                 avctx->pix_fmt == AV_PIX_FMT_YUV420P10 ? 10 : 12;
             enccfg->g_profile =
@@ -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.
+            rawimg->planes[AOM_PLANE_Y] = frame->data[0];
+            rawimg->planes[AOM_PLANE_U] = frame->data[0];
+            rawimg->planes[AOM_PLANE_V] = frame->data[0];
+            rawimg->stride[AOM_PLANE_Y] = frame->linesize[0];
+            rawimg->stride[AOM_PLANE_U] = frame->linesize[0];
+            rawimg->stride[AOM_PLANE_V] = frame->linesize[0];
+        } else {
+            rawimg->monochrome = 0;
+            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];
+        }
         timestamp                   = frame->pts;
         switch (frame->color_range) {
         case AVCOL_RANGE_MPEG:
@@ -1025,6 +1047,7 @@  static int aom_encode(AVCodecContext *avctx, AVPacket *pkt,
 }
 
 static const enum AVPixelFormat av1_pix_fmts[] = {
+    AV_PIX_FMT_GRAY8,
     AV_PIX_FMT_YUV420P,
     AV_PIX_FMT_YUV422P,
     AV_PIX_FMT_YUV444P,
@@ -1032,6 +1055,9 @@  static const enum AVPixelFormat av1_pix_fmts[] = {
 };
 
 static const enum AVPixelFormat av1_pix_fmts_highbd[] = {
+    AV_PIX_FMT_GRAY8,
+    AV_PIX_FMT_GRAY10,
+    AV_PIX_FMT_GRAY12,
     AV_PIX_FMT_YUV420P,
     AV_PIX_FMT_YUV422P,
     AV_PIX_FMT_YUV444P,