From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 105145] vaExportSurfaceHandle interaction with surface interlaced flag prevents switching on vaapi deinterlacing dynamically Date: Wed, 13 Jun 2018 11:15:57 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0717306468==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 256B26E00B for ; Wed, 13 Jun 2018 11:15:57 +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 --===============0717306468== Content-Type: multipart/alternative; boundary="15288885570.da73.12839" Content-Transfer-Encoding: 7bit --15288885570.da73.12839 Date: Wed, 13 Jun 2018 11:15:57 +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=3D105145 --- Comment #13 from k.philipp@gmail.com --- (In reply to Christian K=C3=B6nig from comment #12) > Unfortunately yes it is. That is indeed very unfortunate. It complicates stuff a lot :-( I'd still like to see a solution that allows to support PAFF without copying around already-decoded frames/fields all the time. Do you have any ideas? C= ould we have the decoder put progressive content into progressive surfaces and interlaced content into interlaced surfaces (under the assumption that we w= ill most likely want to deinterlace)? > That HEVC and VP9 only support progressive layout in the output format is > also only logical because those formats don't support interlaced content. At least HEVC does support interlaced content in theory, but as far as I understood it the (hw) decoder does not need special support for that. How would that work then, would we get top/bottom field as two separate quasi-frames? --=20 You are receiving this mail because: You are the assignee for the bug.= --15288885570.da73.12839 Date: Wed, 13 Jun 2018 11:15:57 +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

Comme= nt # 13 on bug 10514= 5 from k.philipp@gm= ail.com 
(In reply to Christian K=C3=B6nig from comment #12)
> Unfortunately yes it is.
That is indeed very unfortunate. It complicates stuff a lot :-(
I'd still like to see a solution that allows to support PAFF without copying
around already-decoded frames/fields all the time. Do you have any ideas? C=
ould
we have the decoder put progressive content into progressive surfaces and
interlaced content into interlaced surfaces (under the assumption that we w=
ill
most likely want to deinterlace)?

> That HEVC and VP9 only support progressive layou=
t in the output format is
> also only logical because those formats don't support interlaced conte=
nt.
At least HEVC does support interlaced content in theory, but as far as I
understood it the (hw) decoder does not need special support for that. How
would that work then, would we get top/bottom field as two separate
quasi-frames?

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