added
video=HDMI-A-1:1280x720M@60D to second line of the file.
cmdline.txt is a single line. Anything after the first newline is ignored. Make sure you add any options to the first line.
added
video=HDMI-A-1:1280x720M@60D to second line of the file.
cmdline.txt is a single line. Anything after the first newline is ignored. Make sure you add any options to the first line.
When I get video lags, I restart raspberry Pi and it helps... Have no idea why
Did you downgrade widevine as mentioned earlier. Latest widevine is known to cause lags.
Azurewrath can you try this test build.
I think the issue was your video was 10-bit but not HDR, which is a little unusual.
That meant the kernel didn't do a full modeset (as HDR colourspace didn't change) but did change the colour depth (which adjusts the pixel clock) which really wants a full modeset.
The test build is a stanard Matrix build with a kernel patch added to force the modeset.
I installed your test build and the 'vc4.inval_delay=5000' added to the cmdline.txt appears to have resolved the issue in my setup. That is with an LG C9 and Yamaha TSR-7810 AVR with the Rpi4 plugged into the AVR using CEC over the ARC HDMI connection. Thanks for looking into this issue! Does this test build include the updates from 10.0.2 and is it safe to continue running or do you recommend that I revert back until your fix is rolled into the next release?
Yes, this build matches 10.0.2 and you can continue using it. Please confirm if vc4.inval_delay=2000 also works for you.
Also report if vc4.inval_delay=0 vc4.cec_debug=0x100 works for you.
My TV is set to limited colour range. I don't want to change this because it is connected to an AVR with other devices which are all sending limited RGB (e.g. the Bluray player).
Limited/full range is signalled over hdmi (in the AVI infoframe) and generated by the source (e.g. the Pi)
You shouldn't set it on the sink (TV) - it should just display in the colour range that has been signalled.
Has the "plain" decoder (w/o PRIME) been fixed too? (i had the same issues when using the plain decoder w/o PRIME too)
No, the fix is in hardware decode specific code.
If it's failing without PRIME, then it suggests a core ffmpeg issue (so will affect kodi on any platform not using hw decode) and will affect many other players that use ffmpeg internally.
Did the original sample provided have the issue?
It was once again my bad as I put vc4.inval_delay=5000 after a line break and not immediately on the same line after "quiet" on cmdline.txt
And I'm happy to say that it is working with this value!!! It does not turn on after being powered off!! I'm so happy now!
Okay good to know. It would be helpful if you could confirm whether a smaller number also works (try with 4000, 3000, 2000).
Also try with "vc4.inval_delay=0 vc4.cec_debug=0x100" which I suspect will also fix it.
It would also be useful if any other affected users could test.
Yesterday I did the proposed update to 10.0.2 and since then the 3840x2160 24p video no longer switches to 24p. In 1080p no problem, the tv goes well in 1080p24. Did you have the same problem or do you have a solution please?
It's not something I see (or have seen anyone else reporting).
Probably best to create a new post, including a debug enabled log of you playing a 3840x2160@24 file, where the hdmi mode is not set.
I couldn't get that file to fail to play.
NeB are you using a whitelist?
I suspect your issue is probably related to hdmi cable, but having a whitelist set up (allowing lower resolution/refresh rates to be chosen) will make it less likely you'll hit issues.
See: https://wiki.libreelec.tv/configuration/4k-hdr
The debug log would be useful to see exactly which hdmi is being chosen.
Please note that /sys/module/vc4/parameters/inval_delay value is always 1000 regardless using vc4.inval_delay=5000 or vc4.inval_delay=0 vc4.cec_debug=0x100 at cmdline.txt
That suggests you haven't edited /flash/cmdline.txt correctly.
What does:
report?
By the way, how to make sure that the update occured?
LibreELEC5:~ # grep . /sys/module/vc4/parameters/*
/sys/module/vc4/parameters/cec_debug:256
/sys/module/vc4/parameters/fkms_max_refresh_rate:85
/sys/module/vc4/parameters/inval_delay:0
/sys/module/vc4/parameters/tv_norm:(null)
If you are not running the correct version, then you won't see the cec_debug/inval_delay entries.
And the values shown should match what you added to cmdline.txt
See post and test build here
There is a test build here.
Place in /storage/.update and reboot to update. It's a Matrix build with some kernel debug options added.
By default it should behave the same as official release. But you can try some modifications by adding options to /flash/cmdline.txt
The default behaviour delays invalidating cec address when hotplug is deasserted for 1000ms (in case it gets reasserted).
That fixes the AVS off/on problem for me with a Panasonic TV and Onkyo reciever.
Try with vc4.inval_delay=5000 (added to end of /flash/cmdline.txt) to increase this delay further.
If that fails, then try another setting.
vc4.inval_delay=0 vc4.cec_debug=0x100
That will ignore the hotplug deasserted message completely. I'd be interested if either (or both) of these helps.
Is it failing to boot, or failing to display a picture? Can you ssh in?
That's the setting. Post a debug enable log when playing a problematic video.
Logical next step is to bump the GPU frequency up a little, however if I even attempt to bump 'gpu_freq' up a mere 50Mhz to 550 then when I try to playback a h265 file, I will immediately lose video output but the OS doesn't crash and the Pi is still reachable via SSH and responds to commands so I can revert and reboot etc..
Disable "adjust refresh rate to match framerate" and I suspect you'll get a picture.
Your overclock is having the same effect as "hdmi_enable_4kp60=1" and something isn't supporting that.
Do you have another hdmi cable or 4k display to test with?