GNOME Bugzilla – Bug 797095
vaapipostproc: deinterlace does not take effect with media-driver
Last modified: 2018-10-10 01:30:19 UTC
Created attachment 373557 [details] Log of libva and media driver The issue is from https://github.com/intel/media-driver/issues/181. It is a Decode+DI case. I checked it on media driver side, found that gstreamer-vaapi didn’t call VP pipeline to do deinterlace. For such Decode+DI case, after decoding, vp context should be created, and then setup DI parameters, and then call VP pipeline to do DI processing.
did you check with vaapi-intel-driver?
(In reply to Víctor Manuel Jáquez Leal from comment #1) > did you check with vaapi-intel-driver? Yes, if using vaapi-intel-driver, it do take effect, but the output is not expected, a black bar can obviously seen at top and bottom of the video, it seems two field is simply splitted into two frames. And when change to using different deinterlace method, it doesn't work and always output the same result.
Can you share the media sample? H264_Main@L2.2_0720x0576_03.9Mbps_10.0fps_Interlaced_Sound_ToTheLimit@.mp4
Created attachment 373582 [details] media sample
It seems like it's due to the reason where gstreamer-vaapi will only call driver's VP pipeline if it's ADI. Code as below in gst/vaapi/gstvaapipostproc.c: if (postproc->flags) { /* Use VA/VPP extensions to process this frame */ if (postproc->has_vpp && (postproc->flags != GST_VAAPI_POSTPROC_FLAG_DEINTERLACE || deint_method_is_advanced (postproc->deinterlace_method))) { ret = gst_vaapipostproc_process_vpp (trans, buf, outbuf); if (ret != GST_FLOW_NOT_SUPPORTED) goto done; GST_WARNING_OBJECT (postproc, "unsupported VPP filters. Disabling"); } /* Only append picture structure meta data (top/bottom field) */ if (postproc->flags & GST_VAAPI_POSTPROC_FLAG_DEINTERLACE) { ret = gst_vaapipostproc_process (trans, buf, outbuf); if (ret != GST_FLOW_NOT_SUPPORTED) goto done; } } I did a quick test on my side by calling gst_vaapipostproc_process_vpp even though it's not ADI, and BOB deinterlace works correctly with media driver. Is there any specific reason with the current code where it will call VP pipeline only if it's ADI?
Created attachment 373829 [details] [review] vaapipostproc: change the way of handling deinterlace I am trying to resolve this issue with the attached patch. Can you please review if the change make sense?
Comment on attachment 373829 [details] [review] vaapipostproc: change the way of handling deinterlace Thanks for the patch! A couple first questions: 1. What does mean VP? video processing? 2. What does mean ADI? A-de-interlace? 3. Did you tested it without VPP capability support?
(In reply to Víctor Manuel Jáquez Leal from comment #7) > Comment on attachment 373829 [details] [review] [review] > vaapipostproc: change the way of handling deinterlace > > Thanks for the patch! > > A couple first questions: > > 1. What does mean VP? video processing? Yes VP refers to video processing. > 2. What does mean ADI? A-de-interlace? That's referring to Adcanced deinterlacing > 3. Did you tested it without VPP capability support? Ouch. Sorry I missed that. I updated the patch so that it remains appending the picture structure meta data when it does not have VPP capabilities support. The changes is very simple now by not limiting driver's deinterlacing capabilities for advance method only.
Created attachment 373831 [details] [review] vaapipostproc: change the way of handling deinterlace v2
attachment 373831 [details] [review] was pushed as commit ee27377c - vaapipostproc: change the way of handling deinterlaced
Thanks all of you.