Posts by popcornmix

    This doesn't sound like a LibreELEC issue.

    And USB isn't something I know too much about.

    I'd suggest opening a kernel issue and describing the issue,

    where a USB expert may have better advice.


    If you can reproduce the issue with RPiOS then that would be even better (as there may be more debugging tools available).

    My videos are encoded as AVC 5.1 with 16 reference frames, and will only play audio, the screen freezes and GUI elements start leaving trails on the screen. If I press top, the screen returns to normal.

    The Pi hardware decode is only specced for level 4.1 (which is the BluRay standard).

    Don't encode videos like that.

    If you set gpu_mem (in config.txt) high enough, the videos will probably play, but you may have issues with the reduction in arm side memory this results in.

    If you add vc4.force_hotplug=1 to cmdline.txt (on existing line) the the Pi will never know if the TV or AVR has been switched off.

    It will be outputting exactly the same signal before and after. Does that change anything?

    Code
    Feb 16 19:10:56.709875 LibreELEC kernel: vc4-drm gpu: [drm] *ERROR* Failed to read TMDS config: -121

    I've never seen this error on a Pi. It comes from an SCDC command to check scrambling status (something specific to 4kp60 modes).

    This uses the I2C pin (also used for reading edid) to communicate with the display.

    I'd typically suggest trying with a different hdmi cable, trying a different hdmi input to display, or trying a different display.

    But:

    Quote

    As of today, I use an RPi4 4GB in an Argon One housing.

    Argon cases are widely reported to cause hdmi issues, so first step would be to test without the case.


    A workaround would be to avoid 4kp60 modes (4kp30 should be okay).

    As most 4k content is 24fps or 30fps this may not lose you much.

    Choose 1080p60 as GUI resolution and enable 4kp24 and 4kp30 in the whitelist.

    4:2:2 MPEG2 content triggers a restart from the LE splash screen

    4:2:2 h.264 content also triggers a restart from the LE splash screen

    I've just tested and some similar files are playing for me (nighyl LE12 on Pi5):

    and

    (10-bit, 12-bit, and 444 variants also playing). So I guess there's something different in your files.

    4:2:2 video like that currently causes my LE Pi 5 to reboot - though AIUI the CPU should be fine to decode it in software (as it also should 4:2:2 MPEG2) so this is less likely to be a hardware limitation on the Pi 5, more a software issue that needs some work.

    Is this LE11 or LE12? I did spend a while making sure the software paths for the all the weird formats I would find (which did include 422/444 as well as 10-bit/12-bit) did the right thing. That may be LE12 only.

    If LE12 fails, can you point me at a sample file that crashes and I'll look into it.

    Some are based around YCbCr (aka YUV) PQ HDR10 or HLG 10-bit HEVC/h.265 and then Dolby Vision RPU metadata (and in some cases also an expansion layer to get from 10-bit to 12-bit depth). These can usually be replayed with no Dolby Vision licensing requirement for the HDR10/HLG stuff. Examples of this type of DV sources are Dolby Vision UHD Blu-rays and DV video shot on iPhones.

    Other DV stuff is encoded purely in a DolbyVision video format using ICtCp representation and PQ instead of YCbCr/YUV - though still encoded in 10-bit HEVC/h.265. When these are replayed by non-Dolby Vision licensed devices they replay with magenta/green colours instead of normal colours, because they are interpreted as YCbCr when they aren't. This format is widely used for streaming platforms - where the streaming player can request a specific encode that it can play (rather than a single encode needing to be playable by multiple devices). The CoreElec DV implementation can play these OK, few other devices can.

    Is there an easy way (e.g. using mediainfo, what is the relevant string to look for) to see which case a video is in?

    Do you believe the first case here can be decoded and displayed correctly, purely by outputting the untouched YCbCr data from decoder and the appropriate metadata? I believe the second case requires per-pixel processing which is likely infeasible at 4k without dedicated hardware or a very high performance gpu.

    Any chance of LLDV decoding from Kodi on RPI4 (I read ffmpeg libplacebo can decode DV) and do HDR10 dynamic tonemapping like hdfury processor?

    My TV is a Samsung and it doesn't decode DV.

    I'd say no possibility for 4K video (neither cpu nor 3d hardware has performance for this).

    I don't know if 1080p would be possible.

    But most hdr content is 4k.

    I'm now seeing the latest version doesn't even have analogue output as an audio option anymore. So that's a definite deal-breaker for me with my old stereo system. Apparently I'm expected to either replace my hardware/stereo, or buy an additional adapter (micro-HDMI to audio) just because Kodi thinks I should be limited to just HDMI and bluetooth outputs?

    Add "dtparam=audio=on" to config.txt.