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. 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.) - Mark _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
