-
Notifications
You must be signed in to change notification settings - Fork 559
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RPi] RPi4 video H.264 & H.265 (HEVC) glitches #553
Comments
I believe the problem is that we're not propagating the DRM format modifiers. The Pi's HEVC decoder outputs this weird Broadcom-specific tiled NV12 SAND128 format that is probably why the output appears tiled like that. I fixed that issue in e87a5fa for the DRM renderer, but EGL will require some more work. Please test the new code with the |
I reworked the way the DRM->EGL buffer export works to avoid assuming the format of the DRM frames and simply draw them as a single opaque EGLImage with 26d04b5 You can now try both I will try to get my Pi 4 to test with the LibreELEC FFmpeg patches. I did test on my RK3288 board, but that VPU never had problems with the old method since it produced "normal" NV12 linear buffers. |
I've bumped the moonlight version to 4a8c9ad and will rebuild the RPi4 images since I don't own RPi4 SBCs I have to wait for feedback or you grab an image and give it a try Indeed it looks like every SoC/VPU design has it own shenanigans to deal with but I guess once the RPi 4 works moonlight is all set. |
User feedback:
New logs with latest head: @cgutman SSH: |
I got some feedback:
Looks like Logfile HEVC: Logfile h.264 |
The EGL fallback to direct DRM rendering is fixed as of e74753b and 74bf981, so the HEVC problems are all solved and I'm probably not going to put much effort into the Pi's H.264 issues with V4L2. I have not found h264_v4l2m2m on the Pi to be anywhere near low latency enough to use for Moonlight, even with the DRM-PRIME patches from LibreELEC. The MMAL code is much faster (assuming cgutman/FFmpeg@193a032 is applied) and has the benefit of being able to draw overlays with X11 running too. Even if h264_v4l2m2m could decode fast enough, performance of rendering frames with |
As long as HEVC works proper it's something. Since MMAL is a proprietary API it's a dead horse in the long run since all major platforms move to V4L2 iirc but I understand that you can't fix problems in h.264 decoder code which needs improvements in upstream anyway. According to Wikipedia most Maxwell and all important Pascal cards support HEVC encoding, so if someone uses older cards and a RPi4... well sorry but you're doomed 😅✌️ |
@cgutman do you have time to look at this bug: veldenb/plugin.program.moonlight-qt#9 ? It looks like LibreELEC has updated to the latest libraries but it breaks the HEVC decoding in Moonlight-qt (glitches) for the Pi4. Moolight-qt logs and changes in LibreELEC can be found in this comment: veldenb/plugin.program.moonlight-qt#9 (comment) It might be caused by the latest ffmpeg or raspberrypi libraries. |
As follow up to #409 (comment) I've created some RPi4 testbuilds based on latest LibreELEC 10.0beta builds.
Could you have a look at the logfile? I have to talk to the RPi4 devs if there are any known quirks but at least h.264 should be fine 🤔 But maybe you can have a look at the FFmpeg patches for RPi & make the work as you did for RK.
Forum link:
moonlight-qt glitches
H.264 log:
moonlight-qt.log
HEVC:
Logfile:
The text was updated successfully, but these errors were encountered: