media-video/ffmpeg-3.3.6 www-client/vivaldi-1.14.1077.60_p1 ffmpeg's chromium USE flag makes ffmpeg install libffmpeg.so in /usr/lib64/chromium, but it is not useable or recognized by vivaldi. https://www.youtube.com/html5 says vivaldi doesn't support H.264 I tried to install http://gpo.zugaina.org/www-plugins/vivaldi-ffmpeg-codecs, but SRC_URI was broken. I copied vivaldi-ffmpeg-codecs ebuild to my local overlay and updated SRC_URI and installed www-plugins/vivaldi-ffmpeg-codecs-64.0.3282.119 Finally, https://www.youtube.com/html5 says vivaldi supports H264.
(In reply to crocket from comment #0) > media-video/ffmpeg-3.3.6 > www-client/vivaldi-1.14.1077.60_p1 > > ffmpeg's chromium USE flag makes ffmpeg install libffmpeg.so in > /usr/lib64/chromium, but it is not useable or recognized by vivaldi. Not recognised how? There is a function checkffmpeg() in /usr/bin/vivaldi that checks different locations. Which libffmpeg.so did it pick? Perhaps you can add some statements ("echo $1 $2" on the line after "export VIVALDI_FFMPEG_FOUND=YES" perhaps) that show which one it loads?
$ vivaldi-stable /usr/bin/vivaldi-stable: line 35: [: -ge: unary operator expected /usr/bin/vivaldi-stable: line 35: [: -ge: unary operator expected No suitable library for HTML5 MP4 (H.264/AAC) video and MP3 audio was found, therefore only open codecs will play. ------------------------------------------------------------------------ /opt/vivaldi/vivaldi: # Chromium's FFMpeg version N-89284-gba4dfad is the oldest known working version # chromium/third_party/ffmpeg/chromium/config/Chromium/linux/x64/libavutil/ffversion.h ------------------------------------------------------------------------ /usr/lib64/chromium/libffmpeg.so installed by ffmpeg contains a string, "FFMpeg 3.3.6". Thus, /opt/vivaldi/vivaldi's checkffmpeg can't use it. It seems I need to install http://gpo.zugaina.org/www-plugins/chromium-codecs-ffmpeg-extra or http://gpo.zugaina.org/www-plugins/vivaldi-ffmpeg-codecs
"FFMpeg 3.3.6" -> "FFMpeg version 3.3.6"
According to https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vivaldi-snapshot-ffmpeg-codecs, libffmpeg.so for vivaldi or opera has to be built from chromium, not ffmpeg.
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vivaldi-ffmpeg-codecs would be more appropraite for the current version of vivaldi on gentoo overlay.
https://gist.github.com/ruario/bec42d156d30affef655 says you will need to update vivaldi-ffmpeg-codecs from time to time as Vivaldi updates its Chromium version.
I suggest incorporating https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vivaldi-ffmpeg-codecs into vivaldi as a USE flag.
opera ignores /usr/lib64/chromium/libffmpeg.so, too.
CC: media-video@gentoo.org The startup script for vivaldi runs some checks to find a good libffmpeg: /usr/bin/vivaldi{,-snapshot}: checkffmpeg '/usr/lib64/chromium/libffmpeg.so' checkffmpeg '/usr/lib/chromium-browser/libffmpeg.so' '/usr/share/doc/chromium-codecs-ffmpeg-extra' checkffmpeg "/usr/lib/$DEBARCH/oxide-qt/libffmpeg.so" '/usr/share/doc/oxideqt-codecs-extra' checkffmpeg '/usr/lib64/chromium-ffmpeg-extra/libffmpeg.so' '/usr/share/doc/packages/chromium-ffmpeg-extra' The first entry I add through a patch, the rest have as second argument what Vivaldi developers apparently see as canonical locations for a document that describes the libffmpeg in the first argument. Perhaps the first checkffmpeg line should get a second argument as well, but what file should it point to?
Also note that the line I add causes bash to complain: /usr/bin/vivaldi: line 35: [: -ge: unary operator expected
Because `grep -aom1 'FFmpeg version N-[0-9]\+-' "$1" | cut -f2 -d-` is not in double quotes, when it is an empty string, "/usr/bin/vivaldi: line 35: [: -ge: unary operator expected" is printed on stderr. It simply means grep -aom1 'FFmpeg version N-[0-9]\+-' "$1" failed to find 'FFmpeg version N-[0-9]\+-' from an ffmpeg library. The ffmpeg library must be compiled from chromium's source code. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vivaldi-ffmpeg-codecs has instructions that build libffmpeg.so from chromium source code.
(In reply to crocket from comment #11) > Because `grep -aom1 'FFmpeg version N-[0-9]\+-' "$1" | cut -f2 -d-` is not > in double quotes, when it is an empty string, Yes yes yes. > The ffmpeg library must be compiled from chromium's source code. Like media-video/ffmpeg[chromium]? I am not sure what you're trying to add to the conversation now.
As far as I know, media-video/ffmpeg[chromium] doesn't build libffmpeg.so from chromium's source code. libffmpeg.so produced by ffmpeg's chromium USE flag is not useable by opera or vivaldi.
(In reply to crocket from comment #13) > As far as I know, media-video/ffmpeg[chromium] doesn't build libffmpeg.so > from chromium's source code. Nope, but chromium builds its libffmpeg.so from ffmpeg's sources. They do apply their own patches to it, though. > > libffmpeg.so produced by ffmpeg's chromium USE flag is not useable by opera > or vivaldi. It used to work. I guess chromium has somehow made it incompatible without their patches added. Havent studied this, but they may be portable to work with upstream ffmpeg using patches. I tried with ffmpeg-4 but it didnt work. No info about ffmpeg-9999. Maybe add chewi@gentoo.org to CC here, since he's done all the work for ffmpeg[chromium]? Also see: #654208 (chromium[system-ffmpeg] doesnt work) related to this one.
Same issue here: hard replacement of libffmpeg.so provided by Vivaldi with media-video/ffmpeg[chromium] is a no go. CC Chewi seems to be a good idea. For the record, last comment of chewi: https://gist.github.com/ruario/bec42d156d30affef655#gistcomment-2374195 http://gpo.zugaina.org/www-plugins/vivaldi-ffmpeg-codecs is not a reliable solution either as it is based on Arch Linux herecura repo which is synced with Arch Linux. For example it requires glibc 2.27 as of now (Gentoo Stable = 2.26).
I'm using "chromium-codecs-ffmpeg-extra" from Ubunutu's repositories to get H.264/MP4 working. When I get a Vivaldi update and it breaks H.264/MP4 I download the latest one, extract it and copy libffmpeg.so to /opt/vivaldi/lib/
Bah, there's so much confusion here, I wish someone had pinged me earlier. You don't need the Chromium sources. I have just pushed a fix to the ffmpeg ebuilds (v4+ only) to make it work again. It won't work out of the box yet because jer stopped patching the launcher script a while back. For now, you'll need to manually set LD_PRELOAD to the libffmpeg.so path or symlink it from /opt/vivaldi/lib/libffmpeg.so. jer, in terms of making this work in the browser, I think more caution is needed. The version check it does will never work because it's checking against the version used by Chromium (based on git commits) rather than the upstream ffmpeg version that our library has. Just commenting it out is dangerous because it'll almost certainly break when the ffmpeg subslot/soname changes. I seriously recommend adding an ffmpeg dependency like "proprietary-codecs? ( media-video/ffmpeg:0/56.58.58[chromium] )" or you'll get problems that could include videos not working without warning, browser tabs crashing, and the browser segfaulting on startup. With the dependency in place, users can choose whether they would prefer to upgrade ffmpeg now or keep the videos working. Using that approach, you can avoid patching altogether and just replace the libffmpeg.so file that gets installed with a symlink. I'm less bothered about this aspect though, I'd just like it to work while avoiding nasty breakages.
Confirm the bug. Thwe workaround is delete /opt/vivaldi-snapshot/lib/libffmpeg.so and replace it with symlink of /usr/lib64/chromium/libffmpeg.so. /opt/vivaldi-snapshot/lib/libffmpeg.so -> /usr/lib64/chromium/libffmpeg.so
Created attachment 602618 [details, diff] vivaldi-2.10.1745.23_p1-r1.ebuild.patch In order the x264 videos and others to work, Vivaldi really needs the libffmpeg.so library. We have it provided by media-video/ffmpeg[chromium] but it needs to be symlinked in a special way to the /opt/vivaldi folder. Upstream has described how: https://gist.github.com/ruario/55a6671b155fe1da35a8d8a5b2352008#providing-a-proprietary-media-enabled-libffmpegso But there is one more problem with the current ebuild - the DRM support provided by Chrome's WidevineCdm. The used in the Vivaldi ebuild binaries come with a symlink to this folder, but it is working only if the Chrome version is stable (i.e. www-client/google-chrome): /opt/google/chrome/WidevineCdm Thus DRM will not work if one uses www-plugins/chrome-binary-plugins or www-client/google-chrome-unstable or www-client/google-chrome-beta, because the symlink will be broken. I propose a fix for these problems -> a patch to the ebuild that can be used in the future versions. I have tested it with the current www-client/vivaldi-2.10.1745.23_p1 and media-video/ffmpeg-4.2.1[chromium,x264,x265] and it works fine (tested it here: https://demo.castlabs.com/ with all available videos) Caveats with the new ebuild: 1. The widevine flag is not forced by default, which means probably the user should get some info that the DRM videos will not work. 2. It is forcing the ffmpeg to have at least x264, so the codecs should work 3. It removes the two update scripts that may mess the system if run as root and that are only manually used by the user for updating Widevine and ffmpeg. I guess these changes would work for the www-client/vivaldi-snapshot also, but have not tried to fix that too.. BTW there is a bug report for older version of vivaldi about the Widevine, that you may close with this new ebuild :) : bug#647738 You may use the patch to update the current intree ebuild for vivaldi Thanks
https://demo.castlabs.com/ is a good test although it's somewhat ironic that they used Big Buck Bunny to test DRM! By chance, I already had www-client/google-chrome installed just now and DRM was working. I updated Vivaldi and it stopped working. I then manually pointed the symlink to the plugin installed by chrome-binary-plugins:stable and it worked again. Are you sure all these versions are compatible? As mentioned earlier, I think the ffmpeg subslot needs to be locked down otherwise future ffmpeg updates may cause Vivaldi to crash.
Well Widevine in the www-plugins/chrome-binary-plugins is just a folder extraction from the corresponding binary package of www-client/google-chrome[-beta,-unstable], so there is no logic your Widevine to work with www-client/google-chrome, but stop working with www-plugins/chrome-binary-plugins:stable. The only difference is the path where both reside: in /usr/lib/chromium-browser/WidevineCdm for all versions of www-plugins/chrome-binary-plugins and /opt/google/chrome/WidevineCdm for chrome stable... So it must have been your symlink in vivaldi opt folder... And yes those are one and the same Widevine for every corresponding version of Chrome. I've tested the current in portage Vivaldi ( =www-client/vivaldi-2.10.1745.23_p1) with all 6 of those (chrome itself and plugin only ebuilds) and they all work perfectly well. And as for the compatibility of the different ffmpeg versions - well according to upstream they are "CHROMIUM_VERSION roughly matching the Chromium version of Vivaldi". But maybe it is a good idea to fix it to an ffmpeg subslot - I've tested with all versions of current available 56.58.58 subslot and the versions work... The one in 55.57.57 doesn't work but I did this in a nasty test - emerging with --nodeps and there are some other libraries vivaldi uses that depend on ffmpeg, so probably the crash was because of mixing the ABI's... It's best someone to test it on a clean system that has the 55.57.57 properly installed... or just fix to the ffmpeg subslot 56.58.58 for now... Another thing is that widevine is actually useless without the libffmpeg that supports propriety codecs like x264...
Just to report that there is no problem in Vivaldi with the Widevine of the just appeared in portage Chrome unstable: www-client/google-chrome-unstable-81.0.4000.3 So I think the fix for the Widevine is safe to be implemented with no slot/subslot restrictions...
(In reply to PhobosK from comment #21) > Well Widevine in the www-plugins/chrome-binary-plugins is just a folder > extraction from the corresponding binary package of > www-client/google-chrome[-beta,-unstable], so there is no logic your > Widevine to work with www-client/google-chrome, but stop working with > www-plugins/chrome-binary-plugins:stable. You assume my www-client/google-chrome was up to date. :P But I'm willing to believe it at least works most of the time. > And as for the compatibility of the different ffmpeg versions - well > according to upstream they are "CHROMIUM_VERSION roughly matching the > Chromium version of Vivaldi". > But maybe it is a good idea to fix it to an ffmpeg subslot - I've tested > with all versions of current available 56.58.58 subslot and the versions > work... Within the same subslot should be okay. I'm not just theorising there though, I speak from experience as I'm the one who added Chromium support to the ffmpeg build and I have seen it crash.
Created attachment 602786 [details, diff] vivaldi-2.10.1745.23_p1-r1.ebuild.patch Yeah you've done a great job adding Chromium support to FFMPEG, though I found the flag a while ago... :) OK, so I do update the patch to fix it to the proper ffmpeg subslot...
Why put the symlink here? /${VIVALDI_HOME}/libffmpeg.so.$(ver_cut 1-2) It already installs /${VIVALDI_HOME}/lib/libffmpeg.so and I just replace that. It looks good other than that. I'm not confident you'll get it merged though. It's jer's package and he doesn't seem very responsive around this stuff.
(In reply to James Le Cuirot from comment #25) > Why put the symlink here? > /${VIVALDI_HOME}/libffmpeg.so.$(ver_cut 1-2) > > It already installs /${VIVALDI_HOME}/lib/libffmpeg.so and I just replace > that. Well according to upstream, we should not overwrite or replace the supplied with Vivaldi "lib/libffmpeg.so" because it will break Vivaldi (see the link I posted above: https://gist.github.com/ruario/55a6671b155fe1da35a8d8a5b2352008#providing-a-proprietary-media-enabled-libffmpegso) We should either add it to a folder named: /var/opt/vivaldi/media-codecs-$CHROMIUM_VERSION or we should put it in /opt/vivaldi/libffmpeg.so.$MAJOR.$MINOR "where $MAJOR.$MINOR represents the first and second parts of the Vivaldi version number"... This one is better handled and that is why I do symlink the libffmpeg.so from the ffmpeg[chromium] here > > It looks good other than that. I'm not confident you'll get it merged > though. It's jer's package and he doesn't seem very responsive around this > stuff. Well I do not care if it will get merged or not... It should save the maintainer of the package some time to focus on other more important bugs here, though whether he will decide to use/merge it is totally up to him, considering he should also care for the good image of Gentoo and the attribution of community... Anyway I do believe in community's role for supporting a distro or an open source package, so I fixed this ebuild for myself and shared it here with all that want a working Vivaldi... And @James, thanks again for the ideas and the chromium support of ffmpeg :) P.S. If some users need the full fixed ebuild (not just a patch to the existing one in tree), just say :) ... I can upload it too... Thanks
(In reply to PhobosK from comment #26) > (In reply to James Le Cuirot from comment #25) > > Why put the symlink here? > > /${VIVALDI_HOME}/libffmpeg.so.$(ver_cut 1-2) > > > > It already installs /${VIVALDI_HOME}/lib/libffmpeg.so and I just replace > > that. > > Well according to upstream, we should not overwrite or replace the supplied > with Vivaldi "lib/libffmpeg.so" because it will break Vivaldi (see the link > I posted above: > https://gist.github.com/ruario/55a6671b155fe1da35a8d8a5b2352008#providing-a- > proprietary-media-enabled-libffmpegso) > We should either add it to a folder named: > /var/opt/vivaldi/media-codecs-$CHROMIUM_VERSION > or we should put it in /opt/vivaldi/libffmpeg.so.$MAJOR.$MINOR "where > $MAJOR.$MINOR represents the first and second parts of the Vivaldi version > number"... This one is better handled and that is why I do symlink the > libffmpeg.so from the ffmpeg[chromium] here Oh cool, I didn't know about that. I've seen earlier versions of their instructions but I think that's relatively new.
> P.S. If some users need the full fixed ebuild (not just a patch to the > existing one in tree), just say :) ... I can upload it too... Yes please! Thanks a lot for your efforts!
Vivaldi now downloads codecs from the internet. Shall this be closed?
(In reply to crocket from comment #29) > Vivaldi now downloads codecs from the internet. Shall this be closed? That's news to me. Do you have a link with further information?
https://help.vivaldi.com/article/html5-proprietary-media-on-linux/
(In reply to crocket from comment #31) > https://help.vivaldi.com/article/html5-proprietary-media-on-linux/ I don't see anything about it downloading the codecs, unless you mean /opt/vivaldi/update-ffmpeg, which won't work on Gentoo.
(In reply to James Le Cuirot from comment #32) > (In reply to crocket from comment #31) > > https://help.vivaldi.com/article/html5-proprietary-media-on-linux/ > > I don't see anything about it downloading the codecs, unless you mean > /opt/vivaldi/update-ffmpeg, which won't work on Gentoo. Sorry, I thought from the note about deb/rpm that it wouldn't work but it extracts from the debs without any Debian tools. Even so, this is a manual step using a prebuilt binary that may not work. I prefer the approach we have.
You can still use it as a workaround until this issue is fixed.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6820eedb820d48207ddc90be02f276662401e7a1 commit 6820eedb820d48207ddc90be02f276662401e7a1 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2020-11-20 22:07:02 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2020-11-20 22:21:08 +0000 www-client/vivaldi-snapshot: Add proprietary-codecs and widevine flags This also removes the upstream "update" scripts that are most likely to just break thing. Bug: https://bugs.gentoo.org/647738 Bug: https://bugs.gentoo.org/653448 Bug: https://bugs.gentoo.org/733904 Bug: https://bugs.gentoo.org/753973 Package-Manager: Portage-3.0.9, Repoman-3.0.1 Signed-off-by: James Le Cuirot <chewi@gentoo.org> www-client/vivaldi-snapshot/metadata.xml | 4 ++++ .../vivaldi-snapshot-3.5.2110.3.ebuild | 18 ++++++++++++++++++ 2 files changed, 22 insertions(+)
Closing this as I don't use vivaldi anymore. I don't think vivaldi is important for other people.
I didn't realise this was still open. I fixed it ages ago, as the above commit shows. Also Vivaldi is very important for some people, especially me.
