5 5
Myy

The VPU driver

Recommended Posts

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.

Share this post


Link to post
Share on other sites

@Myy The patches I have in my rockchip-5.x-vpu branch is on top of v5.0-rc6 + mmind/for-next and not a rockchip tree.

 

All vpu related patches needed on top of v5.0-rc6: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x-vpu (patch)

List of mmind/for-next patches rebased on v5.0-rc6: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x (patch)

VPU related patches on top of mmind/for-next: https://github.com/Kwiboo/linux-rockchip/compare/rockchip-5.x...rockchip-5.x-vpu (patch)

 

I have started to send some of my patches to linux mailing list and more will follow.

Share this post


Link to post
Share on other sites

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 (´・ω・`))

 

Share this post


Link to post
Share on other sites

FFmpeg will need the following configure flags: --enable-v4l2-request --enable-libdrm --enable-libudev

For mvp https://github.com/LibreELEC/LibreELEC.tv/pull/3256/files have some flags and commands that worked on LibreELEC buildsystem.

kodi-gbm should also work without modifications as long as the mpeg2_v4l2request hwaccel is enabled, any recent version of kodi pre v18-v18.1.

 

I have only tested this with libmali gbm files at https://github.com/LibreELEC/libmali and mali-utgard/mali-midgard kernel drivers.

https://github.com/Kwiboo/LibreELEC.tv/tree/rockchip-5.x/projects/Rockchip/packages also have the package.pk with build commans I have used to build utgard/midgard drivers out-of-tree, but lima/panfrost should also "work" I have been told.

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
23 hours ago, Myy said:

since I don't want to recompile them on the Tinky again (took 2H last time

DSC_0748.thumb.JPG.2a964d8698976524a76206b980d5e64f.JPG

 

That's the only reasonable way to do something stressful with an RK3288.  I'd add GPIO powering on top of that to be sure, since it not thermal throttling presents challenges for everything else in the system that might not have anticipated pulling 15 Watts for over an hour.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Haha. I still need to do that thermal comparison between factory, my Frankenstein above, and the nice case they sent me. It is far superior to the factory cooler, although it would still throttle in your situation.

Sent from my Pixel using Tapatalk

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites
23 hours ago, Myy said:

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 ?

 

I never tested v4l2-request-test only peeked at the code to try and learn how to call the request api.

The mpeg2/h264/hevc v4l2 ctrls currently lives in private kernel headers causing some troubles for user-space.

My kernel vpu patcheset includes a revert to make the mpeg2 ctrl public and the hwaccel expects this, I plan to bundle the ctrl headers in next update to hwaccel.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
2 hours ago, Myy said:

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.

 

Sounds like it is linking to the static ffmpeg? I added the libudev dependancy to ffmpeg and only tested it on LibreELEC buildsystem where proper pkg-config file exists for libudev and -ludev is added correctly.

 

2 hours ago, Myy said:

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...

 

Do you have full ffmpeg debug log? On my Tinker Board there is one media and three video devices and the v4l2_request probe code will try all media and related video devices until a video device supporting requested format is found.

On Tinker Board the jpeg encoder is probed before the decoder and one output format not found is expected.

Run mpv with --msg-level=ffmpeg=trace to get ffmpeg debug log.

 

Output from v4l2-ctl --device /dev/video0 --all (and the other 2-3 video devices could be helpful to see if the MP2S format is supported).

Edited by Kwiboo

Share this post


Link to post
Share on other sites
(edited)

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)

Spoiler

 


Driver Info (not using libv4l2):
        Driver name   : rockchip-rga
        Card type     : rockchip-rga
        Bus info      : platform:rga
        Driver version: 5.0.0
        Capabilities  : 0x84208000
                Video Memory-to-Memory
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps   : 0x04208000
                Video Memory-to-Memory
                Streaming
                Extended Pix Format
Priority: 2
Format Video Capture:
        Width/Height      : 100/100
        Pixel Format      : 'BA24'
        Field             : None
        Bytes per Line    : 400
        Size Image        : 40000
        Colorspace        : Default
        Transfer Function : Default (maps to Rec. 709)
        YCbCr/HSV Encoding: Default (maps to ITU-R 601)
        Quantization      : Default (maps to Full Range)
        Flags             : 
Format Video Output:
        Width/Height      : 100/100
        Pixel Format      : 'BA24'
        Field             : None
        Bytes per Line    : 400
        Size Image        : 40000
        Colorspace        : Default
        Transfer Function : Default (maps to Rec. 709)
        YCbCr/HSV Encoding: Default (maps to ITU-R 601)
        Quantization      : Default (maps to Full Range)
        Flags             : 
Selection: compose, Left 0, Top 0, Width 100, Height 100
Selection: compose_default, Left 0, Top 0, Width 100, Height 100
Selection: compose_bounds, Left 0, Top 0, Width 100, Height 100
Selection: crop, Left 0, Top 0, Width 100, Height 100
Selection: crop_default, Left 0, Top 0, Width 100, Height 100
Selection: crop_bounds, Left 0, Top 0, Width 100, Height 100

User Controls

                horizontal_flip 0x00980914 (bool)   : default=0 value=0
                  vertical_flip 0x00980915 (bool)   : default=0 value=0
                         rotate 0x00980922 (int)    : min=0 max=270 step=90 default=0 value=0 flags=modify-layout
               background_color 0x00980923 (int)    : min=0 max=16777215 step=1 default=0 value=0

/dev/video1

Spoiler

 


Driver Info (not using libv4l2):
        Driver name   : rockchip-vpu
        Card type     : rockchip,rk3288-vpu-dec
        Bus info      : platform: rockchip-vpu
        Driver version: 5.0.0
        Capabilities  : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps   : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
Priority: 2
Format Video Capture Multiplanar:
        Width/Height      : 48/48
        Pixel Format      : 'NV12'
        Field             : None
        Number of planes  : 1
        Flags             : 
        Colorspace        : JPEG
        Transfer Function : Default
        YCbCr Encoding    : Default
        Quantization      : Default
        Plane 0           :
           Bytes per Line : 48
           Size Image     : 3456
Format Video Output Multiplanar:
        Width/Height      : 48/48
        Pixel Format      : 'MG2S'
        Field             : None
        Number of planes  : 0
        Flags             : 
        Colorspace        : JPEG
        Transfer Function : Default
        YCbCr Encoding    : Default
        Quantization      : Default
        mpeg_2_slice_parameters 0x009909fa (unknown): type=103 flags=has-payload
   mpeg_2_quantization_matrices 0x009909fb (unknown): type=104 flags=has-payload

/dev/video2

Spoiler

 


Driver Info (not using libv4l2):
        Driver name   : rockchip-vpu
        Card type     : rockchip,rk3288-vpu-enc
        Bus info      : platform: rockchip-vpu
        Driver version: 5.0.0
        Capabilities  : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps   : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
Priority: 2
Format Video Capture Multiplanar:
        Width/Height      : 96/32
        Pixel Format      : 'JPEG'
        Field             : None
        Number of planes  : 1
        Flags             : 
        Colorspace        : JPEG
        Transfer Function : Default
        YCbCr Encoding    : Default
        Quantization      : Default
        Plane 0           :
           Bytes per Line : 0
           Size Image     : 6745
Format Video Output Multiplanar:
        Width/Height      : 96/32
        Pixel Format      : 'YM12'
        Field             : None
        Number of planes  : 3
        Flags             : 
        Colorspace        : JPEG
        Transfer Function : Default
        YCbCr Encoding    : Default
        Quantization      : Default
        Plane 0           :
           Bytes per Line : 96
           Size Image     : 3072
        Plane 1           :
           Bytes per Line : 48
           Size Image     : 768
        Plane 2           :
           Bytes per Line : 48
           Size Image     : 768

JPEG Compression Controls

            compression_quality 0x009d0903 (int)    : min=5 max=100 step=1 default=50 value=50

MPV/FFMPEG

Spoiler

 


Playing: /tmp/grb_2.mpg
[ffmpeg] Probing mpegvideo score:25 size:2048
[ffmpeg] Probing mpegvideo score:25 size:4096
[ffmpeg] Probing mpegvideo score:25 size:8192
[ffmpeg] Probing mp3 score:1 size:16384
[ffmpeg] Probing mpegvideo score:51 size:16384
[ffmpeg/demuxer] mpegvideo: Before avformat_find_stream_info() pos: 0 bytes read:16384 seeks:0 nb_streams:1
[ffmpeg/video] mpeg1video: Format yuv420p chosen by get_format().
[ffmpeg/demuxer] mpegvideo: All info found
[ffmpeg/demuxer] mpegvideo: Estimating duration from bitrate, this may be inaccurate
[ffmpeg/demuxer] mpegvideo: stream 0: start_time: -7686143364045.646 duration: 27.861
[ffmpeg/demuxer] mpegvideo: format: start_time: -9223372036854.775 duration: 27.861 bitrate=5999 kb/s
[ffmpeg/demuxer] mpegvideo: After avformat_find_stream_info() pos: 1223680 bytes read:1228800 seeks:0 frames:50
 (+) Video --vid=1 (mpeg2video 720x480 29.970fps)
[ffmpeg] AVHWDeviceContext: Opened DRM device /dev/dri/card0: driver rockchip version 1.0.0.
[ffmpeg/video] mpeg2video: Format drm_prime chosen by get_format().
[ffmpeg/video] mpeg2video: Format drm_prime requires hwaccel initialisation.
[ffmpeg/video] mpeg2video: ff_v4l2_request_init: avctx=0x1b2ddb0 hw_device_ctx=0x1b2c600 hw_frames_ctx=(nil)
[ffmpeg/video] mpeg2video: v4l2_request_probe_media_device: avctx=0x1b2ddb0 ctx=0x1b2f700 path=/dev/media0 driver=rockchip-vpu
[ffmpeg/video] mpeg2video: v4l2_request_probe_video_device: avctx=0x1b2ddb0 ctx=0x1b2f700 path=/dev/video2 capabilities=69222400
[ffmpeg/video] mpeg2video: v4l2_request_try_format: output buffer type do not support requests, capabilities 21
[ffmpeg/video] mpeg2video: v4l2_request_probe_video_device: try output format failed
[ffmpeg/video] mpeg2video: v4l2_request_probe_video_device: avctx=0x1b2ddb0 ctx=0x1b2f700 path=/dev/video1 capabilities=69222400
[ffmpeg/video] mpeg2video: v4l2_request_try_format: output buffer type do not support requests, capabilities 21
[ffmpeg/video] mpeg2video: v4l2_request_probe_video_device: try output format failed
[ffmpeg/video] mpeg2video: Failed setup for format drm_prime: hwaccel initialisation returned error.
[ffmpeg/video] mpeg2video: Format drm_prime not usable, retrying get_format() without it.
[ffmpeg/video] mpeg2video: Format yuv420p chosen by get_format().
[ffmpeg] detected 4 logical cores
[ffmpeg/video] mpeg2video: Format yuv420p chosen by get_format().
VO: [gpu] 720x480 => 720x540 yuv420p
V: 00:00:00 / 00:00:27 (0%)

And then the video plays in a fluid manner if I use the Mali binary blob for OpenGL output.

Edited by Tido
added spoiler

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@Myy I pushed some updated kernel branches to my linux-rockchip repo today that may help you get the vpu driver running.

 

Earlier this week I sent out my ffmpeg V4L2 request API hwaccel as RFC on ffmpeg-devel mailing list, see http://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242316.html

Important device tree and clk patches have already been merged or is queued for v5.1/v5.2.

 

If you apply both of these two patches on top of v5.0.7 you should have a kernel with working vpu mpeg-2 driver for rk3288, rk3328 and rk3399:

https://github.com/Kwiboo/linux-rockchip/compare/v5.0.7...rockchip-5.x-hdmi-sound.patch - contains all mmind/for-next patches merged/queued for v5.1/v5.2 + few patches from mailing list + my hdmi sound and cec patches

https://github.com/Kwiboo/linux-rockchip/compare/v5.0.7...rockchip-5.x-vpu-v2.patch - contains all v4l2 related media tree patches merged/queued for v5.1/v5.2 + Ezequiel rockchip vpu v2 patchset + my additions for rk3288 and rk3328

 

If you do not care for hdmi sound or cec improvements you can instead use the fromlist patch:

https://github.com/Kwiboo/linux-rockchip/compare/v5.0.7...rockchip-5.x-fromlist.patch - contains all mmind/for-next patches merged/queued for v5.1/v5.2 + few patches from mailing list

 

For mali kernel driver I recommend https://github.com/Kwiboo/mali-rockchip/commits/utgard-r9p0, see below how I build it:

 

make_target() {
  kernel_make -C $(kernel_path) M=$PKG_BUILD/driver/src/devicedrv/mali \
    MALI_PLATFORM_FILES=platform/rk/rk.c GIT_REV="" \
    EXTRA_CFLAGS="-DCONFIG_MALI400=1 -DCONFIG_MALI450=1 -DCONFIG_MALI470=1 -DMALI_FAKE_PLATFORM_DEVICE=1 -DCONFIG_MALI_DMA_BUF_MAP_ON_ATTACH -DCONFIG_MALI_DT" \
    CONFIG_MALI400=m CONFIG_MALI450=y CONFIG_MALI470=y CONFIG_MALI_DMA_BUF_MAP_ON_ATTACH=y CONFIG_MALI_DT=y \
    modules
}

makeinstall_target() {
  kernel_make -C $(kernel_path) M=$PKG_BUILD/driver/src/devicedrv/mali \
    INSTALL_MOD_PATH=$INSTALL/$(get_kernel_overlay_dir) INSTALL_MOD_STRIP=1 DEPMOD=: \
    modules_install
}

 

Share this post


Link to post
Share on other sites

( `・ω・́)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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

