Re: Stateless Encoding uAPI Discussion and Proposal

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

 





On 7/27/23 03:53, Nicolas Dufresne wrote:
CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.


Hi,

Le mercredi 26 juillet 2023 à 10:49 +0800, Hsia-Jun Li a écrit :
I am strongly against this approach, instead I think we need to keep all
vendor-specific parts in the kernel driver and provide a clean unified userspace
API.

We are driving away vendor participation. Besides, the current design is
a performance bottleneck.

I know you have been hammering this argument for many many years. But in
concrete situation, we have conducted tests, and we out perform vendors stacks
that directly hit into hardware register with stateless CODEC. Also, Paul's
proposal, is that fine grain / highly close to metal tuning of the encoding
process should endup in the Linux kernel, so that it can benefit from the
natural hard real-time advantage of a hard IRQ. Just like anything else, we will
In a real case, especially in those EDR/DVR, NVR, re-encoding could happen occasionally. The important is feedback the encoded statistic to the controller(userspace) then userspace decided the future operation(whether re-encoding this or not).

find a lot of common methods and shareable code which will benefit in security
The security for a vendor would only mean the protection of its intelligence properties. Also userspace and HAL is isolated in Android. Security or quality are not a problem here, you can't even run the unverified code.
Or we just define an interface that only FOSS would use.
and quality, which is very unlike what we normally get from per vendor BSP. The
strategy is the same as everything else in Linux, vendor will adpot it if there
is a clear benefit. And better quality, ease of use, good collection of mature
Any vendor would like to implement a DRM(digital right, security) video pipeline would not even think of this. They are not many vendors that just sell plain video codecs hardware.

In such case, we can't even invoke in its memory management, they may even drop the V4L2 framework.

Somebody may say why the vendor want the stateless codec, they could have a dedicated core to run a firmware. It is simple, if you are comparing an ARM cortex-R/M core to an ARM application core, which one could performance better? A remote processor could make the memory model(cache coherent) more complex. Besides, it is about the cost.
userspace software is what makes the difference. It does takes time of course.

Anyway, despite those registers and controls part, I think I could input the buffer management part here.

Please DO ***NOT*** make a standard that occupied many memory behinds usersace and a standard that user has to handle the reconstruction buffer holding with a strange mechanism(I mean reconstruction buffer lifetime would be manged by userspace manually).

regards,
Nicolas

--
Hsia-Jun(Randy) Li



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux