After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 730925 - MADI doesn't respect hardware limits, and assumes that any surface type is acceptable as the reference surface
MADI doesn't respect hardware limits, and assumes that any surface type is ac...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-05-29 09:36 UTC by Simon Farnsworth
Modified: 2018-11-03 15:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
vaapipostproc: prevent advanced-deinterlacing of non-native video formats. (2.63 KB, patch)
2015-06-25 10:43 UTC, sreerenj
committed Details | Review

Description Simon Farnsworth 2014-05-29 09:36:41 UTC
As per https://bugs.freedesktop.org/show_bug.cgi?id=79377#c2 I'm filing this bug.

When I have a YUY2 source feeding gstreamer-vaapi with the patch at https://bugzilla.gnome.org/show_bug.cgi?id=726361 applied, I get horrible colour effects from the deinterlacing. My pipeline is:

gst-launch-1.0 v4l2src ! vaapipostproc deinterlace-mode=interlaced deinterlace-method=motion-adaptive ! vaapisink

gstreamer-vaapi provides YUY2 surfaces to VPP for deinterlacing; SNB and IVB can only deinterlace NV12, so I get horrible artifacting.
Comment 1 Gwenole Beauchesne 2014-06-18 17:20:58 UTC
Hmm, sorry, you are right. This is an omission from the specs. The reference surfaces must have the same format as used internally. In particular, this is NV12. Still, the driver should still accept YUY2 sources.

I think we should amend the specs to report that the first PixelFormat format returned for a VPP pipeline(*) is the "native" (internal) format and shall be the one used for reference.

(*) vaQuerySurfaceAttributes() with a VPP config.
Comment 2 Simon Farnsworth 2014-06-19 09:11:59 UTC
That would work for today's hardware.

What would you do to cope if future hardware supports other reference frame formats (e.g. YV16 to enable it to deinterlace in 4:2:2 as well as 4:2:0)? Add a new query?
Comment 3 sreerenj 2015-06-25 10:43:11 UTC
Created attachment 306083 [details] [review]
vaapipostproc: prevent advanced-deinterlacing of non-native  video formats.

This is only a temporary work-around intended for 0.6 release. Fail it in negotiation step itself for advanced-deinterlacing of non-native video input formats.

A better solution could be to do the color space conversion internally(inside vaapipostproc) for reference surfaces.
Comment 4 sreerenj 2015-06-29 10:33:50 UTC
Pushed,
commit a1eef1c35505ae5df9d96ed98eab5c928da77e06
Author: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Date:   Mon Jun 29 13:20:28 2015 +0300

Keeping this bug report open to track further improvements..
Comment 5 sreerenj 2016-03-24 16:55:26 UTC
Moving to Product:GStreamer, Component:gstreamer-vaapi
Comment 6 Víctor Manuel Jáquez Leal 2017-07-27 09:24:14 UTC
Comment on attachment 306083 [details] [review]
vaapipostproc: prevent advanced-deinterlacing of non-native  video formats.

marking as committed because it was committed already :)
Comment 7 Víctor Manuel Jáquez Leal 2017-07-27 09:35:57 UTC
Complete the previous patch and close the bug seems to be easy, since all the pieces are already in place.
Comment 8 GStreamer system administrator 2018-11-03 15:45:08 UTC
-- 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/15.