Hello all media staff
I talked with Nicolas and Mr.ceyusa in the yesterday and early morning
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.
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