Sand sticks to vlc if launched from Vivaldi downloads
When I download a video file and open it from Vivaldi (e.g. double click in Downloads), vlc starts but fails to find necessary video codecs (weirdly it can play the sound).
When I open the same file normally, not from Vivaldi, vlc plays it fine.
I assume this has something to do with sandboxing or whatever which corrupts the execution environment for the processes launched by Vivaldi.
Do you experience the same issue?
becm last edited by
@smartptr the corrupting factor is very likely the (crude) way Vivaldi injects a modified
libffmpeg.sovia its wrapper script for proprietary codecs.
The most extreme form would be to use the standard packaged version and see
VLCfail to play normal media:
LD_PRELOAD=/opt/vivaldi/lib/libffmpeg.so vlc <mediafile>
- missing decoders for
- crash on
- missing decoders for
@becm, you're right, thank you.
This LD_PRELOAD ffmpeg made the 'VLC could not decode the format "mp4v" (MPEG-4 Video)' trick.
smartptr last edited by smartptr
I tried to copy the libavcodec.so (installed normally from Ubuntu repository) to /opt/vivaldi-snapshot/lib (with libffmpeg.so name) and even rename this directory, but that didn't have any effect.
I don't know now how does Vivaldi find and fake this libffmpeg.so for child processes.
@smartptr the library in the
<vivaldi>/libdirectory is not the problem.
It is used by
The problem arises if there is a
libffmpeg.soin one of the directories checked by the
Only then the
LD_PRELOADvariable is set.
This hijacks functions before they can be resolved via regular means.
In this way VLC (and other applications) are broken, although they do not link against a
It also messes with the
libffmpeg.soshared object lookup, replacing the packaged (
Otherwise Vivaldi would no longer work after your copy/rename test!
My example was to demonstrate the smallest feature set with the highest possibility for codec failure.
libffmpeg.sowith proprietary codecs has better (but still incomplete) codec support and thus less failure conditions.
DO NOT replace the /opt/vivaldi/lib/libffmpeg.so! It is needed by Vivaldi!
If you want to add the proprietary codec from Ubuntu repo you have to copy to ~/.local/vivaldi/lib/ or /opt/vivaldi/
Interestingly I have not experienced any issue with renamed /opt/vivaldi-snapshot/lib so far, but I'll eventually test further.
I don't have anything in .local/vivaldi*/lib by the way. Looks like there's another location from where this library comes (I'll try to debug this deeper).
Anyway it's good already that we agree that this is not the best behavior for a browser. I assume there is already an issue in the bug tracker which tracks the problem.
I do not know where you got the idea that there may be a different folder for Vivaldi channels. =:(
Keep care: the are not many local vivaldi lib places used, only one ~/.local/vivaldi/lib/ for all Vivaldi versions.
@smartptr again: Not having Vivaldi issues after deleting/renaming
libffmpeg.sois proof a external variant is loaded.
So far you (only) messed with the default/fallback version.
LD_PRELOADwas not set, VLC would have no problems.
But Vivaldi would no longer find a required library.
@smartptr Thanks for pointing to such issue. Can you please report this to our Linux Vivaldi devs so they may investigate?
Please read How to Report a bug for Vivaldi carefully and then report the bug to Vivaldi bugtracker.
@becm Please do so, it is appreciated for us internal testers and the devs to get as many information as you provide.
You know you can report fist and then reply to the received mail from bugtracker to add attached fiels or logs?
Reported as VB-40870: LD_PRELOAD breaks 3rd party program invocations
Added suggestion for upstream fix (unlikely) or mitigation.
Since the (current) chrome has no
LD_PRELOADin its start script this seems to be Vivaldi-specific.
Something filtered out mail content containing
<>for my example to reproduce.
Hope the original still has it or the intention can still be deducted…
Or included link to this topic is sufficient (similar to 2nd post).
@gwen-dragon I seem to recall this problem was already discussed somewhere in the forum.
But I'm unable to find anyting at the moment…
Thank you all for the support in reporting the issue!
Just for a note, it turned out that the vivaldi-snapshot script found /usr/lib/chromium-browser/libffmpeg.so and so the browser was working fine.
@smartptr Yes, this is one of the Vivaldi search paths for the libffmpüeg.