| 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 | expand |
| Context | Check | Description |
|---|---|---|
| andriy/ffmpeg-patchwork | success | Make fate finished |
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".
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
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".
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.
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". >
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
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".
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". > >
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
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 --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,
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(-)