> Issue does not reproduced on nightly build dated about 20201120.
HW hevc decode may not have been supported back then, so you may have always had this issue.
I'd predict that disabling DRM Prime HW decode in settings would avoid the artefacts.
It is possible you have a hardware fault. You don't have another Pi4 you could try the sdcard on?
The workaround just gets half-SBS 3D playback working like on the other players you suggested.
i.e. with no 3d menus/subs.
It is on the list of things to fix, but it's not the highest priority.
If it is a "really simple fix", then pull requests are welcome.
Nope.
Simply no... SBS 3D videos play normally on any software player I've tried, they simply consist of two both frames side-by-side ... any mplayer/VLC/SMplayer plays them fine - apparently with no "driver" the projector does the decoding/alternating of the frames.
None of those players bother to have 3D menus or 3D subtitle support. - which is still working for nice video playback.
Here we have a perfectly fine SBS menu, subtitles in 3D , but instead of displaying both frames inside the picture, like those players do .. it seems we somehow crop the output to one single frame.
The workaround is to not tell kodi the files are 3D.
Make sure filenames do not contain the 3d tags (either by changing the filename or the default 3d tags matched):
or use the OSD interface to set the file to 2D.
That should mean the menus/subs won't go into 3D mode, but it also means the video will be played normally,
which for half-SBS/half-TAB is what you want.
I believe it was no longer needed after a wireless firmware update:
There is test firmware in this thread which may help this issue.
It is possible the test firmware from this post may help
Issue is over voltage
Cannot be set higher then
over_voltage=3
I've found an issue with over_voltage=4 (or higher) on Pi2.
Can you test this firmware
Unzip and replace http://start.elf/fixup.dat on boot partition with start_x.elf/fixup_x.dat from zip file.
Let me know if over_voltage=4 starts to work again.
Your sample does generate a "hevc @ 0x168ca90] Out of pu + coeff intermediate memory: pus=768" warning which doesn't seem to be handled well.
I've forwarded the report to our hevc codec guy.
The bitrate limits are complicated. Generally higher bitrates means more motion vectors which tends increase cache misses and so increase sdram bandwidth. sdram bandwidth is usually the constraint on playing harder samples.
You can get a slight increase in sdram bandwidth with hdmi_enable4kp60=1 (even if you don't use a 4kp60 mode) as it runs the AXI bus at 550MHz rather than 500MHz.
The GUI overlay takes some bandwidth, so subs, OSD, debug info etc will cost some additional bandwidth.
It may also be worth monitoring the hevc clock (vcgencmd measure_clock hevc) when the video is playing. I believe it will be 500MHz when busy and 250MHz when less busy. If it's dropping to 250MHz when your stream is playing that would limit the streams you can play.
hevc can be overclocked, or you can disable the lower frequency (force_turbo=1 in config.txt) which could help.
Can you provide a sample file that freezes the Pi4
While we're unlikely to be able to play very high bitrate clips smoothly, they shouldn't cause a freeze.
As it's showing same symptoms with raspbian, then it might be worth creating an issue here:
Issues · raspberrypi/firmware · GitHub
where the right people should see it.
OffLoad could you try installing raspbian on an sdcard, and use the display configuration tool to switch to 4kp30.
Does that have the same problem? If so can you also try with hdmi connected to other hdmi port
(this doesn't work with kodi, but should with raspbian).
Does 4kp24 work?
I'm suspecting that the cable is borderline (I know it has worked on another device, but it could be just on the edge of being usable at 4kp30).
But to begin with see if we can rule out a kodi/LE issue.
The fix was done long ago, but is stuck in a PR and hasn't made it into an official build:
That sounds like 1366x768 doesn't work on raspbian (the scrambled display should be showing a dialog saying "do you want to keep this resolution" which is timing out and putting you back to the old resolution)
Can you confirm that it still fails with latest firmware (using rpi-update on raspbian).
Assuming it does then this is a firmware issue rather than a kodi issue and reporting it here would be best:
Can you choose 1366x768 from raspbian? Does it work?
state 0xa [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60Hz, progressive
Okay so that is using a more standard resolution so not surprising that worked.
Was that the default resolution when you booted raspbian or did you change it yourself?
I've poked the hdmi experts for advice. Can you report output of "tvservice -s" when using raspbian (and display is working)?
I wonder how the Pi 4 will behave with enclosures such as these that are basically one large heat sink for all chips.Would make it easy to carry around also. I refuse to rely on active cooling. A Pi has to be completely silent to begin with, and I travel quite a lot so the less parts and wires that can break the better.
I'd expect that to work well assuming it is a large piece of aluminium with good thermal connection to SoC.
Flirc cases have historically worked very well using the same principles.
I'm also expecting the new Pi4 version of Flirc case to work well when I get to try one.
