From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 97988] [radeonsi] playing back videos with VDPAU exhibits deinterlacing/anti-aliasing issues not visible with VA-API Date: Fri, 30 Sep 2016 22:58:22 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0233231566==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [IPv6:2610:10:20:722:a800:ff:fe98:4b55]) by gabe.freedesktop.org (Postfix) with ESMTP id CD8956EAD3 for ; Fri, 30 Sep 2016 22:58:21 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0233231566== Content-Type: multipart/alternative; boundary="14752763010.fD09e4b.30667"; charset="UTF-8" --14752763010.fD09e4b.30667 Date: Fri, 30 Sep 2016 22:58:21 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D97988 --- Comment #8 from Grigori Goronzy --- Here's a bit of background: Earlier, mpv used interop with OutputSurfaces. That is, it rendered the vid= eo into an RGB surface and then used that for its own procesing (scaling, rendering OSD on top, etc.). Now recently, mpv has switched to interop with VideoSurfaces. That is, it m= aps four fields of luma/chroma planes. These are split up into top and bottom field, just as the spec for the interop extension says: https://www.opengl.org/registry/specs/NV/vdpau_interop.txt mpv then weaves the fields and does color space conversion, scaling, etc. Things get wrong with the weaving, and I found some very suspicious code in Mesa: https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_vdpau= .c#n82 Here a sampler is returned based on texture name index, and the same plane sampler is used for top and bottom field. That can't be right at all. Is the sampler possibly mangled somewhere else to make it point to the right field= s? It does not look like it, but maybe I'm just missing something. This really makes me wonder whether VideoSurface interop ever worked correc= tly. --=20 You are receiving this mail because: You are the assignee for the bug.= --14752763010.fD09e4b.30667 Date: Fri, 30 Sep 2016 22:58:21 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Comment= # 8 on bug 97988<= /a> from Grigori Goronzy
Here's a bit of background:

Earlier, mpv used interop with OutputSurfaces. That is, it rendered the vid=
eo
into an RGB surface and then used that for its own procesing (scaling,
rendering OSD on top, etc.).

Now recently, mpv has switched to interop with VideoSurfaces. That is, it m=
aps
four fields of luma/chroma planes. These are split up into top and bottom
field, just as the spec for the interop extension says:

http=
s://www.opengl.org/registry/specs/NV/vdpau_interop.txt

mpv then weaves the fields and does color space conversion, scaling, etc.


Things get wrong with the weaving, and I found some very suspicious code in
Mesa:

https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/sta=
te_tracker/st_vdpau.c#n82

Here a sampler is returned based on texture name index, and the same plane
sampler is used for top and bottom field. That can't be right at all. Is the
sampler possibly mangled somewhere else to make it point to the right field=
s?
It does not look like it, but maybe I'm just missing something.

This really makes me wonder whether VideoSurface interop ever worked correc=
tly.


You are receiving this mail because:
  • You are the assignee for the bug.
= --14752763010.fD09e4b.30667-- --===============0233231566== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0233231566==--