On Tue, Apr 14, 2020 at 3:57 AM Ryo Hirafuji <ryo.hiraf...@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. _______________________________________________ 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".
