> From: libav-devel [mailto:[email protected]] On Behalf Of Mark > Thompson > Sent: Monday, April 2, 2018 8:45 PM > To: [email protected] > Subject: Re: [libav-devel] [PATCH V2 2/3] lavu/hwcontext_qsv: Add support > for pix_fmt RGB32. > > On 02/04/18 10:32, Li, Zhong wrote: > >>> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c > >>> index 5018a05..0db446b 100644 > >>> --- a/libavutil/hwcontext_qsv.c > >>> +++ b/libavutil/hwcontext_qsv.c > >>> ... > >>> + surface->Data.Y = frame->data[0]; > >>> + surface->Data.UV = frame->data[1]; > >>> + break; > >>> + > >>> + case AV_PIX_FMT_YUV420P: > >>> + surface->Data.Y = frame->data[0]; > >>> + surface->Data.U = frame->data[1]; > >>> + surface->Data.V = frame->data[2]; > >>> + break; > >>> + > >>> + case AV_PIX_FMT_RGB32: > >>> + surface->Data.B = frame->data[0]; > >>> + surface->Data.G = frame->data[0] + 1; > >>> + surface->Data.R = frame->data[0] + 2; > >>> + surface->Data.A = frame->data[0] + 3; > >>> + break; > >>> + > >>> + default: > >>> + return MFX_ERR_UNSUPPORTED; > >>> + } > >>> + surface->Data.Pitch = frame->linesize[0]; > >> > >> What happens if linesize[0] != linesize[1]? (You aren't introducing > >> that problem, but I hadn't seen it before.) > > > > I don't think MSDK can handle this case perfectly since there is only one > pitch. > > Take YUV420p as example, IMHO it is required linesize of Y must be twice > of U and V. > > That isn't going to be true for a general frame in libav - the pitches for > each > plane are independent. Since they are usually created by taking the width > of the plane and rounding up to the appropriate alignment (usually 32, I > think) > it will work for widths which are multiples of large powers of two - e.g. 1920 > width will work because both 1920 and 960 are already aligned to a 32-byte > boundary. It won't work for less aligned widths (e.g. 720 width from NTSC > or PAL will give luma pitch = align(720, 32) = 736 but chroma pitch = > align(360, > 32) = 384), nor will it work for other ways of laying out the frame such as > line-interleaving.
Perfectly correct. Actually I've seen a bug when transcoding a 720x480 clips. In that case, must 64 bytes aligned to make sure luma_pitch = 2 x chroma_pitch. > This problem was preexisting, though, so I guess it isn't necessary to deal > with it in this patch. Not sure what the right answer is - maybe it could > just > reject non-matching pitches and return an error? Or it could make a > temporary frame with the stricter alignment and copy to that before > uploading? (Though that might be slow and defeat the point of this upload > path.) "Return an error" is not user-friendly because they can do nothing after receive such an error message. Agree with Maxym, I prefer the second option too and there are existing piece of code to handle the cases haven't aligned as libmfx's requirement (though haven't handle the 720x480 yuv420p issue). But I'm not sure why it will "defeat the point of this upload path". Could you help to give some detail info? _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
