[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)

[ghost]

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.

[ghost]

Thanks for acknowledging this is still an issue. For the moment this is preventing me to use this as a solution, while it seems well suited otherwise.

Is there anyway I can help by performing tests or looking into things? I'm not very experienced with linking of libraries and stuff, but maybe I can do something. Otherwise, I would be willing to offer a bounty, if that would help prioritize this issue for you guys?

[RSATom]

Is there anyway I can help by performing tests or looking into things?

Unfortunately no, it's require C/C++ software debugging/bugfixing skills to get it solved...

Otherwise, I would be willing to offer a bounty, if that would help prioritize this issue for you guys?

It's already number 1 issue in my priority list, I just don't have free time atm. So bounty will not help much...

[RSATom]

I think problem is really come from libffmpeg.so from Electron. I've tried preload this libffmpeg.so to QmlVlcDemo with LD_PRELOAD and got the same problem with .avi playback. So I think problem is really with exports with same name in different .so modules.

All possible solution I can imagine at the moment are pretty complex:

1. Rebuid Electron without media playback support (i.e. without libffmpeg.so) or with libffmpeg statically linked to Electron module (as it was before Electron v0.36.8)
2. Implement import table replacement at runtime: https://www.apriorit.com/dev-blog/181-elf-hook (same in Russian: https://habrahabr.ru/post/106107/)

[RSATom]

I think second option will be better solution, but unfortunately it will take pretty huge amount of time to implement it, which I don't have atm... So help wanted...

[MikeGCV]

The issue with the latest builds of electron in linux is solved?

[RSATom]

@MikeGCV, I didn't solve it. Maybe something was changed on Electron side, I didn't check.

[amilajack]

Has this changed with the current modern versions of electron? I've built this from source on my linux machine and it seems to have compiled against electron 1.2.7. Does mean that it works properly now?

[RSATom]

@amilajack, it builds without problem, but didn't run due to conflict with ffmpeg bundled with Electron.

[RSATom]

but I didn't try latest versions.

[amilajack]

I see. How can I try this out myself after I have built it?

[RSATom]

@amilajack, Just try https://github.com/RSATom/wcjs-ugly-demo with WebChimera.js built against latest Electron

[amilajack]

Just made a repo to test this out:

https://github.com/amilajack/wcjs-example

The problem is that electron exits with no errors. Do you know the reason for this?

[RSATom]

Don't see any issue in your code, but I didn't try run it. Maybe it's the problem with Electron. Try the same with older Electron(it's 100% worked with Electron v0.33.9).

[0181532686cf4a31163be0bf3e6bb6732bf]

Well, it builds without any errors, have to try it in the app

[0181532686cf4a31163be0bf3e6bb6732bf]

@RSATom, I think I've found out why this happens:

1. While building via Travis you're using libvlc-dev for Linux (https://github.com/RSATom/WebChimera.js/blob/master/.travis.yml#L30) and prebuilt VLC for OSX (https://github.com/RSATom/WebChimera.js/blob/master/travis_before_install.sh)
2. This prebuilt stuff is already linked to system's default ffmpeg
3. Your wrapper links to it -> it links to default system libs
4. Compiled node extension is also linked against system vlc (Gentoo):

/tmp/test/WebChimera.js$ ./build_electron.sh
[snip]
/tmp/test/WebChimera.js/build/Release $ lddtree WebChimera.js.node 
WebChimera.js.node => ./WebChimera.js.node (interpreter => none)
    libvlc.so.5 => /usr/lib64/libvlc.so.5
        libvlccore.so.8 => /usr/lib64/libvlccore.so.8
            librt.so.1 => /lib64/librt.so.1
            libidn.so.11 => /usr/lib64/libidn.so.11
            libdl.so.2 => /lib64/libdl.so.2
                ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
            libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3
        libpthread.so.0 => /lib64/libpthread.so.0
    libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6
    libm.so.6 => /lib64/libm.so.6
    libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgcc_s.so.1
    libc.so.6 => /lib64/libc.so.6

It does not indicate ffmpeg here, but I'm assuming it does dlopen or something like that since ffmpeg is required dependency: https://wiki.videolan.org/Contrib_Status/#Usage

In the extension I develop currently (node-libtorrent-ng) I've had a similar issue, I had to use a third-party library (libtorrent) which's dependent on boost and always resolved to local system's boost. I ended up compiling everything as static (both libtorrent and boost) and linking into the addon; this way I managed to do a truly redistributable library (depends only on libstdc++) with acceptable size (about 4Mbs, even lesser than boost + libtorrent compiled as dynamic!).

My ideas are:

1. Use recent (or not) libvlc, and compile it as static;
2. In case of compiling against electron, link explicitly to its ffmpeg (-L), though it may involve some play with rpath for Mac;
3. Bundle everything into your addon, thus making it independent on system libs (no need to install VLC) and redistributable.

What do you think?

[RSATom]

The problem is it's not so easy build libvlc as static library

[0181532686cf4a31163be0bf3e6bb6732bf]

I will try to do it. Also, there's kind of official cpp wrapper: https://code.videolan.org/videolan/libvlcpp/tree/master

[TRPB]

Is this something that could be more easily fixed electron's end or does it have to be fixed here?

[RSATom]

@TomBZombie, if you can rebuild Electron - yes, you could change Electron's build configuration to link ffmpeg statically.

[kazemihabib]

@RSATom , @lyssdod
hi, I found a way to fix the problem in arch linux with help of https://github.com/tensor5/arch-atom/tree/master/electron .
In arch linux the package of atom in official repository not uses the embeded electron , it installs the electron package first then uses that .
in the link above as you see they write patches for static library , use system ffmpeg and ... .
so if you use arch linux electron package and webchimera it will work (I tried it works :) )
with those patches and rebuild electron will fix the problem in other linux distributions too.

[thesabbir]

can anybody fix this or let us know how to?

[RSATom]

@thesabbir, I think the simplest solution will be rebuild electron with patches mentioned by @kazemihabib

[sunxfancy]

@RSATom Any update? Is there a way to build customized libffmpeg.so to replace the default one?

[RSATom]

@sunxfancy, no. I didn't work on this issue.

Is there a way to build customized libffmpeg.so to replace the default one?

You don't need rebuild libffmpeg.so, you need rebuild Electron with static libffmpeg. And no, I didn't investigate how to do it yet.

[Kagami]

Simplest workaround that I use for mpv.js/boram is:

gcc -shared -lavformat -o node_modules/electron/dist/libffmpeg.so

It's unfortunately broken since 1.4.15: electron/libchromiumcontent#268

[Kagami]

Also found workaround for latest Electron! See Kagami/mpv.js#10 (comment)

[RSATom]

@Kagami, is it use sandboxed libmpv?

[Kagami]

No, the system one.

[RSATom]

hm... so pepper plugins could be run in not sandboxed environment? Interesting

[Kagami]

Yes. It's kinda intended for dev purposes, but nothing prevents you to use in production :) (Well, there are few pitfalls, but not critical.)

[vishal733]

I'm planning to try WebChimera.js on latest electron version: (v1.7.6). Seems there's a lot to try to get it to work. And seems quite involved.
Just one question. WebChimera.js doesn't require any NSAPI support on chrome side, right? Since that's already been removed from Chrome.

[RSATom]

@vishal733, no, WebChimera.js doesn't require NSAPI. It's based on Node.js addons API.

[RSATom]

Closed as too old.