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....@ffmpeg.org>: > Hi, > > On Tue, Apr 7, 2020 at 5:14 PM Ryo Hirafuji <ryo.hiraf...@gmail.com> > wrote: > > > > From: Ryo Hirafuji <p...@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-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ 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".
