[Bug 793678] New: vaapipostproc: if dmabuf then disable deinterlace

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793678

Bug ID: 793678
Summary: vaapipostproc: if dmabuf then disable deinterlace
Classification: Platform
Product: GStreamer
Version: unspecified
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gstreamer-vaapi
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@igalia.com
QA Contact: gstreamer-***@lists.freedesktop.org
CC: ***@gmail.com, ***@igalia.com
GNOME version: ---

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

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793678

--- Comment #1 from Víctor Manuel Jáquez Leal <***@igalia.com> ---
Created attachment 368683
--> https://bugzilla.gnome.org/attachment.cgi?id=368683&action=edit
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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793678

--- Comment #2 from Nicolas Dufresne (stormer) <***@ndufresne.ca> ---
Review of attachment 368683:
--> (https://bugzilla.gnome.org/review?bug=793678&attachment=368683)

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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793678

--- Comment #3 from Víctor Manuel Jáquez Leal <***@igalia.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #2)

Post by "GStreamer" (GNOME Bugzilla)
Where is the glimagesink patch to support that ?

It is a missing part indeed.

Post by "GStreamer" (GNOME Bugzilla)
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

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793678

Nicolas Dufresne (stormer) <***@ndufresne.ca> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@ndufresne.ca

--- Comment #4 from Nicolas Dufresne (stormer) <***@ndufresne.ca> ---
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 ?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793678

Julien Isorce <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #5 from Julien Isorce <***@gmail.com> ---
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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793678

Víctor Manuel Jáquez Leal <***@igalia.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@intel.com

--- Comment #6 from Víctor Manuel Jáquez Leal <***@igalia.com> ---
*** Bug 797278 has been marked as a duplicate of this bug. ***

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793678

--- Comment #7 from Soon, Thean Siew <***@intel.com> ---
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?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793678

--- Comment #8 from Víctor Manuel Jáquez Leal <***@igalia.com> ---
(In reply to Soon, Thean Siew from comment #7)

Post by "GStreamer" (GNOME Bugzilla)
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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793678

GStreamer system administrator <***@gstreamer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #9 from GStreamer system administrator <***@gstreamer.net> ---
-- 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.