Re: [PATCH 0/3] Enable JPEG Encoder on RK3566/RK3568

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Nicolas,
Hi Andrzej,

On Mon, May 02, 2022 at 08:20:50AM -0400, Nicolas Dufresne wrote:
Le samedi 30 avril 2022 à 01:20 +0200, Michael Grzeschik a écrit :
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.

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 Andrzej
in CC, as he started some base work using VP8 encoder on RK3399 (same HW found
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 work-
flow. The first step was obviously to have working prototype, Bootlin started
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.

I just have tested the bootlin v4l2-h264-encoder stack on the rk3399
with v5.19-rc2. It is working as expected.

Since there have been some rumours about using the VEPU121 core on the
rk3568, which could have h264 support as well. I have tested this
stack on that core as well.

The findings are; It is producing some data, but the stream created
is not possible to be decoded. Tested with vlc and gstreamer.

Be it due to misconfiguration or the core is really not h264 capable.

Find the latest code here:

https://git.pengutronix.de/cgit/mgr/linux/log/?h=v5.19/topic/rk3568-vepu-h264-stateless-bootlin

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 stopped.

I have seen that the userspace tool is filling in some initial values
in the PPS and SPS headers, which are not adjustable. I bet you refer to that.

And I personally believe some OSS userland (not just tests) that can handle
multiple reference, perhaps more advance GOP pattern and some basic rate control
would help build confidence in the uAPI.

I found the following CTRL Types being defined in the bootlin stack
for the request API.

V4L2_CID_STATELESS_H264_ENCODE_PARAMS
V4L2_CID_STATELESS_H264_ENCODE_RC
V4L2_CID_STATELESS_H264_ENCODE_FEEDBACK

The FEEDBACK CID is the information we gain after one frame was
encoded. With this data the RC (Rate Control) parameter is prepared for
the next frame.

You mean to have some user interface to make the rate control user
configurable?

Let us know how we can help, we should >void doing the same thing, as
this is already quite a large project that can easily take over a year
to become mainline ready.

It would probably help to share some codebase. If you already have
something for that rkvenc codec, be it VP8 support. It would probably
make sense for me to build up on that. Or to discuss common code
patterns on structures.

Michael

--
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Driver Development]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux