Myy

Members
  • Content Count

    283
  • Joined

  • Last visited

About Myy

  • Rank
    Elite member

Contact Methods

  • Website URL
    https://miouyouyou.fr

Profile Information

  • Gender
    Not Telling
  • Interests
    https://www.patreon.com/Miouyouyou

Recent Profile Visitors

1673 profile views
  1. Interesting find. They seem to talk about filling up a "form" to get more informations, but I can't find that form. Do you know if the hardware decoder documentation is still available on this site ?
  2. Yeah, just retried with his latest patches (both kernel and FFmpeg using some new flag M2M_HOLD_CAPTURE_BUF WIP) and it's better, but blocks are still flickering a little. However, most of the issues are gone so, I guess that between mid-June~July H264 support will be top notch. VP8 support has been added to the driver, but either his FFmpeg is not able to decode this format, or MPV refuses to use this hardware decoder ("codec vp8 is not on whitelist" error).
  3. Alright, I understand that downloading some precompiled binary by who-knows-who, and tinkering here and there to get it working, sounds shady and fucking annoying. So, instead, I made a script that allows you to download a fresh official FFmpeg, apply @Kwiboo and @jernej patches against it to get V4L2 Request API support, and compile the whole thing (binary and dynamic libraries). Now, this *won't* install the patched FFmpeg, for reasons stated above. https://github.com/Miouyouyou/FFmpeg-V4L2-Request I didn't apply bbrezillon patches, since I haven't tested his latest modifications and, ATM, there were issues here and there. I'd love some good H264 support, but you'll have to wait a bit.
  4. Trying to compile FFMPEG statically worked... Trying to compile MPV, though, was a disaster since it wants *every potential library* as a statically linked library when trying to link against FFMPEG... Which makes no sense to me, if you link against a statically linked FFMPEG, why would need a static libdrm and libudev ? Still, throwing "-Wl,-Bstatic" before "-ludev" result in ldd not finding the right libraries and I don't see how to resolve the problem in a "nice" way (meaning not hacking through the configure script). So, anyway, I decided to provide the dynamically linked FFMPEG and mpv instead. You'll need the following libraries to use the provided libraries : ld-linux-armhf.so.3 (Available on any ARM debian system) libc.so.6 (GlibC - installed by default) libdrm.so.2 (libdrm2) libm.so.6 (GlibC - installed by default) libpthread.so.0 (GlibC - installed by default) libudev.so.1 (libudev1) libva-drm.so.2 (libva-drm2) libva.so.2 (libva2) libva-x11.so.2 (libva-x11-2) libvdpau.so.1 (libvdpau1) libX11.so.6 (libx11-6) libxcb-shape.so.0 (libxcb-shape0) libxcb.so.1 (libxcb1) libxcb-xfixes.so.0 (libxcb-xfixes0) libz.so.1 (zlib1g) So, basically : apt install libdrm2 libudev1 libva-drm2 libva2 libva-x11-2 libvdpau1 libx11-6 libxcb-shape0 libxcb1 libxcb-xfixes0 zlib1g Or maybe just apt install libdrm2 libudev1 libva2 libva-x11-2 libvdpau1 libx11-6 libxcb1 zlib1g For mpv, you'll need : ld-linux-armhf.so.3 (Available on any ARM debian system) libass.so.9 (libass9) libc.so.6 (GlibC) libdl.so.2 (Available on any ARM debian system) libdrm.so.2 (libdrm2) libEGL.so.1 (libegl1) libgbm.so.1 (libgbm1) libjpeg.so.8 (libjpeg1) libluajit-5.1.so.2 (libluajit-5.1-2) libm.so.6 (GlibC) libpthread.so.0 (GlibC) librt.so.1 (GlibC) libz.so.1(zlib1g) So basically : apt install libass9 libdrm2 libegl1 libgbm1 libjpeg1 libluajit-5.1-2 zlib1g ffmpeg-mpv-dyn.tar.xz ffmpeg-includes.tar.xz
  5. Ah, indeed, I forgot about statically linking some media players, like MPV, against patched FFmpeg. I'll use that for MPEG-2 support. And, yeah, Chromium and Firefox bundle their own FFmpeg, so they'll need to be patched independently once H.264, VP8 or MPEG-4 full support hit the kernel.
  6. VPU patches re-ordered, remade and tested against 5.1 release kernel, with the usual patches combined. I retested the H264 driver with a slight fix and it's better, but there's still a few blocks not placed correctly here and there. This might be resolved this month, though. Anyway, it's MPEG-2 decoding only for the moment. Note to @TonyMac32, if you want to import these patches, the actual kernel patch list I'm using is there : https://github.com/Miouyouyou/RockMyy/blob/master/GetPatchAndCompileKernel.sh#L57 Now, what remains is FFmpeg. I don't remember if Ubuntu is still using libav, or went back to FFmpeg. I remember that the projects forked for some weird reasons and Debian went with libav... So, basically, do I create a package, or just a tarball with the libraries. With just the tarball, you'll have to extract them somewhere and run LD_LIBRARY_PATH=/path/to/ffmpeg/libs to use them with mpv and such. With the Debian package, you get the advantages (automatic dependencies handling) along with all the troubles (packages conflicts). I still have to test bootlin libva too, since it seems to go well with VLC.
  7. Here's a first draft of the patches I pulled from bbrezillon tree : https://github.com/Miouyouyou/RockMyy/tree/SplittingPatchesForVPU/patches/kernel/v5.1/VPU These are applied against mainline v5.1-rc5 kernels, and have been tested with Kwiboo's FFMPEG and a standard MPV. I'll try to test them, and adapt them, against v5.1 releases tomorrow. Then I'll re-arrange them and do a release of RockMyy. I'll then generate a FFmpeg package with Kwiboo's patch, using Kwiboo's tree, since bbrezillon's one doesn't integrate udev /dev/video node detection. And *then* I'll give the whole thing to test to @TonyMac32, who loves testing random VPU patches for Tinkerboards.
  8. ... May I know since when people working on RK3288 VPU knew this ? Did someone try to port the iMX VPU and found "Hey... this looks similar !" ? And, I know it's bad. If you got a mail from iMX, I'll remove the PDF @Igor. However, for the record, here's the VPU registers documentation : out.pdf
  9. ... So, just to see what are the latest LKML gossips, I went to LKML.org. Besides the common people throwing a tantrum because they provided their work under a license and want to rescind it, for whatever reasons, I saw this : Hardware-accelerated video decoders used through a firmware instead of hardware registers I skimmed that thread, by curiosity. Basically, Paul Kocialkowski and Nicolas Dufresne are talking about current developments in the Video decoders, and how to deal with angry closed blobs coming from nowhere. But then, Nicolas then threw this, out of nowhere : ... !!? Ok, let's search on the web for "Hantro G1". Maybe I'll find the Reference Manual for this chip. And I stumbled on this : https://github.com/linux4sam/gst1-hantro-g1 (Gstreamer implementation) https://github.com/linux4sam/g1_decoder Oookay... Maybe this doesn't work on RK3288 boards. I'll have to check. Still, they *REALLY* look similar : https://github.com/linux4sam/g1_decoder/blob/master/software/source/common/8170enum.h#L38 https://github.com/Miouyouyou/Mainline-VPU-V4L2-Edition/blob/master/rk3288_vpu_regs.h#L155 ROCKCHIP ! What the FUCK !? Why did you ask Google to develop a driver for your VPU, while the company already had all the documentation about your chip !? By the way, the chip in itself, is able to decode a good lot of formats : http://www.verisilicon.com/IPPortfolio_14_58_2_HantroG1.html
  10. Instead of doing a proper packaging job, I decided to test the H264 decoder because... Hey, H264 ! If it works, it means we can actually use RK3288 boards to watch YouTube, Netflix and Twitch.tv, boosting productivity by 10x ! But, nah... the H264 is still a Work In Progress. While the basics work (Sending the V4L2 request, Getting an image back), I tried with a video that was lying on my PC HDD, their FFMPEG and mpv and... I got some weird blocks interlacing with frames replacing each other... It's not ready. But there's clear progress made. Still, the kernel from bbrazillon can be used for MPEG-2 decoding too, since it integrates Kwiboo's work, so I'll use this base, strip the changes to the bare minimum required by the V4L2 decoders, generate a patch, integrate it into my main build script and let everyone have fun with this. Then I'll retry with RK3399 boards.
  11. Nice ! However, since Kwiboo actually patched FFMPEG to add V4L2 request support, the FFMPEG might actually be neeed to. I'll try to run the standard Debian packaging sequence you pasted.
  12. V4L2, with the right kernel headers, is enough. In this version RKMPP isn't needed. Now, there's also a libva driver being developed. I didn't test it, though. It seems to be used in combination with VLC. I'll test it if I can get the H264 decoder working.
  13. Interesting. I'll take a look at their work.
  14. Anyway, I'll get some sleep and, tomorrow, I'll see if I can retest this on RK3399 devices like a NanoPC-T4 (and maybe the Orange Pi 3399... though my last try with the Orange PI and mainline kernels was terrible).
  15. Nice ! I'll take a look at this branch and try to extract the minimal set, in order to test it on mainline kernels. Now, I guess that for H264, I'll need to port this : https://github.com/Miouyouyou/Mainline-Rockchip-VPU/blob/dev/based_on/rk3288_vpu_hw_h264d.c ? Is there test code available for RK3288 or RK3399 ? Or is it too soon ? Meanwhile, @JMCC , do you feel like trying to create a script, that automatically build FFMPEG + MPV with V4L2 Request support ? Or shall I ?