Nightly images for A64, H3, H5, H6 and R40 boards

    Downloaded some random popular youtube playlist, 1080p res, each video in h264, vp9 and av1.

    Latest master build for Beelink GS1, tested in both kodi and mpv.


    AV1 software decoding get H6 to its knees, all 4 cores loaded pretty much to 100%.

    H264 hardware decoding, no problems detected.

    VP9 hardware decoding, 49 of 50 videos played just fine, one produces garbled picture. Also, mpv sometimes hangs on VP9 videos, not a hard lock though, can Ctrl+C and play again.

    This VP9 clip fails to decode correctly

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Ah yes, H6 hardware decoding path also garbles everything when outputing to 1440p@144Hz my monitor HDMI defaults at.

    Downgrading video output to 1080p@60Hz solved the issue (except that one VP9 clip)

    Edited 2 times, last by offbeat: Merged a post created by offbeat into this post. (January 27, 2022 at 6:18 PM).

    Quote from jernej

    You expect too much from A53 cores. H6 predates AV1, so no HW decoding support.

    Yea, but it looks like H6 can handle 720p AV1, dav1d software decoder seems to be pretty optimized.

    Here is a different issue I mentioned in previous comment, broken hardware decoding outputing to 144Hz, video is plain h264.

    Switching to 120Hz or 60Hz fixes it, turning off DRM decoder solves the problem as well.

    Quote from offbeat

    Here is a different issue I mentioned in previous comment, broken hardware decoding outputing to 144Hz, video is plain h264.

    That might be DRM rendering issue. Can you try with switching DRMPRIME rendering from "direct to plane" to EGL? If that doesn't help, I don't know... I would need such monitor to test directly.

    Quote from jernej

    That might be DRM rendering issue. Can you try with switching DRMPRIME rendering from "direct to plane" to EGL? If that doesn't help, I don't know... I would need such monitor to test directly.

    Yes, prime decoder=ON + prime render=EGL helps, video is OK.

    Quote from jernej

    It's entirely possible that 144 Hz output needs some things to be done in more precise ways

    According to calculator, 1440p@144 pushes the very limits of HDMI 2.0 bandwidth, assuming H6 outputs full RGB.
    At least simple OpenGLES things like kmscube seem to render and output at 144FPS just fine, so it's only video plane output that has some glitch.

    Data Rate Required: 14.08 Gbit/s

    Video Format:

    2560 × 1440 (16∶9 ratio) at 144 Hz

    8 bpc (24 bit/px) RGB color

    Uncompressed

    CVT-R2 timing format

    HDMI 2.0 14.40 Gbit/s

    Quote from chewitt
    Code
    find / -name "*.nfo" -exec sed -i 's|http://imdb|https://imdb|g' {} \;

    ^ Something like that might work. You probably need to grep the possible values for the URLs from the .nfo files first so the sed find/replace is precise and doesn't have unintended results.

    Made the changes but it did not make a perceptible difference to the performance of the scan. At least the Amlogic is working fine.

    Thanks

    Quote from offbeat

    At least simple OpenGLES things like kmscube seem to render and output at 144FPS just fine, so it's only video plane output that has some glitch.

    Correct. I believe the issue is timing - HW scaler for video plane is a bit sensitive when registers are updated and I'm pretty sure we don't write them at optimal moment.

    Quote from levitsky86

    Jernej, I have just tried that but it says it was unable to run one, or two media files and I can find info in log files.


    http://ix.io/3Nta

    This is not debug log. Not a single line which would say "DEBUG".

    Quote from jernej

    everlanes sorry, a bit late, but nevertheless: http://jernej.libreelec.tv/test/vp9/ If you have issue with any VP9 video except 10-bit (currently unsupported by the driver), please provide short (5 - 30 seconds) video sample.

    Also a bit late, I gave it a try. Sadly it did not help. I did a few tests with "Big Buck Bunny". Used the original movie (Video: h264 (High) (avc1 / 0x31637661), yuv420p, 4000x2250 [SAR 1:1 DAR 16:9], 10002 kb/s, 60 fps, 60 tbr, 60k tbn, 120 tbc (default)) and converted it to different codecs and resolutions (see the script change.sh in the cloud link below):

    Codec h264: worked for all resolutions - so it is not depending on the movie size

    Codec VP9: worked for some resolutions, but not for all:

    • All movies with width >= 785px and width <= 1280 are working (4k was not working)
    • starting from width <= 784 px movies are scambled - especially 720x576 - DVD (see image in cloud link below)
    • made one test with 320x240 - this was working

    It is somehow depending on the width, not the height of the movie. Especially the DVD resolution 720x576 is not working - very sad for my kids, cause a lot of children movies and tv shows are in this format.

    Libreelec VP9
    Nextcloud - a safe home for all your data
    nextcloud.brinner.net