About a potential version 3 of libimxvpuapi

[dv1]

I wish to bring up a problem with the current libimxvpuapi interface. Version 1 of libimxvpuapi was written purely for the imx6 CODA VPU. Version 2 introduced support for the Hantro VPU on imx8mm machines.

However, the V2 API has shortcomings:

• When decoding, pushing encoded frames into the VPU and pulling decoded frames out of the VPU are interlocked. You cannot get the next decoded frame without pushing another encoded frame to decode. When decoding live streams, this can pose a problem, because it can raise minimum latency. Same applies to encoding, just in reverse.
• The API is unnecessarily complex for setting the pixel format that shall be used for decoding. It should be sufficient to just set a pixel format and that's it. Instead, the API uses various kind of hints.
• Encoding is only possible in a zerolatency mode. This means that one raw frame is fed into the VPU, and the encoded frame comes out. With encoders that only produce h264 baseline data, or VP8 data, that's sufficient. However, if an encoder can do other h264 profiles (like the VC8000E), then we have a problem, because with such profiles, feeding one raw frame into the VPU might not immediately produce an encoded frame. Instead, frames may be queued. And, the encoded frames may not be in order. The current encoder API does not support this.
• The Hantro G1 and G2 decoders and H1 encoder are operated through the imx-vpu-hantro package's OpenMAX IL layer. When libimxvpuapi2 was written, there was next to no information about imx-vpu-hantro, and what little example code existed used that OMX layer. These days though, it seems that it would have been better to skip that layer and instead use the Hantro specific APIs directly. In particular, the H1 encoder could be controlled better that way. H1 currently exhibits weird bitrate spikes (as reported here), and I found no way to finetune its behavior through that emulated OMX layer.
• The Amphion Malone decoder found on imx8qm and imx8qxp machines has to be operated through V4L2. However, the driver included in NXP kernels is not fully V4L2 standard compliant, so supporting this in libimxvpuapi may still be useful. But this is complicated by the fact that that driver has a "timestamp manager" which reorders frames based on the timestamp values that are set in v4l2_buffer instances. This "timestamp manager" cannot be turned off. The only options are to either feed valid PTS (not DTS!), or turn off h264 and h265 frame reordering and then let libimxvpuapi do that reordering on its own.
• Support for tiled formats is currently quite lacking. This is particularly true of Hantro G2.
• The API uses both physical addresses and file descriptors (for DMA-BUF). These days, it may be better to just always use the latter, and rely on DMA buffer allocators in the kernel that allocate DMA-BUF. All imx kernels have these, but they need to be enabled for imx6 machines, because NXP refuses to fix their kernel configs there.

This is why I am considering a version 3 of libimxvpuapi, redesigned from the ground up to address these issues.

On one hand, this would be a great opportunity to completely clean up the API and fit these missing features and solve these problems in a clean way. The API would also be simpler, and it would also affect gstreamer-imx positively, simplifying its VPU plugin code. On the other hand, we already have a version 1 and 2 ... is adding another version a good idea? Also, of course, a version 3 would take months to complete.

I'd like input and opinions from others about this. In particular, @dougnazar , @sdroege , @otavio , @DanielePettenuzzo , @ndufresne , I'd like your input, since you are especially experienced with these topics.

I also realize that there has been continuing work on upstreaming Hantro etc. support to the mainline kernel, but it still seems to take some time to be feature complete, and there are still a lot of setups that use imx kernels, so I think a V3 is still relevant, but perhaps you have a different opinion..?

[ndufresne]

I think if abstracting the various API is something wanted at the low level, this rewrite is unavoidable. The new API should allow different threads for input and output, and should be asynchronous enough that we can ensure userspace can parse prepare and submit frame while the HW is busy. As for the memory model, if dmabuf is fine, good, but otherwise a full abstraction (with dmabuf / physical offset extension) might work better.

What I'm observing upstream is that NXP is only active around the imx8q (Amphion based) series. Leaving a huge upstream gap for all the imx8m (including the plus). That basically creates a fracture in the echosystem, so I live in doubt mainline will ever fully replace the bsp. On older platforms, it seems like mainline have matched or surpassed the bsp now, and most users are moving away from the bsp. For this reason I'd ask if imx5/6 bsp support is still relevant for a newer API?