Hi Tomasz, On Thu, May 24, 2018 at 08:46:35PM +0900, Tomasz Figa wrote: > On Thu, May 24, 2018 at 7:34 PM Baruch Siach <baruch at tkos.co.il> wrote: > > I'm trying to get the RK3288 VPU do h.264 encoding on the Tinkerboard > > platform with latest mainline kernel. I found the v4l2 based rockchip-vpu > > driver in the vendor kernel. But I could not get it work even in the > > context of that kernel. Is this driver in usable state? If not, how far it > > is from being usable? > > The driver in chromeos-3.14 kernel [1] is running in production on RK3288 > systems, while the one in chromeos-4.4 [2] on RK3399 systems. > > [1] > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/drivers/media/platform/rk3288-vpu/ > [2] > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/media/platform/rockchip-vpu/ > > However, it doesn't implement a regular stateful V4L2 encoder API, since > the hardware is stateless and does only part of the encoding. For other > things, like bitstream generation and bitrate control, we have libv4l-based > plugins for rk3288 [3] and rk3399 [4]. > > [3] > https://chromium.googlesource.com/chromiumos/third_party/libv4lplugins/+/master/libv4l-rockchip/ > [4] > https://chromium.googlesource.com/chromiumos/third_party/libv4lplugins/+/master/libv4l-rockchip_v2/ This is interesting, thanks. It looks like only v2 supports h.264 encoding. Does the v2 plugin work with the rk3288? A recent discussion on the linux-media list indicated that gstreamer and libv4l2 are not a good match. Which application would you recommend for doing h.264 encoding? > Do you have any details on what was going wrong when you tried to "get it > work even in the context of that kernel"? I used the code from the 'develop' branch of the TinkerOS kernel source tree[1]. I had to build the latest gstreamer version 1.14.0 to get the v4l2h264enc plugin. On startup I got a lot of "must be set encoding output size" error messages from try_fmt. Shortly after that I got a NULL dereference BUG message. But since you say that the driver does not implement the regular API, I can't expect gstreamer native V4L2 code to work, right? [1] https://github.com/TinkerBoard/debian_kernel > > Another option is to forward port the rockchip-vcodec shim driver for the > > MPP > > framework. I'm aware of Myy Miouyouyou's work[1] in this area. But this > > driver > > seems unusable as well. Testing v4.17-rc6, the PM code fails to enable the > > video power domain (the hvec power domain enables correctly, though). The > > error is: > > > rockchip-pm-domain ff730000.power-management:power-controller: failed > to get ack on domain 'pd_video', val=0x8021c > > Hmm, this looks like some problem with power domains. I don't think this is > related to the codec driver itself. Could be something wrong with power > domain driver or some data in device tree, such as power domain clocks. > > > > With the TinkerOS provided kernel I managed to make the VPU encode to > h.264 > > using the gstreamer MPP plugin. But I would rather not use that kernel if > > possible, since that would mean backporting other v4l2 code that I need. > > > Do you have any other idea/direction for me to explore? > > I think you should be able to get our driver to work, but ideally we should > create a proper stateless encoder API, based on V4L2 Request API, similar > to what's being proposed for decoders. Thanks for your detailed and helpful response. baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
