Myy

Well, ok, it obviously couldn't work since I used the wrong kernel tree... I'll retry my tests and fix my script this week-end...

Ah, it seems that on the special kernel, there's no MPEG decoder VPU appearing. Only the JPEG encoder is enabled... I guess I forgot something in the configuration...

So... I tested it with the old patched version of FFMPEG but it didn't work (´・ω・`　) When I mean "it didn't work", mpv played the video but when I checked the logs quickly after, I found that it tried to use the V4L2 output, and then failed and then switched back to the software decoder, which IS fast enough to decode and display MPEG2 at ~30 FPS. Now, I'm compiling the new FFMPEG but it takes a while... !! HOWEVER !! I made a special compilation script that fetches Kwiboo's kernel and compile it automatically, with the old Mali drivers though (I should try with your r28p0). As always, the script is autonomous, so you can just grab the script, run it and have a freshly patched and compiled kernel, ready to install in your system. Then you can always edit it and play with it. https://raw.githubusercontent.com/Miouyouyou/RockMyy/VPU-V4L2-5.x/GetPatchAndCompileKernel.sh I should follow with a few scripts to compile the patched FFMPEG and MPV, so that everyone can test the whole thing. Now, maybe I'm just missing something, and maybe someone else can test the whole thing and be like "You're fucking dumb ! You forgot to activate this here ! And now everything works !". Anyway, have a try everyone ( `・ω・́)

Are the FFMPEG patches you sent to their ML, the ones present here : https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel ? Also, do you have a working MPEG-2 sample, so that I can be sure that I'm testing with the right format.

If you connect your board (only) to a PC through an USB cable, do you see an USB connection ? (lsusb or Windows Device manager)

Also, about the Mali driver for Mali-T7xx and Mali-T8xx, I had some information from one of the panfrost driver developer who told me that the Panfrost will hit the kernel very soon. https://gitlab.freedesktop.org/Miouyouyou/RockMyy/issues/14 It will act as a full kernel driver, meaning that no additional patches should be required. I should post this in the GPU thread but... I also need to test this before hand.

