Why is ffmpeg.dll included in Vivaldi path on Windows?

[Pathduck]

Probably it's included because of video playback, but still not sure why the DLL needs to be there? Is not video decoding included in Chromium?

The reason I ask is mostly curiosity, also because it's causing issues when Vivaldi launches another application (Qbittorrent) when then inherits the loaded DLLs, which again causes issues in other applications started from this.

Probably it's caused by Qbittorrent being 64-bit and Vivaldi is 32-bit. So I could solve it by upgrading to 64-bit Vivaldi I guess...

Also for instance Opera does not include the DLL. Is it there included in the opera_browser.dll ?

[lamarca]

Vivaldi is multi platform. ffmpeg executes videos em HTML5/MP3. It's proprietary media, which means Unix users have a hard time to install it with violate the copyright.
Try the 1st video of the test case below

https://www.quirksmode.org/html5/tests/video.html

Edited: As for your question, I don't know the answer

[xyzzy]

@Pathduck I've asked about this internally. I'm guessing that this is actually causing problems because Vivaldi's ffmpeg.dll would not include proprietary codecs that other programs might expect to find.

[lamarca]

@xyzzy Does it mean Win user can't play Videos In HTML5 format?

[xyzzy]

@lamarca No, just that Vivaldi uses a different library to decode proprietary media that decodes using the Windows native platform codecs. On the other hand, other external programs would not expect ffmpeg.dll to be missing an H.264 decoder.

[lamarca]

@xyzzy Please, correct me If I misread, Win comes with the built-in DLL, which is incomplete/incompatible for Vivaldi executes some file format.

Edited,

[lamarca]

@xyzzy A quick search

ffmpeg.dll file is a critical component for the 
software to work properly and without any dll error messages. 

Full article: https://www.dll4free.com/ffmpeg.dll.html

ffmpeg dll file is a critical component for the software to work properly and without any dll error messages

[QuHno]

@Pathduck Chromium (not to be mixed up with Chrome) does not include proprietary codecs like AAC or h264/265 because they are incompatible with the used open source license. Chromium uses the ffmpeg.dll to decode the rest of it because the ffmpeg.dll it is not included in Windows.

ffmpeg can be compiled with those codecs in, but that would afford paying for the those codecs if distributed in binary format, i.e. ready made for use. (Of course you you for yourself can build it for you on your own computer with codecs in)

Windows (at least in older versions before a certain W10 update) has no built in support for formats like WebM and OPUS (needed e.g. for Youtube) but comes with h264 and AAC licenses and codecs.

Vivaldi on Win and Mac uses the ffmpeg without the proprietary codecs to decode the license free stuff and for everything else it asks the OS to decode it.

You can either include the code in the executable (like some Chromium binaries do) or use a DLL for that (like some other Chromium binaries do, always depending on who compiled them and what was used as compiler).

The natural way to include stuff that is not always needed is to use a DLL - at least on Windows. Such a DLL does not interfere with other applications on its own, because it can not start on its own and it should not be found, not even be seen by any other application at all as long as it is not in the common search path or registered to them.

I don't know how qBittorrent exactly works, but as it is a an installed executable with its own path and even with the wrong architecture (64 vs 32bit in your case), it should not inherit any DLL and not search in the Vivaldi application path, but only take the data it gets from Vivaldi. If it does otherwise and runs into problems because of that, it is a bug, but no bug of Vivaldi.

Other than that, using a 64bit version of Vivaldi on a 64 bit OS is always a good idea for multiple reasons.

[Pathduck]

Thanks for your replies guys.
@QuHno Thank you especially for your very insightful answer.

Man, software patents... Those guys will be first against the wall when the revolution comes

Not the first time I've looked at DLL Hell issues on Windows, so I have the tools to deal with it fortunately.

First I suspected my issue was caused by my having added ffmpeg to the PATH, so I tried to move it out. However, with the Vivaldi ffmpeg.dll it's obvious the cause lies here.

The issue seems to be that when launching Qbittorrent (x64) from Vivaldi (x32), it becomes a child process of Vivaldi. Then when launching my player (Zoom Player x32) from there, it has the Vivaldi DLL on the path instead of the one it should use (i.e. from FFDShow):

Qbittorrent does not load the dll at all, which makes sense - why should it.

So either Vivaldi does something "wrong" when adding Qbittorent as a child process, or Zplayer should not inherit the DLL from the parents when launched.

Maybe if I change to Vivaldi x64 it would stop being an issue. Or changed to LAV instead of FFDShow for AAC in Zoom. FFDShow is getting old.

Not that it's a big one though, I can work around it. Just nice to load the video directly from the torrent client sometimes... I have contacted the ZP developer for their insight too.

[xyzzy]

@Pathduck Thanks very much for reporting this issue. The Vivaldi team is looking into it.

[becm]

@xyzzy seems to be the same problem domain (VB-40870) as encountered on ELF platforms.
Not cleaning special loader environment variables before launching external applications.

[xyzzy]

@becm Yeah, same gist. On Windows, I think that this is just a build issue. On Linux, the situation (as you know) is rather more complex.