Hello all media staff
Dear Mr.Verkuil
Dear Mr.Osciak
I talked with Nicolas and Mr.ceyusa in the yesterday and early morning of today. I think I have made them get the situation of state-less Video Acceleration Unit(VPU) and Rockchip for VA-API driver. We both agree that creating a new C API bindings to V4L2 is making wheel again. Mr.Ceyusa suggest that there could be a middle library to parse those codec settings to V4L2 extra controls array, and push back to Gstreamer, leaving the V4L2 related job to Gstreamer. I agree with him. I think the Gstreamer then could get rid of hardware detail, even not need to know internal data structure in kernel driver of codec parameters. Later, the ad-n770 joined us. He gave me some idea about the relationship with VA-API and DXVA2. I found we do need some extra data beyond those data used by VA-API to reconstruct a frame, it is a limitation in HW. We better regard this kind of HW to a Acceleration Unit rather than Full decoder/Encoder. Also ad-n770 pointer out that it seems that Rockchip HW could do the reodering job, which is not need actually as it is done by Gstreamer, but I am not sure whether the Hardware does and I could disable this logic. I am sorry I can't attend the conference in Berlin. But I hope we could keep in discussion in this topic, and offering more information to you before the meetings. Currently, I would still work on VA-API framework and I am learning something about codec through a book, I hope that it make me explaining the situation easily.

Randy Li
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]

Libva mailing list

Reply via email to