From: Philipp Zabel <p.zabel@pengutronix.de>
To: Jonas Karlman <jonas@kwiboo.se>,
Ezequiel Garcia <ezequiel@collabora.com>
Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Hans Verkuil <hverkuil@xs4all.nl>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
Boris Brezillon <boris.brezillon@collabora.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH 02/12] media: hantro: Do not reorder H264 scaling list
Date: Tue, 03 Sep 2019 14:53:04 +0200 [thread overview]
Message-ID: <1567515184.5229.5.camel@pengutronix.de> (raw)
In-Reply-To: <DB6PR06MB4007C140420365E83064C5BEACB90@DB6PR06MB4007.eurprd06.prod.outlook.com>
On Tue, 2019-09-03 at 07:54 +0000, Jonas Karlman wrote:
[...]
> After a closer look both ffmpeg and rkmpp only apply zig-zag scan and not field scan,
> ffmpeg will memcpy the scaling_matrix4/8 as is for vaapi, vdpau and nvdec,
> for dxva2 there is a workaround flag that controls if zig-zag should be applied or not.
>
> I suggest a clarification of the expect order of values and use of the same value order as vaapi, vdpau and nvdec.
> i.e. have the scaling list values in "matrix order"/"raster order", after zig-zag scan has been applied,
> as is currently expected by cedrus and hantro after this patch.
>
> I would also suggest a change to the expected order of the 8x8 scaling lists to follow the H264 standard,
> instead of the ffmpeg order like this patch and cedrus driver currently expects.
>
> Expected scaling list order would then be,
> for 4x4: Intra Y, Intra Cb, Intra Cr, Inter Y, Inter Cb, Inter Cr,
> for 8x8: Intra Y, Inter Y, Intra Cb, Inter Cb, Intra Cr, Inter Cr.
I'm in favor of both, it seems unnecessary to reorder the lists in
userspace only to have the kernel reorder them back before passing them
to the hardware.
regards
Philipp
next prev parent reply other threads:[~2019-09-03 12:53 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-01 12:42 [PATCH RFC 00/12] media: hantro: H264 fixes and improvements Jonas Karlman
2019-09-01 12:45 ` [PATCH 01/12] media: hantro: Fix H264 max frmsize supported on RK3288 Jonas Karlman
2019-09-04 13:07 ` Ezequiel Garcia
2019-09-09 19:25 ` Jonas Karlman
[not found] ` <20190901124531.23645-1-jonas@kwiboo.se>
2019-09-01 12:45 ` [PATCH 02/12] media: hantro: Do not reorder H264 scaling list Jonas Karlman
2019-09-02 14:00 ` Philipp Zabel
2019-09-02 16:18 ` Jonas Karlman
2019-09-03 7:54 ` Jonas Karlman
2019-09-03 12:53 ` Philipp Zabel [this message]
2019-09-03 9:56 ` Philipp Zabel
2019-09-10 10:14 ` Ezequiel Garcia
2019-09-01 12:45 ` [PATCH 03/12] media: hantro: Fix H264 motion vector buffer offset Jonas Karlman
2019-09-03 10:58 ` Philipp Zabel
2019-09-03 20:13 ` Jonas Karlman
2019-09-10 10:18 ` Ezequiel Garcia
2019-09-10 11:34 ` Ezequiel Garcia
2019-09-01 12:45 ` [PATCH 05/12] media: hantro: Remove now unused H264 pic_size Jonas Karlman
2019-09-01 12:45 ` [PATCH 04/12] media: hantro: Reduce H264 extra space for motion vectors Jonas Karlman
2019-09-01 12:45 ` [PATCH 06/12] media: hantro: Set H264 FIELDPIC_FLAG_E flag correctly Jonas Karlman
2019-09-01 12:45 ` [RFC 08/12] media: hantro: Fix H264 decoding of field encoded content Jonas Karlman
2019-09-03 13:21 ` Philipp Zabel
2019-09-03 14:02 ` Jonas Karlman
2019-09-03 15:01 ` Philipp Zabel
2019-09-03 19:47 ` Jonas Karlman
2019-09-01 12:45 ` [RFC 07/12] media: uapi: h264: Add DPB entry field reference flags Jonas Karlman
2020-07-10 4:21 ` Ezequiel Garcia
2020-07-10 8:13 ` Boris Brezillon
2020-07-10 8:48 ` Jonas Karlman
2020-07-10 12:18 ` Ezequiel Garcia
2020-07-10 11:50 ` Ezequiel Garcia
2020-07-10 12:05 ` Boris Brezillon
2020-07-10 12:25 ` Ezequiel Garcia
2020-07-10 21:49 ` Nicolas Dufresne
2020-07-11 10:21 ` Jonas Karlman
2020-07-11 18:36 ` Nicolas Dufresne
2020-07-12 22:59 ` Ezequiel Garcia
2020-07-14 16:04 ` Nicolas Dufresne
2019-09-01 12:45 ` [RFC 09/12] media: hantro: Refactor G1 H264 code Jonas Karlman
2019-09-01 12:45 ` [RFC 10/12] media: hantro: Add support for H264 decoding on RK3399 Jonas Karlman
2019-09-02 11:46 ` Hans Verkuil
2019-09-02 15:25 ` Jonas Karlman
2019-09-01 12:45 ` [RFC 11/12] media: hantro: Enable " Jonas Karlman
2019-09-01 12:45 ` [RFC 12/12] media: hantro: Enable H264 decoding on RK3328 Jonas Karlman
2019-09-02 13:02 ` [PATCH RFC 00/12] media: hantro: H264 fixes and improvements Ezequiel Garcia
2019-09-02 16:28 ` Jonas Karlman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1567515184.5229.5.camel@pengutronix.de \
--to=p.zabel@pengutronix.de \
--cc=boris.brezillon@collabora.com \
--cc=ezequiel@collabora.com \
--cc=hverkuil@xs4all.nl \
--cc=jonas@kwiboo.se \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mchehab@kernel.org \
--cc=paul.kocialkowski@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).