jernej

Members
  • Content Count

    834
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by jernej

  1. I'm not sure what to say, most likely your installation of customized ffmpeg didn't replace all ffmpeg libraries installed from repository (likely, because mpv doesn't complain about wrong version). This procedure worked well for me with ALARM rootfs.
  2. With mainline kernel, driver is more or less the same as on H3, so everything here applies.
  3. it's a long time since I build packages on Debian based distro, but wouldn't "sudo apt-get build-dep ffmpeg" help in this case?
  4. I guess that if you specify only those arguments I gave you to ffmpeg configure script it will build monolithic binaries which is not what you want. I suggest that you check what arguments were used to build ffmpeg from Debian repository by reinstalling it from repository and running "ffmpeg" without any arguments. Use them and add those which I mentioned. After you build ffmpeg and install it, I think mpv will complain that it can't run with different ffmpeg libraries. Then you have to rebuild mpv.
  5. ffmpeg configure script does some checking and if no appropriate library is found, option is disabled anyway. Can you make sure that you have libdrm, libudev and kernel headers installed?
  6. It seems that your ffmpeg doesn't support request api decoding. You can check that by searching for "h264_v4l2request" in output of "ffmpeg -decoders". Can you give your configuration output printed by "ffmpeg" (without any parameters)?
  7. ok, I didn't know that neo doesn't have HDMI output. In that case, you can replace "drm" with "null". I think it should still give useful output.
  8. log status is not implemented by cedrus. Do you have /dev/dri/card0? Do you have any monitor connected? It seems to me that mpv can't find any monitor. Yes, it should. But kernel patches used in LE and FFmpeg contain hacks which are used to handle some cases (interlaced videos). That makes interface incompatible for VAAPI library until right approach is agreed upon and implemented. This may take a while, though.
  9. I haven't been clear enough. You can go either ffmpeg way or VAAPI way (technically using VAAPI with ffmpeg should be possible, but that's not tested). So no, VAAPI is not used. Are you running this in desktop environment? If so, it won't work. You have to shut down whatever desktop you're using and run this command from command line. Note that this is only for test to see if known good configuration works.
  10. @FGuerzoni can you add -v to the command line? it should give enough details then to figure out why it isn't working.
  11. I don't know, first try with mpv? If that works, we can be sure that it works and move forward. Did you fix your user permissions? or just for sake of trying, can you run it as root?
  12. It's tricky and needed kernel header files are not exposed in UAPI (userspace API) yet because they are still evolving and changing. You can try following: 1. Apply Linux patches 1 (you can filter out only media related patches), 5, 7-11 on kernel 5.3: https://github.com/jernejsk/LibreELEC.tv/tree/cedrus_update/projects/Allwinner/patches/linux 2. Apply all FFmpeg patches on FFmpeg 4.0.4 (it is easy to port those patches on newer version, to avoid rebuilding mpv): https://github.com/jernejsk/LibreELEC.tv/tree/cedrus_update/packages/multimedia/ffmpeg/patches/v4l2-request-api 3. Compile FFmpeg with at least following options --enable-v4l2-request --enable-libudev --enable-libdrm 4. Recompile mpv if needed - depends on FFmpeg version used. If it matches to what was was used to compile mpv with, then there is no need. 5. Add your user to appropriate group ("video" I think) so you can use VPU without root privileges. Now you should have working mpv with HW accelerated decoding. As I don't use any desktop on SBCs, I run mpv with following options: mpv --hwdec=auto --vo=drm video.mkv This gives you most speed - HW decoded and directly rendered by DRM driver, so CPU is not involved. Only downside is that it is fullscreen only. Not sure how big performance hit (CPU usage) you would get with X11.
  13. Show your DT patch. It shouldn't be that hard to make it work.
  14. In the old days, I provided OpenELEC images with 3.4 kernel (https://github.com/jernejsk/OpenELEC-OPi2) and it worked with 4K videos on 1080p display. Sadly, images don't exist anymore and source doesn't build anymore. Be aware, I used CedarX library instead of libvdpau-sunxi. I don't think I ever make it work with 4K screens, mostly because I didn't have such screen at the time.
  15. Hi! HW video decoding on mainline kernel is possible, but in most cases you have to do some kernel patching yourself and use special library which provides VAAPI or use modified ffmpeg libraries. MPEG2 decoding is possible with kernel 5.0 or 5.1 (not sure), basic H264 decoding will be possible with kernel 5.3 and HEVC decoding will probably come with kernel 5.5 (patches already exist). Note that H264 and HEVC codecs are feature incomplete currently. However, I did some improvements for LibreELEC and there most H264 and HEVC videos work. Patches are available on LibreELEC github but are incompatible with VAAPI library, so only option is to use modified ffmpeg. Regarding memory consumption, please note that with OrangePi Lite you have only 512 MiB of RAM which is a bit low. LibreELEC for that reason doesn't support devices with less than 1 GiB of RAM. Consider following calculations for memory requirements, no matter which kernel you use: 1. Multiple variants of 4K and 1440p resolutions exist, so I'll assume that 4K means 4096x2160 (same as on my LG TV) and 1440p means 2560x1440 2. kernel allocates one XRGB (4 bytes per pixel) buffer for user interface (no matter if you're using window manager or not), so for that you need 4096*2160*4 ~ 34 MiB of CMA memory 3. video is decoded to NV12 or NV21 formats and both take 1.5 byte per pixel, that means 2560*1440*1.5 = 5.27 MiB of CMA memory per single frame 4. worst case for H264 and HEVC is that you need 16 reference frames to properly decode current frame, which means additional 5.27 * 16 ~ 84 MiB of CMA memory 5. VPU needs additional scratch buffers per frame. Size of those buffers depends on codec features used, but for H264 is typically about 1/4th of multiplied width and height, so in worst case (1 + 16)*2560*1440/4 ~ 15 MiB of CMA memory 6. VPU needs some other scratch buffers, but they are small, about 1 MiB in total 7. you also need additional CMA memory for providing encoded data to VPU, but memory consumption for that heavily depends on userspace library/player implementation. Hard to give any estimation, so let's use 20 MiB. Final estimation for worst case display + VPU CMA consumption for 4K display and 1440p video: 34 + 5.27 + 84 + 15 + 1 + 20 ~ 160 MiB. You also have to consider that other devices may use CMA memory at the same time. In LibreELEC, CMA memory size is set to 256 MiB because so much is needed for decoding 4K videos. Hopefully that gives you perspective how much memory is needed for H264/HEVC video decoding. I won't touch (use) 3.4 kernel anymore, but I can help you with patching mainline kernel for better H264 and/or HEVC support and bring up ffmpeg based solutions (that includes mpv), if you want.
  16. I haven't work on thermal nor on cpufreq driver for any SoC yet in LibreELEC, so I'm not familiar with possible issues.
  17. @PiotrO 5.3-rc8 contains fixes needed for this workaround to work. Can you try again?
  18. Yes and fixes are here. Not sure when they'll be merged to 5.3 though.
  19. It's hard limit - address space is 32-bit and first byte from DRAM can be reached at address 0x40000000 (1G). If Allwinner would re-arrange peripherals below 1G, it could squeeze out another 512M or so, but in that case memory address decoder becomes more complicated (slower).
  20. Not today, I'm tired too. But I'm pretty sure someone would reviewed them because others complained too.
  21. Note that 5.3 will be released in about 2 weeks so don't delay too much I would say that you can just reply to cover letter, but in this case there isn't any, so yes. You can also reply with reviewed-by if you understand the code, but tested-by already helps.
  22. @hexdump can you test patches from Maxime? It would be nice to respond with Tested-by tag if it works.
  23. strange, then I have no idea and without HW I'm not sure I can do much. Maybe it's connected to DRAM issue
  24. @hexdump One of the mysteries is solved. Tanix TX6 doesn't have external 32768 Hz crystal, so it has to use internal one. After a quick hack in RTC driver, which takes care for that, there is no more RTC issues reported in dmesg and HDMI-CEC works from the beginning. I wonder if this also helps with Eachlink HDMI issue. Can you test this LE image on Eachlink box?