RPi4 testbuild with HDR support

    My bad. For some reason my Pioneer reciever seems not to like HDR from the pi4 at times.

    I connected the pi4 directly to my tv and HDR plays fine :)


    Strange with the reciever as it passes HDR from shield and AppleTV 4k without issues. I did test same inputs/cables and it seems that it passes HDR at times but only works randomly with the pi4 for some unknown reason.


    I will try and reset the reciever to factory default and see if that helps. but another day, there is a lot to configure etc after a reset :P

    I see this same behavior over wifi with "LibreELEC-RPi4.arm-9.80-nightly-20210205-3420901" copying the update to it, its copying then drops to 0 b/s, copying the 0 b/s, etc But this time updating to HDR build, it is streaming movies fine, tested copying files to it and fine also. I test network with stable 9.2.6 and stream same movie fine. Ping test 100 packets and no loses.


    i can report this;


    Again 'big step' jump forward crashes to librelec splash screen and did not recover.


    ix.io/2OBe (and attached)

    Ok did some more testing today. Did reset my AVR and HDR works everytime now.


    updated from current nightly to this build with HDR went fine both from SD card and SSD hdd.

    HDR plays nicely :) Thank you for this! Been waiting long time for this to arrive for the pi4 :)


    I did chapter skip both ways and it works for me.

    running this since yesterday, very smooth, looks good to me so far. Will let you know if I can find any issues.


    Thanks for all the great work!

    HiassofT


    I get some visual issues appearing once every other minute or so, nothing can be seen in the log while it happens,

    i mailed you link to sample, ive also notices simular glitches on some 1080 non hdr materials, might be related, tell me if you want samples of those too

    I noticed on mine the config.txt only had gpu_mem=76 so I bumped it.


    gpu_mem=512 made it carp itself.


    gpu_mem=320 works.

    Edited once, last by wanderlei ().

    Quote from wanderlei

    I noticed on mine the config.txt only had gpu_mem=76 so I bumped it.

    Keep it at 76, it's been changed to that for a reason. New graphics stack needs CMA, not GPU memory, and at best you'll just waste memory, at worst you'll run into crashes because of memory exhaustion.


    so long,


    Hias

    Here's a new testbuild with HEVC decoding fixes: LibreELEC-RPi4.arm-9.80-devel-20210210171544-68ac68f.tar


    Some HEVC files showed pixelation artefacts (decode errors) and the "Samsung Wonderland Two" demo from 4kmedia.org resulted in a hard crash because the decoder ran out of memory. The HEVC decoder now handles out-of-memory situations much more gracefully and we've increased the default CMA memory size to 512MB so the file can be properly decoded.


    so long,


    Hias

    Thanks for this build! I updated from the latest nightly (LibreELEC-RPi4.arm-9.80-nightly-20210210-06bafb5.img.gz), which was installed freshly to the SD card. I tested a few video files via LAN. Audio was fine. In theory, HDR was being played (according to my Sony KD65FX9005), but there was a clear difference in image quality comparing the same scene being played via Plex on my TV itself and Kodi.


    Unfortuantely, the screenshot function doesn't work properly:



    Using my phone, I made this picture from Kodi:



    And from Plex running directly on my TV:



    The difference is visible on the pictures, though it is greater in real life.


    I have attached the log file as well. This is not meant as critique, it's more like feedback. I'm thankful development is going in the right direction :) BTW, I also ran the file locally by copying it over and tried multiple files just to be sure.


    Edit: I literally posted this 3 minutes after you posted the new dev file. I'll update and report back.


    Edit2: No changes after updating.


    Edit3: Cannot upload the edid.dat as *.dat file (the forums won't let me), so I appened .log to it.


    Edit4: Tried connecting the RPI 4 directly to my TV (HDMI 1), same result.

    AriaTwoFive have you checked if the Plex player on TV and Kodi used identical picture settings?


    On my LG TV picture settings (brightness, colour temperature, "optimizations" etc) can be configured independently for internal player(s) and each HDMI port - and it's quite easy to miss that they might be set differently.


    If you have another player app on your TV (eg to play from USB media) or some other external player it'd also be interesting to cross-check with these.


    As it's bleeding edge code I wouldn't rule out that something is off a bit, but we also have to make sure we don't compare with a player/source that applies different video settings.


    so long,


    Hias

    JohnWayne111 just talked to RPi devs but you might not like the answer:


    RPi4 doesn't have hardware support for HDR-to-SDR tonemapping, it might be possible to tweak things a bit but the result will always be off - either too dark or too light.


    Simple solution: don't use HDR encodes if you don't have a HDR display.


    You could also try to re-encode the HDR files on your PC, ffmpeg (and probably other encoders) should support that with tonemap filters (never used that myself though).


    so long,


    Hias

    Hi there,


    I couldn't get 4k HDR playback to work, but changing the playback resolution to 1080p let it play (tv showed hdr10 properly, colors looked accurate). I attached my logfile, I think I set logging up correctly? Let me know if I should add anything else.


    hastebin


    The video would just stutter at 4k hdr, mostly showing a black screen that would flash with one or two frames per second. Some 4k HDR movies wouldn't even play, would just show a black screen (but wouldn't crash, stopping the video would pull the GUI back up). These were all very high bit rate files.


    Thanks for all your work on HDR on the Raspberry Pi 4! it is very exciting that it is so close!


    EDIT: I removed the attached zip log file and added a paste kodi link instead.


    Thanks,

    Edited once, last by aakister ().