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==--