media: rockchip-vpu: I should place the huffman table at kernel or userspace?
randy.li at rock-chips.com
Tue Sep 27 01:08:09 PDT 2016
On 09/27/2016 03:52 PM, Hans Verkuil wrote:
> On 27/09/16 05:43, Randy Li wrote:
>> I have just done a JPEG HW encoder for the RK3288. I have been told
>> that I can't use the standard way to generate huffman table, the VPU
>> supports only 10 levels with a different huffman table.
>> If I send the huffman table through the v4l2 extra control, the memory
>> copy is requested, although the data is not very large(2 x 64 bytes) but
>> still a overhead. The other way is to place them in the kernel driver,
>> and just define the quality every time it encode a picture. But storing
>> in kernel would make the driver a little bigger(2 x 11 x 64 bytes) and
>> beyond the FIFO job.
>> So where Should I place the huffman table?
> Put it in the driver. It's less than 1.5 kB, so really small.
> I'm not sure what you mean with 'beyond the FIFO job' though.
I always been taught that the kernel driver is just FIFO between
userspace and hardware.
Next time I would learn those small thing(even hard code) could be
stored in kernel source code.
> My understanding is that there 10 quality levels, each with its own
> huffman table?
Right. But I still asking what the relationship is to the standard
quality in JPEG from 0 to 100 to the other staff.
> So the driver would implement the V4L2_CID_JPEG_COMPRESSION_QUALITY control
> and for each quality level it picks a table. Makes sense to me.
Let looks I could omit a extra JPEG control then.
P.S the encoder for VP8 and H.264 is really very hard. I really need
more time to do them. There is a new VA-API driver which removed the
most possible information from the third party library(but still need
it) and using most decoder settings from the VA-API client.
The new kernel driver is in schedule as well.
The third produce department
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
More information about the Linux-rockchip