4

I have firstly played with the Raspbian config for video to see if that's the cause but after trying the web app within a different browser (Chromium included) it works.

I have a web version of my video playback app that I can load via URL in the included Chromium application that comes with Raspbian and it plays videos windowed, full-screen, etc perfectly, looks great and no video tearing.

I now package that same web app up, no differences, into an Electron app built for Linux-arm in a DEB package, and when I install it and open app, the videos play still, functionality is there, but playback has horizontal video tearing on videos with lots of movement.

I'm curious if anyone knows how to build the Electron prebuilt with flags or other settings to mimic the Chromium application that is included on Raspbian? Is the included Chromium app using VLC as the video renderer somehow?

Thank you.

Edit 1:

I opened chrome://gpu on both Chromium and the Electron app. The versions are slightly different, but wouldn't expect enough to be the cause. The driver bug workarounds and problems detected are slightly different and I don't know how to make the Electron app use the same "config" as the Chromium. Below is both gpu reports with differences in the Electron app highlighted.

I suspect problem lies in these workarounds that are only found in the Electron report. No idea how to compile the Electron app to no do these workarounds

>> decode_encode_srgb_for_generatemipmap
>> disable_post_sub_buffers_for_onscreen_surfaces

>> Disable partial swaps on Mesa drivers (detected with GL_VERSION): 339493
Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces

>> Decode and encode before generateMipmap for srgb format textures on os except macosx: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap

Electron GPU Report:

Graphics Feature Status

Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Disabled
Hardware Protected Video Decode: Unavailable
Rasterization: Software only. Hardware acceleration disabled
Skia Renderer: Disabled
Video Decode: Unavailable
Viz Display Compositor: Enabled
Viz Hit-test Surface Layer: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

Driver Bug Workarounds

clear_uniforms_before_first_program_use
count_all_in_varyings_packing
>> decode_encode_srgb_for_generatemipmap
>> disable_post_sub_buffers_for_onscreen_surfaces
exit_on_context_lost
rely_on_implicit_sync_for_swap_buffers
scalarize_vec_and_mat_constructor_args
disabled_extension_GL_KHR_blend_equation_advanced
disabled_extension_GL_KHR_blend_equation_advanced_coherent

Problems Detected

Accelerated video decode is unavailable on Linux: 137247
Disabled Features: accelerated_video_decode
Protected video decoding with swap chain is for Windows and Intel only
Disabled Features: protected_video_decode
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Mesa drivers in Linux handle varyings without static use incorrectly: 333885
Applied Workarounds: count_all_in_varyings_packing
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
>> Disable partial swaps on Mesa drivers (detected with GL_VERSION): 339493
Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces
>> Decode and encode before generateMipmap for srgb format textures on os except macosx: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Some drivers can't recover after OUT_OF_MEM and context lost: 893177
Applied Workarounds: exit_on_context_lost
Avoid waiting on a egl fence before swapping buffers and rely on implicit sync on Broadcom GPUs: 938286
Applied Workarounds: rely_on_implicit_sync_for_swap_buffers

Version Information

Data exported   2020-04-03T02:18:39.594Z
Chrome version  Chrome/78.0.3904.130
Operating system    Linux 4.19.108-v7l+

Chromium GPU Report

Graphics Feature Status

Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Disabled
Hardware Protected Video Decode: Unavailable
Rasterization: Software only. Hardware acceleration disabled
Skia Renderer: Disabled
Video Decode: Unavailable
Viz Display Compositor: Enabled
Viz Hit-test Surface Layer: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

Driver Bug Workarounds

clear_uniforms_before_first_program_use
count_all_in_varyings_packing
exit_on_context_lost
rely_on_implicit_sync_for_swap_buffers
scalarize_vec_and_mat_constructor_args
disabled_extension_GL_KHR_blend_equation_advanced
disabled_extension_GL_KHR_blend_equation_advanced_coherent

Problems Detected

