Posts by popcornmix

    I have your sample file and can reproduce the crash.

    Looks like the crash is in SetPictureParams calling an invalid function pointer.

    I'll need a debug build to narrow it down further.

    edit:

    Looks like disabling deinterlace avoids the crash.


    Also for me, this crashes:

    Allow DRM PRIME decoder ON

    Allow hardware acceleration with DRM PRIME ON

    Allow hardware deinterlace with DRM PRIME OFF

    This does not crash:

    Allow DRM PRIME decoder ON

    Allow hardware acceleration with DRM PRIME ON

    Allow hardware deinterlace with DRM PRIME ON

    I believe the Touch Display 2 is natively portrait, and kodi doesn't support rotation through DRM so this is not going to work well even if you get the touchscreen working (presumably there are kernel commits missing).

    Running RPiOS desktop, and using kodi21 from apt would support rotation I believe (but it's a less efficient render path).

    With latest nightly, you can enable NUMA to get better performance. See numa thread.

    Make sure bootloader is updated to latest and set:

    SDRAM_BANKLOW=1 (for pi5)

    SDRAM_BANKLOW=3 (for pi4)

    using using rpi-eeprom-config.


    From previous testing, on a pi5 I'd expect any 8-bit 1080p60 AV1 to play fine, and most 10-bit 1080p60.

    1080p24/1080p30 will have no problems.

    NUMA likely means any 10-bit 1080p60 will play on a Pi5.


    Pi5 is around 2 to 2.5x the speed of Pi4, so Pi4 abilities will be lower.

    I'd predict any 720p60 AV1 files to play okay, and some 1080p30 on a Pi4.

    Quote

    This seems to be the normal speed for that hardware. The NIC specs don't mean you really get it in real life.

    No. The linked chewitt post reported:

    I see transfers around ~112MB/s from an RPi5 with nvme storage.

    112MB/s is 896Mbit/s, so very close to gigabit.


    Yes - you can get close to gigabit real world speed from a Pi5 ethernet port.

    This assumes the rest of the network devices and cables can handle gigabit.

    The Pi5 can't wakeup over CEC. You can configure to shut down when TV shuts down, but you'd have to use the power button on the Pi5 to switch back one. There do exist some addon boards (HATs) that can power cycle the pi.

    But most users leave the Pi on continuously - it uses little power.

    popcornmix what's the latest on that front? - I can see pelwell and @6by9 commenting so it's presumably on their radar.

    Sorry I have no knowledge of this issue beyond this.

    I believe officially WPA3 is not supported on any Pi boards, although with combinations of custom versions of wifi firmware, kernel patches and userland libraries some users have had success, but I don't believe it's mature enough to say "this will work".

    popcornmix is there any way to force 1080p composite output using kernel DRM?

    No, composite cannot handle HD. From here:

    Quote

    Composite video is an baseband analog video format that typically carries a 405, 525 or 625 line interlaced black and white or color signal, on a single channel,

    I don't know if there was a way to force an older version of LE using the firmware driver to generate a 1080p gui, and rescale it down to SD, then output it. If there was it wasn't a deliberately supported use case and kernel driver has no mechanism for that.

    No. The projector just turns off. Shuts down exactly as if I were to hit the standby/power button on the projector's remote. I need to hit the power button on the remote to turn the projector back on to re-display the picture. The Pi 5 and receiver continue playback through the process. However, I do notice a brief blip in the audio when this happens.

    Hmm. If you asked me to create some code that ran on the Pi and powered off the projector without using CEC (which you say is disabled) or DDC (which the pi will never send without running an external program like ddcutil), I'd say that was impossible.

    Your projector is choosing to power off for some reason. It could be an intermittent hardware fault of the projector.

    It could dislike something about the signal coming from the pi over hdmi (although switching to standby is very surprising for this - normally you would expect a loss of sync, resulting in a temporary black screen, and recovery shortly after).

    The likely causes for it not liking the signal (after it being happy for ~25mins) is something marginal - possibly caused by a poor hdmi cable/adaptor, or an inadequate power supply (the 5V from the power supply does go over the the hdmi cable and powers the display/projector's hotplug/edid logic).

    Might be worth timing how long playback lasts before failure. If it is always 25min then that would be interesting (but I suspect it is more likely random).

    Recommendation for the dev team: If someone enables passthrough then enable it for all formats by default...it makes no sense I have to go into Expert mode and enable them manually despite the main passthrough being enabled already. :)

    Not really.

    A TV supporting AC3 passthrough is quite common.

    A TV supporting DTS passthrough is quite rare.

    A TV supporting DTS-HD/TrueHD passthrough is almost unheard of.


    Enabling passthrough on a device that doesn't support it, will at best produce silence and possibly loud white noise.

    25ish minutes into a longer movie, projector will shut off but my receiver and Pi 5 will continue to play. The playback may stutter a second or two after this happens as well but resumes.

    Just to be clear, the projector shuts off for just a couple of seconds then resumes normally?

    hdmi cable would be my first guess. What's the hdmi resolution/refresh rate?

    For 4kp60 you do need a high quality cable (and mico hdmi -> full size adaptor if you are using a separate one).

    Does it still occur if you force hdmi mode to 1080p?


    Other tests would be does the issue occur if you connect straight to projector (no AVR)?

    Does the issue occur with a normal TV instead of projector?