Hi,
I would like to jpeg encode packed YUV 4:2:2 raw images with an Apalis iMX6Q.
I have tried to use the libimxvpuapi but it seems to work only with planar 4:2:2
images. Are there others libraries that I can use?
I would like to encode at a rate of 160Mpx/s , is it realistic?
Best regards,
Alexis
Solved! Go to Solution.
The Chapter 69 of the i.MX6Q RM says that MJPEG can be encoded at up to 8192x8192 size.
Artur
Actually, VPU can process only planar image data on its input due to its hardware nature. A raw data should be re-formatted to planar before being processed by VPU.
Yes, it is realistic to encode images at 160Mpix/s.
Have a great day,
Artur
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
First, thankes for your reply Artur!
But can I encode images of size 3360x2496? cause in the vpu documentation (http://hands.com/~lkcl/eoma/iMX6/VPU_API_RM_L3.0.35_1.1.0.pdf ) it is written about 1920x1088 images.
The Chapter 69 of the i.MX6Q RM says that MJPEG can be encoded at up to 8192x8192 size.
Artur
Ok,
I find the reference manual but when I try to compress an image of 8Mpx, it takes 200ms using the libimxvpuapi!
How do I need to do to reach the 160Mpx/s?
Alexis
Do you use the L3.0.35 Linux BSP by FSL/NXP? If so, please note that this BSP is quite early and not well-optimized. The better way is to migrate to most up-to-date BSP release. Current release is L3.14.52.
Also, take into the account other possible overhead, possibly related with image re-formatting, reading/storing etc.
Artur
I'm currently using the Linux-3.14.28-V2 linux BSP and i have written a short program just for encode one image.
Alexis
Seems that you use the outdated VPU API Reference document. Please use the attached one. Also, still take into the account the software overhead, related with image reading/storing, it can be significant.
Best Regards,
Artur
Thanks for all!
Best Regards,
Alexis