Native decoding on Raspberry Pi 4 #129
Comments
|
I was wondering if the 1.7 build has had any advancements on the stability of playing back with hardware support. The Raspberry page hasn't been updated with any tests there. Is it assumed now that it will work better, or possible no issues on the Pi 4 because it has more power? Has anyone had any success testing on the Pi4? S |
|
Hello, |
|
Thats awesome. When you say mostly. What's missing? |
|
I pushed the rpi4 acceleration support to the master branch. It's also now available in the latest arm AppImage build. Note that only video with 4:2:0 subsampling is supported and there are a few limitations like not being able to resize or move the video output once it is on the screen. To use it launch ultragrid like this |
|
Thats awesome. Looking forward to test that out. Its common that only 420 is hardware accelerated so I am sure it will work just fine. |
|
AWESOME ! |
|
Sorry for the dumb question, but when I try to decode I get the following error. I'm using 420 h.264, do I have to use the omx h264 to be able to work? Unable to find decoder for input codec "H.264"!!! |
|
It looks like this acceleration method supports only hevc (H.265). |
|
When trying to run Ultragrid on a Raspberry pi4 I am receiving the error I am using the nightly build if UltraGrid and have tried on both the desktop and console version of Raspbian. |
|
The missing "/dev/rpivid-hevcmem" was resolved with rolling back to an older Raspberry pi firmware. |
|
Have been able to get video to decode on RPI4 and it's rock solid. That being said have been challanged with getting HDMI audio to pass. Getting ALSA errors on the HDMI port audio. |
|
Did you try alsa or pulse? |
|
speaker-test does produce audio on the HDMI output without error |
|
@alatteri you are correct -r alsa corrected the issue, thanks |
|
Still playing around with this but it looks like in recent versions of raspberry pi firmware they have moved /dev/rpivid-hevcmem to /dev/video19. Is there a way to specify a different rpivid device |
|
I looked into it and it appears that it's not as simple as changing the path. The whole API changed. We might look into supporting the new API sometime in the future, but I can't promise anything right now. Also, for the sake of documentation, could you please share which version of the firmware works for you with the current implementation? |
MMAL headers not present in 64-bit RaspiOS 11 libraspberrypi-dev (but mmal.pc is still there!) The MMAL API doesn't seem to be longer supported, see necro-posting in CESNETGH-129.
|
I have been having good success with UG on RPi4 with this firmware / raspbian release. |
|
Just a heads up, I was looking into getting this to work again and I was able to implement partial support. Decoding HEVC works, but only in copy mode right now, so the performance is not completely there yet for perfectly smooth playback. As a part of this I switched the armhf continuous builds over to raspbian bullseye and removed the old hwaccel implementation, since there is no point in maintaining it if it no longer works. As such the 1.9 stable branch will be the last one to support rpi hwaccel on raspbian buster. |
|
I am going to grab a pi5 and can play around with UG on a fresh bullseye install (debian 11). |
|
@MartinPulec I cloned the rpi_bookworm branch and built it on a rpi5 clean os install. Here are a list of features that were discovered during the build process Does it make sense to investigate the rpi5 as it it is more full featured and affords vulkan sdl2 support out of the box? |
|
The master branch now contains a special That said, it is also quite inflexible. It needs exclusive access to the connected display, which means that you can't have any other display server running (no X11, Wayland, desktop environment, etc.). At the moment it also doesn't support any scaling, so the connected display device needs to support a video mode that is appropriate for the decoded video (the decoded video can be larger than the display resolution, in which case it is cropped, but it cannot be smaller). Scaling could be probably implemented using overlay planes in the future, but right now I don't know if the Raspberry hardware supports this or if it would be performant enough.
You need to install the appropriate development packages for the features that you want. See this section of the wiki for more info.
We currently do not have any rpi5 on hand to test or develop on. That said, the current implementation of the acceleration probably could work on the rpi5 as well and we would be happy if you let us know if that's indeed the case. Also this issue is quite old, grew quite long and even branched out into unrelated topics. Now that the display module is merged it seems like a good time to close this. For any bugs, feature requests, etc. please create new issues or discussions. |
The Raspberry Pi 4 has hardware HEVC decoding so it could make a very nice display device for UltraGrid. With VLC and ffmpeg I'm able to get smooth playback of 4K 10-bit (limited to 4:2:0) with about 30% CPU usage.
From what I've read, the HEVC decoder uses a custom pixel format known as "sand". Converting this to a standard pixel format is too slow for realtime, so I think the only option is to pass the opaque sand buffers to the HDMI output which knows how to display it.
Example ffmpeg command (built from https://github.com/popcornmix/FFmpeg/tree/kodi_v4l2_4_2_2):
The text was updated successfully, but these errors were encountered: