[Linux] Video playback broken with Electron 0.36.8+

[asherkin]

onFrameSetup is called fine, onFrameReady is never called.

I'm thinking this is probably a Linux-only issue, and possibly related to "Don't drop capabilities in renderer process." from the Electron changelog - since VLC (well, I think avcodec actually) is also now logging detected 4 logical cores. I'm guessing multithreaded software decoding is going awry somewhere.

[RSATom]

What VLC version do you use?

[asherkin]

Got a couple of patches (unrelated to anything important - just HLS bandwidth selection tweaks) on top of the tagged 2.2.2 release.
Nothing was changed other than the electron version when bisecting it back to 0.36.8.

[RSATom]

Thanks, I'll look.

[RSATom]

checked on Windows with Electron 0.36.9 - it works fine... so it could be really linux specific...

btw, why do you need 0.36.9?

[asherkin]

I'm after `BrowserWindow.getNativeWindowHandle`, but there are quite a few other nice-to-haves (like the premature remote object freeing, which I'm running into quite a lot) - generally I like to stay as current as possible anyway, it makes reporting issues easier.

[RSATom]

I'm after BrowserWindow.getNativeWindowHandle

Does it mean it's possible now place custom windows on Electron main window? Maybe I should resurrect WebChimera plugin then...

[Ivshti]

Hm...that one is new... @RSATom if a window handle is all you need, then please consider doing something with it!

Do you think it's possible, if you get a window handle to a transparent Electron window, to draw a video via VLC, or even better - MPV - in it's background?

[RSATom]

Yes, I can, but unfortunately not in background. I.e. don't think it will be possible place any html elements over it. That's why I'm thinking about WebChimera, i.e. some video engine + QML for UI.

[RSATom]

Something very strange happening. I can't play .avi on Linux with Electron 0.36.9.

[0000169ee8958518] core decoder error: Codec `mp4v' (MPEG-4 Video) is not supported.
[0000169ee8958518] core decoder error: Codec not supported
[0000169ee8958518] core decoder error: VLC could not decode the format "mp4v" (MPEG-4 Video)

the same file plays fine in NW.js

[asherkin]

And the plot thickens...

With v0.37.2, most things work fine - but any media requiring libavcodec for decoding crashes inside Electron's libffmpeg.so (testing with a H.264 / AAC M2TS stream). If I replace libffmpeg.so with the one Electron provides without propriety codecs (so no H.264), no crash and audio plays fine, but obviously no video.

It is quite the mystery.

Crash dump: https://gist.github.com/asherkin/9f805d8adfbdde5034a4
(it it would actually be useful, I could gather the relevant libvlc symbols as well)

Hi guys,

Is there any news on this issue? I'm seeing the exact same thing with Electron/WebChimera.js(specifically wcjs-player) on Linux (Debian 8.0). Any version of Electron < 0.36.8 is working fine, but newer versions do not show the video. In the console I get the error:

[h264 @ 0x3c4f2cac4680] no frame! (many times)

I would like to go to Electron v1.0.* because that fixes some other issues (non WebChimera.js related) I'm having, but this issue is preventing me from doing so.

Please let me know if I can do more to troubleshoot or find more information, happy to help tracking down the problem.

[RSATom]

@jayke-vbh, unfortunately still can't find enough time to find solution... sorry. Will try to do something soon.

[asherkin]

My theory here is that the problem is caused by Electron's libffmpeg.so exporting symbols as global, which are being used in preference to the ones in the system's libavcodec.so (which are what VLC's libavcodec_plugin.so is expecting to get). I ran into a similar issue in another project I work on recently, which caused similarly confusing issues.

$ find . -type f -print0 | xargs -0 nm -AD 2>/dev/null | grep avcodec_default_get_format
./vlc/lib/vlc/plugins/codec/libavcodec_plugin.so:                 U avcodec_default_get_format
$ find /usr/lib64/ -type f -print0 | xargs -0 nm -AD 2>/dev/null | grep avcodec_default_get_format
/usr/lib64/libavcodec.so.56.26.100:0000000000418860 T avcodec_default_get_format
/usr/lib64/vlc/plugins/codec/libavcodec_plugin.so:                 U avcodec_default_get_format
$ find /usr/lib/node_modules/electron-prebuilt/dist/ -type f -print0 | xargs -0 nm -AD 2>/dev/null | grep avcodec_default_get_format
/usr/lib/node_modules/electron-prebuilt/dist/libffmpeg.so:000000000015edb0 T avcodec_default_get_format

Chromium is explicitly building without -fvisibility=hidden, so this behavior is intentional - I'm not sure why libavcodec_plugin.so is taking offense however, this should work fine. In the case of the other mentioned issue, it was a conflict in global-static variable storage.

My next line of investigation will be attempting to create a compatible libffmpeg.so from the standard distro-supplied ffmpeg libs (it's an amalgamation of what should be at least libavcodec.so and libavformat.so), but that'll probably be many moons away - pinning my Linux release to 0.36.7 is still holding out for me, but steadily getting more painful.

EDIT: Heh, on a whim I just deleted libffmpeg.so and things were in basically the same state (other than Electron losing playback support, which is absolutely fine with me), it's leaving time here so I won't get a crash dump / debugger attached until next week and verify it's crashing in the same spot - but it may imply that all of the above is a red-herring and just deflecting away from a real internal issue (I'm finding WC.js surprisingly crashy all round, and have had to implement auto-recovery for renderer crashes - bad interaction with the custom memory allocator methinks).

EDIT 2: I'm a lemon and had a copy of libffmpeg.so in my LD_LIBRARY_PATH from the above debugging.