how about second option : temporary frame with the stricter alignment and copy to that before uploading but with log/INFO message included ?
On Mon, Apr 2, 2018 at 2:45 PM, Mark Thompson <[email protected]> wrote: > 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 > [email protected] > https://lists.libav.org/mailman/listinfo/libav-devel _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