I have not yet tested lima or panfrost drivers since libmali is working better for my use case, will switch to lima and panfrost in future.

 

For midgard mali driver I am using https://github.com/Kwiboo/mali-rockchip/commits/midgard-r28p0 (contains a restore 10.6 api commit that makes it work with rk r14p0 libmali)

See https://github.com/Kwiboo/LibreELEC.tv/blob/rockchip-5.x/projects/Rockchip/packages/mali-midgard-rockchip/package.mk for how I build the midgard driver.

The midgard rk platform code is doing some unnecessary dev_info logging, but driver runs with mainline device trees on both rk3288 and rk3399.

 

I am not sure the v4l2 testing tools by bootlin etc is working with rockchip vpu driver (nothing I have ever tested).

The ffmpeg hwaccel from https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel and mpv patched with https://github.com/mpv-player/mpv/pull/6461 should work for both cedrus and rockchip vpu driver.

kodi-gbm should also work as long as ffmpeg used is patched and is built with --enable-v4l2-request --enable-libudev --enable-libdrm

Share this post


Link to post
Share on other sites
20 minutes ago, Myy said:

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.

I saw that as well, nice.

 

3 minutes ago, Kwiboo said:

For midgard mali driver I am using https://github.com/Kwiboo/mali-rockchip/commits/midgard-r28p0 (contains a restore 10.6 api commit that makes it work with rk r14p0 libmali)

:thumbup:

Share this post


Link to post
Share on other sites
1 hour ago, Myy said:

Are the FFMPEG patches you sent to their ML, the ones present here : https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel ?

Almost, that is the ffmpeg 4.0 branch I use myself, the ML patches was the ones at https://github.com/Kwiboo/FFmpeg/compare/bb5efd1727eeecc9be8f1402810c7ab72344eed3...v4l2-request-hwaccel-master.patch (same patches rebased on ffmpeg master), the FIXUP commit that I have added was just to do a rename as suggested by ML comments

You can use https://github.com/Kwiboo/FFmpeg/compare/21c13d04e624aabc1c78998f910782db673070e6...583677006f15ee59600f6f30f5e79aa5f81935b9.patch if you want the 4.0 version or the link above for a ffmpeg master patch.

 

1 hour ago, Myy said:

Also, do you have a working MPEG-2 sample, so that I can be sure that I'm testing with the right format.

I have tested https://samplemedia.linaro.org/MPEG2/ very much, the only sample I have had issue with was a field encoded mpeg2 sample been trying to find other field encoded samples in order to test but they are hard to come by.

Share this post


Link to post
Share on other sites

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 ( `・ω・́)

Share this post


Link to post
Share on other sites

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...

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
5 5