GNOME Bugzilla – Bug 793678
vaapipostproc: if dmabuf then disable deinterlace
Last modified: 2018-11-03 15:53:05 UTC
dmabuf can contain interlaced content, but, as far as I understand, the sink should have the mechanism to deinterlace dmabuf-based buffers. For example, when using EGL_EXT_image_dma_buf_import[1], two EGLImages should be generated from one dmabuf-based buffer. 1. https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
Created attachment 368683 [details] [review] vaapipostproc: if dmabuf then disable deinterlace When dmabuf-based buffers are pushed downstream, vaapipostproc should not deinterlace, that's is reponsibility of the video sink. For example, glimagesink should import the dmabuf into two EGLImages.
Review of attachment 368683 [details] [review]: Where is the glimagesink patch to support that ? Importing into seperate EGLImage does not magically deinterlace. You still have half a frame/plane in each EGL Image and need to do something if you are rendering to a progressive display.
(In reply to Nicolas Dufresne (stormer) from comment #2) > Review of attachment 368683 [details] [review] [review]: > > Where is the glimagesink patch to support that ? It is a missing part indeed. > Importing into seperate > EGLImage does not magically deinterlace. You still have half a frame/plane > in each EGL Image and need to do something if you are rendering to a > progressive display. Agreed. Rethinking the issue, I guess this is a bad option to "hide" a problem with interlaced streams with dmabuf: in-between black frames. My options: 1\ keep this and add code in glupload for deinterlacing dmabuf (??) 2\ a bug in vaapi-intel-driver VPP and it could export non-black dmabuf-based frames when deinterlacing 3\ another workaround: if deinterlacing ignore dmabuf-buf negotiation
Ok, so I missed that vaapi-intel-driver bug, so it's trying to workaround it. I just checked, and we have gldeinterlace, maybe we just need to test ?
Does vaapivideodec push A) the 2 parts (interlaced) of an image as 1 gstbuffer (so to 2 gstmemory with each one a dmabuf) or B) 2 separate gstbuffers (the 2 parts of one image are delivered on after another) ? Because gldeinterlace currently works with the B) case (it always keeps a ref on the previous buffer, see https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/ext/gl/gstgldeinterlace.c#n491) but it should not be too hard to make it compatible with the A) case.
*** Bug 797278 has been marked as a duplicate of this bug. ***
Based on the discussion here, can I say that flickering issue for deinterlacing is basically due to a bug in vaapi-intel-driver or media driver, where it would export black dmabuf-based frames and displayed directly by glimagesink on screen?
(In reply to Soon, Thean Siew from comment #7) > Based on the discussion here, can I say that flickering issue for > deinterlacing is basically due to a bug in vaapi-intel-driver or media > driver, where it would export black dmabuf-based frames and displayed > directly by glimagesink on screen? Yes, it might be a problem in the driver: when the VPP deinterlace, when requesting the second frame from the second field, the dmabuf contains a black frame, and that's the reason of the flickering when dmabuf is negotiated with interlaced media.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/83.