( `・ω・́)b Nice ! I'll try this tomorrow. Sorry about the delay with the V4L2 tests, I'm dealing with a very busy week (and another one too).

Since the Ethernet driver is sending warnings, have you tried to launch Chromium on some static HTML files, without the Ethernet cable plugged in ?

Glad you got back from MASKROM mode. The image I used at the time was from RKTool_Linux.tar.gz -> Linux_Pack_Firmware/Linux-rockdev_2015-06-17_for_RK3399.zip -> rockdev/ This comes from OrangePi MEGA folder : https://mega.nz/#F!K1BQFQjL!W9rYedaoGpV4y8vHfrGEfQ!ekYA0AwR Why did they hide the image into a sub-sub-archive on a random MEGA folder ? I don't know.

VIDIOC_QUERYBUF hits v4l_querybuf, which calls the driver vidioc_querybuf function pointer, which actually points to the global v4l2 helper : v4l2_m2m_ioctl_querybuf . This helpers calls v4l2_m2m_querybuf which sets its return value with the return value of vb2_querybuf. At that point, I thought that either the type, or the index of the queried buffer was invalid. Turns out that it wasn't the case. EINVAL (-22) is set by __verify_planes_array, which checks if the queried buffer "length" field is at least equal to the queued buffer "num_planes" field (and if the index isn't absurd). The check fails, __verify_planes_array returns -22 and the returned value bobble up to the ioctl handler, which sends the errno value to the v4l2-request-test software. Now I need to understand why the tester sets the buffer "length" to some value (3) when queuing it, and then use another value (1) when querying it. Trying to modify the software by all the buffers length to 3 just led to some a SIGSEGV... However, the VIDIOC_QUERYBUF returned 0 (SUCCESS) before the SIGSEGV. So there's that... So yeah, tomorrow will be : debugging the tester... and learning a little more about how it works.

So, in order : The kernel used for V4L2 patches seems to be the one implementing the Allwinner SoC VPU : https://github.com/bootlin/linux-cedrus/tree/cedrus/5.0/next It's the one providing all the H264/HEVC definitions at least. At least, I know where to be base myself on. Also, it seems that the tester I used was sending the VIDIOC_TRY_FMT ioctl query, with the following format type : V4L2_BUF_TYPE_VIDEO_CAPTURE The VIDIOC_TRY_FMT ioctl is handled by v4l_try_fmt , and v4l_try_fmt call the v4l2_ioctl_ops->vidioc_try_fmt_vid_cap setup by the driver. Turns out that the Rockchip VPU driver doesn't implement this function pointer. It implements vidioc_try_fmt_vid_cap_mplane instead, which is only called if the type is V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE . By default, on the tester I used, V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE was not used. However, turns out that Ezequiel already provided a version testing for Multiplanar first : https://github.com/ezequielgarcia/v4l2-request-test/commit/9135eab85e9a1acc6e575fa5225b81e66f70e0d0 Which is available in its "non-sunxi" branch. Now, when using the "Network" function of Github, I see that Randy Li also provided some improvements to test his own driver : https://github.com/ezequielgarcia/v4l2-request-test/network That said, with the new tester I get stuck at the VIDIOC_QUERYBUF request failing now...

Okay, I'm trying (again) this week-end. So the Randy-Li patch not including VPU Decoder v1 for RK3288 chips, I've giving up on it at the moment. I'm retrying the Ezequiel patch, with Kwiboo additions, now trying to understand how the V4L2 request thing work, and why when using the v4l2-request-test tester, the driver sends back a "Invalid request" response...

Your first best bet would be to try using weston. If weston doesn't work, you'll to need to fix this first. Also know that, a lot of Wayland compositors have their own way to work with the DRM/OpenGL ES stack and... it tends to play badly with embedded systems due to some "weird" mechanisms for initializing the graphic stack. So if a wayland compositor (beside weston which tends to have some 'state of art' way of initializing the graphic stack) doesn't work, it doesn't mean that others won't.

I need to understand what V4L2 changes are made between the branch used in the "Rockchip-linux" talk (it seems to be mmind one, but I'm not entirely sure). Then, I could try Ayaka and Kwiboo patches again.

Interesting ! That way you only have to get into Maskrom flash one image to get the DDR setup correctly and boot the new compiled U-Boot Without having to resort to some weird rkdeveloptool incantations ? I'm all for this too !

Before I try to look for solutions concerning a problem that might not exist, is this video in the right format ? [mpegvideo @ 0x13d62a0] Estimating duration from bitrate, this may be inaccurate Input #0, mpegvideo, from '/tmp/grb_2.mpg': Duration: 00:00:27.86, bitrate: 5999 kb/s Stream #0:0: Video: mpeg2video (Main), yuv420p(tv, bt470bg, bottom first), 720x480 [SAR 8:9 DAR 4:3], 6000 kb/s, 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc At least one output file must be specified I mean, I understand that there's NV12 (YV12) and NV21, and I'm not sure in which format this video is.

Interesting tools. I got these logs, which seems to indicate that I forgot something in my kernel, since MP2G is not available. I got a MG2S format with mpeg_2_slice_parameters, however it seems that FFMPEG used /dev/video2 instead of /dev/video1 anyway. Here are the logs excerpt : /dev/video0 (RGA) /dev/video1 /dev/video2 MPV/FFMPEG And then the video plays in a fluid manner if I use the Mali binary blob for OpenGL output.

I'll recheck the headers to be sure, but I'm pretty confident I copied them correctly. I even had issues with the bootlin testers, since they redefine them in two headers in their repository, so I had to put two blanks files instead of their headers to compile the whole thing.

If you need Video Decoding support, you'll have to wait until the whole thing is ported and stable. If you need GPU support, then you can just grab the mali drivers from Rockchip and use them with recent kernels. The Debian package for the rockchip drivers is here : https://github.com/rockchip-linux/rk-rootfs-build/blob/master/packages/armhf/libmali/libmali-rk-midgard-t76x-r14p0-r0p0_1.6-1_armhf.deb Or, you could do something like this, if you don't want play too much with random Debian packages : mkdir -p ~/.local/lib cd ~/.local/lib wget https://github.com/rockchip-linux/libmali/raw/29mirror/lib/arm-linux-gnueabihf/libmali-midgard-t76x-r14p0-r0p0-wayland.so -O libmali.so for file_to_link in libGLESv1_CM.so{,.1,.1.0.0} libGLESv2.so{,.2,.2.0.0} libEGL.so{,.1,.1.0.0} libgbm.so{,.1,.1.0.0} libOpenCL.so{,.1,.1.0.0} libwayland-egl.so{,.1,.1.0.0}; do ln -s libmali.so "$PWD/$file_to_link"; done echo "alias mali_launch=LD_LIBRARY_PATH=\$LD_LIBRARY_PATH:`echo ~/.local/lib`" >> ~/.bashrc

Compiled MPV (with the habitual troubles, have to patch it for EGL, have to modify the build script to add udev to the list of libraries needed to link MPV) AND... it doesn't work. v4l2_request_probe_video_device: try output format failed... So... I'll have to debug the IOCTL to understand what's going on, why that doesn't work, are all the patches applied correctly, etc... Ugh... At least, I have the required softwares to test the whole thing. Still, the bootlin tester failing might just be a big "RED FLAG" after all. That said, I have to say that with the Mali binary OpenGL drivers, the picture is fluid on the screen...

Yeah... well.. went without it, with just a passive cooler while powered through a USB charger. #SoRebel #MuchRockchip

I have to add that I LOVE the fact that, by default, FFMPEG doesn't compile shared libraries. It's so fun to compile it TWICE, because you forgot this little "feature". Anyway, I was able to compile this patched FFMPEG, even though I had to resort to a few hacks to get the binaries compiled, since -ludev wasn't added automatically at compile time, and the linker complained about missing udev_ symbols references. Note that $LDFLAGS didn't do the trick, because for "some reason" only "-lLIBNAME" put at the end of the gcc command line were working... So, yeah, it basically went like this : make V=1 > command # edit "command", add the "-ludev" at the end, save, close the file source command make A "better" way would be to edit the Makefile appropriately but I'm lazy and finding the right place to do it, in a very big Makefile, from an actual terminal... No... So, tomorrow, I'll try MPV and see if I can get something decoded.

Alright, the module not loading was due to one my patch modifying the DTSI in order to adapt to Ayaka driver, which used names like "VEPU" and "VDPU". So I basically copied back the nodes as they're defined in the rk3288.dtsi of your kernel tree. So the module loads, media-test is able to list all the rockchip-vpu outputs (sink, ...). However this one, https://github.com/bootlin/v4l2-request-test , throws Invalid argument when trying to execute a VIDIOC_TRY_FMT . Given how IOCTL work, trying to recompile FFMPEG appears to be a "quicker" solution than debugging the tester from bootlin. Is there a "quick" tester that just tries to decode ONE frame of a specific format, that is up to date and works with the currently implemented V4L2 Request extension ?

Alright, I've tested the inclusion of @Kwiboo patches into my compilation script (`・ω・́) However I missed a few patches here and there since they didn't apply to my patched branch... And I'm pretty sure I missed the ones on the rk3288.dtsi and rk3288-tinker.dts loading the driver correctly. I'll try to get this patch done tomorrow and test this with https://github.com/bootlin/v4l2-request-test first. I understand that you have a patched FFMPEG https://github.com/Kwiboo/FFmpeg/compare/4.0.3-Leia-Beta5...v4l2-request-hwaccel and MPV https://github.com/mpv-player/mpv/pull/6461 ready but... I'll have to remember how to cross-compile these projects, since I don't want to recompile them on the Tinky again (took 2H last time (´・ω・`))

So, this Sunday, I took a look at the patches list, thinking I'll just have to get them and apply them to the mainline kernel and test them... Then I realized that, they're applied against the Rockchip tree... So I'll have to redo the whole patchset manually... This will take a few days, since I'll have to : - Take my patched Linux tree - Copy the whole VPU code from the Rockchip tree to mine - Generate the first patch - Copy every modified subsystem (V4L2, VOP, Videobuf2, Clocks, ...) - Generate a patch for each of these subsystems - Test the compilation - Apply additional modifications if necessary - Test the compiled kernel - Assemble the patches list - Put in the script - Test the script again And release... The last steps (Test the compilation, ...) are mundane. What takes time is the first steps. So, yeah, I'm on it. I just underestimated the integration time.