Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <0414bb0816eef95961fe47de96f97f925d29228f.camel@ndufresne.ca>
Subject: Re: [PATCH 0/3] Enable JPEG Encoder on RK3566/RK3568
From:   Nicolas Dufresne <nicolas@ndufresne.ca>
To:     Michael Grzeschik <mgr@pengutronix.de>,
        Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Cc:     Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Heiko Stuebner <heiko@sntech.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Peter Geis <pgwipeout@gmail.com>,
        Michael Riesch <michael.riesch@wolfvision.net>,
        Liang Chen <cl@rock-chips.com>, linux-media@vger.kernel.org,
        linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-staging@lists.linux.dev,
        Kever Yang <kever.yang@rock-chips.com>,
        Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Date:   Mon, 02 May 2022 08:20:50 -0400
In-Reply-To: <20220429232047.GG7671@pengutronix.de>
References: <20220427224438.335327-1-frattaroli.nicolas@gmail.com>
         <198ce3981ad15844627581f9519cab67ed2a81c1.camel@ndufresne.ca>
         <2438841.KJ31GcehEG@archbook> <20220429232047.GG7671@pengutronix.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.0 (3.44.0-1.fc36) 
MIME-Version: 1.0
Precedence: bulk

Hi Michael,

Le samedi 30 avril 2022 =C3=A0 01:20 +0200, Michael Grzeschik a =C3=A9crit=
=C2=A0:
> Since the RK3568 seems to get more and more of attention at the moment
> I would like to ask if somebody is planning to write support the RKVENC
> in mainline. That is the VEPU540 core refered to in the RK3568 TRM.
>=20
> I would start with that in the next weeks, taking the bootlin H1 support
> as an reference to handle the request_api for the encoder part. Which is
> currently completely untouched in mainline AFAIK.

I'm very happy to ear you'd be interest in helping with this. I'm adding An=
drzej
in CC, as he started some base work using VP8 encoder on RK3399 (same HW fo=
und
on other RK SoC) to make this possible. Note that these are a new type of
encoders and a specification is needed to ensure they all have a coherent w=
ork-
flow. The first step was obviously to have working prototype, Bootlin start=
ed
with H264 (but never posted anything on the mailing list). I'm under the
impression they have abandoned it. Andrzej have decided to use VP8 as it is
simpler. The prototype should help understand the basic flow of an encoder =
and
produce a specification for this.

From there, the "easy" part is to make per codec controls, to configure the
encoder. Demonstrating fixed QP, this is about were I believe Bootlin stopp=
ed.
And I personally believe some OSS userland (not just tests) that can handle
multiple reference, perhaps more advance GOP pattern and some basic rate co=
ntrol
would help build confidence in the uAPI. Let us know how we can help, we sh=
ould
avoid doing the same thing, as this is already quite a large project that c=
an
easily take over a year to become mainline ready.

regards,
Nicolas

>=20
> Regards,
> Michael
>=20