Accelerated video decode is unavailable on Linux: 137247
Disabled Features: accelerated_video_decode
Protected video decoding with swap chain is for Windows and Intel only
Disabled Features: protected_video_decode
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Mesa drivers in Linux handle varyings without static use incorrectly: 333885
Applied Workarounds: count_all_in_varyings_packing
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Some drivers can't recover after OUT_OF_MEM and context lost: 893177
Applied Workarounds: exit_on_context_lost
Avoid waiting on a egl fence before swapping buffers and rely on implicit sync on Broadcom GPUs: 938286
Applied Workarounds: rely_on_implicit_sync_for_swap_buffers

Version Information

Data exported   2020-04-03T02:19:47.378Z
Chrome version  Chrome/78.0.3904.108
Operating system    Linux 4.19.108-v7l+
Improve this question
4
  • No, Chromium uses FFmpeg libs for video playback.
    – Dmitry Grigoryev
    Commented Mar 27, 2020 at 13:01
  • Hello @DmitryGrigoryev thanks for the clarification. I've edited my question if you would like to take a look. Not sure where to go from here.
    – ScottN
    Commented Apr 3, 2020 at 2:37
  • Sorry, I don't think I will be able to help. I usually answer every bountied question I see, but this is literally the first time I hear about Electron.
    – Dmitry Grigoryev
    Commented Apr 4, 2020 at 9:23
  • 1
    No problem. I've created a bug report on Electron Github and may get more assistance there. Thanks.
    – ScottN
    Commented Apr 5, 2020 at 18:21

1 Answer 1

Reset to default
1

The version of Chromium in Raspbian's repo (chromium-browser package) is patched to support hardware decode on the Pi. The patches are here: https://github.com/RPi-Distro/chromium-browser/tree/master/debian/patches

Electron bundles and patches Chromium itself and doesn't use the patched system version. I've looked at producing a patched build of Electron that includes Pi decode patches, but it's a bit complicated because there's no matching Chromium version between Electron and the Pi Chromium patched versions, and the patches are highly Chromium version specific. Maintaining a patched Electron would be quite a lot of work.

There's no hope of upstreaming those Pi patches either, because once patched Chromium won't work on anything except a Pi.

The most efficient route is an external accelerated player I think, though it would theoretically be possible to patch electron, it's s lot of work.

Improve this answer
4
  • Thanks for you informative answer. I've been able to get my web app working with Chromium in kiosk mode, but after some hours, Chromium crashes and needs to restart. I've put in monitoring in my background services to monitor for that, but I assume the patches used to make hardware decode are making it more unstable. Electron plays for days and days, no issues when using software decode. If I knew more of this I would love to help debug those instability issues with Chromium and the patches applied. Any ideas where to help?
    – ScottN
    Commented Apr 6, 2021 at 17:45
  • Another question: I come from a Windows background, writing high framerate applications with DirectX, and now moving to Linux, the best and easiest solution was for me to use a web based app since it's more platform agnostic. But, with my lack of Linux and external accelerated players, I don't know where to start that would be worth my time to start a dedicated external app in a certain framework and library. Any pointers would be appreciated.
    – ScottN
    Commented Apr 6, 2021 at 17:47
  • @ScottN depends if you're talking the Pi or not. Generally speaking I think your two options for building a custom video app that runs on Linux are to use one of FFMpeg or GStreamer, probably wrapped in some kind of framework like SDL or Qt, which provide some bindings. The Pi OS patches the FFMpeg and GStreamer libraries they distribute for hardware acceleration support, so as long as you're dynamically linked to them you'll get accelerated playback. I don't myself have experience in this area, but that's the theory as I understand it.
    – Neil
    Commented Jul 18, 2021 at 21:44
  • thanks for the response. With the most recent version of Electron and building for ARM on the Pi, the tearing issues seem to be gone. Although, inspecting the media rendering within the Chromium portion, it's still doing software rendering. I've even installed the Vulkan drivers. My guess is I need to provide some switches to Chromium so it will attempt to use those drivers.
    – ScottN
    Commented Jul 19, 2021 at 22:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.