Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 580990 - www-client/vivaldi - some HTML5 videos do not play
Summary: www-client/vivaldi - some HTML5 videos do not play
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Jeroen Roovers (RETIRED)
URL: https://gist.github.com/ruario/bec42d...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-23 23:57 UTC by Markus S-D
Modified: 2018-05-14 21:28 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
ebuild adding an additional use-flag to substitute vivaldi's libffmpeg.so (vivaldi-1.1.453.36_p1.ebuild,2.91 KB, text/plain)
2016-04-23 23:57 UTC, Markus S-D
Details
my emerge --info (emerge.info,16.76 KB, text/plain)
2017-07-25 00:14 UTC, Peter Große
Details
Example patch against vivaldi (0001-www-client-vivaldi-Add-system-ffmpeg-via-USE-flag-fe.patch,1.72 KB, patch)
2017-08-27 19:48 UTC, James Le Cuirot
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Markus S-D 2016-04-23 23:57:35 UTC
Created attachment 431746 [details]
ebuild adding an additional use-flag to substitute vivaldi's libffmpeg.so

Since switching to Vivaldi as my default browser, I have been annoyed, that a large number of HTML5 videos didn't play in Vivaldi (e.g. videos on www.tagesschau.de).

A thread on the vivaldi.net forums https://vivaldi.net/en-US/forum/vivaldi-browser-for-linux/8382-several-sites-dont-play-video deals with this problem, and it seems, that Vivaldi ships a libffmpeg.so which lacks some video codecs (I guess they remove those codecs that are 'difficult' in terms of licence/patent protection, so I would not expect upstream to fix this in near future). So this issue could be patched by replacing Vivaldi's libffmpeg.

The maintainer of the vivaldi package in Arch Linux goes the way of building a more complete libffmpeg.so from the sources of the corresponding chromium version, providing a package vivaldi-snapshot-ffmpeg-codecs, see https://aur.archlinux.org/packages/vivaldi-snapshot-ffmpeg-codecs/

My suggestion is to do the same in Gentoo,
* either by adding such a separate ebuild for a chromium-libffmpeg and a use-flag system-libffmpeg to vivaldi, which replaces /opt/vivaldi-snapshot/lib/libffmpeg.so with a symlink to our own version (probably the cleaner approach, so more complex),
* or adding a use-flag archffmpeg (find a better name...) to vivaldi, which fetches the binary package for vivaldi-snapshot-ffmpeg-codecs from Arch Linux and copies it over the vivaldi's version of the file.

The second solution is implemented in the attached ebuild. I'm not experienced in writing ebuilds, so there are probably thing that could be done better. But it works for me, and since using it, I did not stumble upon a non-working video.
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2016-04-28 08:25:11 UTC
Comment on attachment 431746 [details]
ebuild adding an additional use-flag to substitute vivaldi's libffmpeg.so

ARCHFFMPEG_BASE_URI="http://repo.herecura.eu/pool/vivaldi-snapshot-ffmpeg-codecs-${CHROMIUM_VERSION}"

I have no idea what that is and why it's better than what Vivaldi provides.
Comment 2 Adrien D 2016-10-18 18:38:34 UTC
Up !
I have the same problem.

=www-client/vivaldi-1.4.589.29_p1

There are /opt/vivaldi/lib/libffmpeg.so file but some video don't play.
Comment 3 James Le Cuirot gentoo-dev 2016-11-16 21:53:44 UTC
Vivaldi is my main browser so I've looked into this. There's a few options.

The link jer posted mentions building from source, which would be ideal except that you would need to download the entire Chromium tarball, which currently stands at 488MB.

There are also binaries from other distros but this is less than ideal and may not always work.

I build Chromium from source anyway so I was hoping to borrow the libffmpeg.so from that. I didn't find it and I figured this was because system-ffmpeg is enabled by default. Disabling it didn't make any difference though. Unlike Chromium on Fedora 24, this one has it statically linked. I then read about a -Dffmpeg_component=shared_library option that you pass to gyp but that didn't help either! Perhaps that is old advice.

Even if I can get the above to work, we wouldn't want to make Chromium a dependency by default. It would need to sit behind a flag.
Comment 4 Le Baron d'Merde 2016-11-17 14:42:01 UTC
This is also a problem to Opera, what need to have the same libffmpeg.so from Chromium installed on /usr/lib/opera/lib_extra.

I am getting it from an Arch Linux third party repository what is built from an AUR PKGBUILD, I do not have Chromium installed:

http://repo.herecura.be/herecura/x86_64/

What I mean, maybe could be considered to add a binary package to install the desired libffmpeg.so on the right place, for Vivaldi and Opera.

Thanks!
Comment 5 14122002 2017-02-06 07:55:24 UTC
Up !
I have the same problem.

media-video/ffmpeg not installed (I use libav).
Please, add system-libffmpeg use flag.
Comment 6 James Le Cuirot gentoo-dev 2017-02-06 08:08:29 UTC
(In reply to 14122002 from comment #5)
> media-video/ffmpeg not installed (I use libav).
> Please, add system-libffmpeg use flag.

It's not that simple.
Comment 7 James Le Cuirot gentoo-dev 2017-07-16 17:53:35 UTC
Some good news. After some experimentation, I managed to build libffmpeg.so from chromium-60.0.3112.40 sources and it works with Vivaldi just fine. It even uses the system ffmpeg rather than the bundled version.

I did have some trouble as libffmpeg.so depends on various other Chromium components. The dependencies aren't too precise so it takes a while to build all these and I was tripping up over incompatibilities with ICU 59, even though ICU isn't even needed by libffmpeg.so.

In the end, I cheated by building it manually with g++ because it's only one C++ file and three header files. If you link with the system ffmpeg and trust that the remaining undefined references will be found later then this works. Unfortunately it still relies on some headers that are built by other components so it may not be as simple as a single call to g++. I'll see what I can do here.

It'll still mean downloading a massive tarball though we won't necessarily need to bump it that often. My current Vivaldi is based on Chromium 59 but a libffmpeg.so from Chromium 60 works. Perhaps if I can isolate precisely what is needed, we could produce a cut-down tarball but I'm not too hopeful on this point.

I'm not sure where I should install libffmpeg.so. It needs to be symlinked to various places for various browsers but there is no obvious location for the real file. I don't think it should go directly under /usr/lib.
Comment 8 Adrien D 2017-07-16 17:56:12 UTC
When i pick the libffmpeg.so from ubuntu archive, i put it into /opt/vivaldi/libffmpeg.so
Comment 9 James Le Cuirot gentoo-dev 2017-07-19 12:46:36 UTC
Update! Some good news and bad news.

The good news is that the generated headers are very short and just contain the flags that are normally used to configure the build. I wrote a script to create these headers and combine them with gcc's -MM option to produce a new tarball of just... 180KB! A vast improvement, I'm sure you'll agree.

The bad news is that I found that while BBC News videos work, Steam videos cause the tab to crash. I haven't been able to get much information about the crash but I'm guessing it's because Vivaldi was not built to use the system ffmpeg and/or the version of ffmpeg is incompatible. I will try using the bundled version instead. Arch has a package that does just this so if it works for them, it should work for us.

phajdan-jr has suggested I contact upstream to ask why their ffmpeg doesn't support more codecs. I was more under the impression that it just didn't work under Gentoo. I'll see what I can find out. He also suggested that we build Vivaldi from source. If that's even possible, I doubt I have the time to maintain such a beast.
Comment 10 James Le Cuirot gentoo-dev 2017-07-24 22:34:39 UTC
More news of the good variety!

Turns out I was slightly off the mark before. Official instructions tell you to build the media/ffmpeg target but it turns out that libffmpeg.so really is just the main ffmpeg libraries combined. There are no additional sources involved at all. The only reason the system libraries are incompatible is because Chromium-based browsers are usually built with -DFF_API_CONVERGENCE_DURATION=0, which breaks the ABI.

I decided to leverage our existing ffmpeg package to build an additional copy with the above macro defined. This involved relatively few changes and the result works a charm under vivaldi, vivaldi-snapshot, opera, opera-beta, and opera-developer. I'm now running it by other devs. Check it out if you like.

https://github.com/chewi/gentoo/commit/134b2300f418f24eb752bdd64b3bf34a586ad350
Comment 11 Peter Große 2017-07-25 00:13:18 UTC
Cool!

I tried using your patch, but the linker is not happy:

/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libavcodec/libavcodec.a(012v.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libavcodec/libavcodec.a(4xm.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libavcodec/libavcodec.a(8bps.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libavcodec/libavcodec.a(8svx.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libavcodec/libavcodec.a(a64multienc.o): relocation R_X86_64_32S against `.bss' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libavcodec/libavcodec.a(aac_adtstoasc_bsf.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libavcodec/libavcodec.a(aac_parser.o): relocation R_X86_64_32S against symbol `ff_mpeg4audio_channels' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libavcodec/libavcodec.a(aacadtsdec.o): relocation R_X86_64_32S against symbol `avpriv_mpeg4audio_sample_rates' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libavcodec/libavcodec.a(aaccoder.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libavcodec/libavcodec.a(aacdec.o): relocation R_X86_64_32 against undefined symbol `ff_aac_kbd_long_1024' can not be used when making a shared object; recompile with -fPIC

...

/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libavutil/libavutil.a(xtea.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(audioconvert.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(dither.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(options.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(rematrix.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(resample.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(resample_dsp.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(swresample.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(swresample_frame.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(audio_convert.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(audio_convert_init.o): relocation R_X86_64_32S against hidden symbol `ff_int16_to_int32_a_mmx' can not be used when making a shared object
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(rematrix.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(rematrix_init.o): relocation R_X86_64_32S against hidden symbol `ff_mix_1_1_a_int16_mmx' can not be used when making a shared object
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(resample.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libswresample/libswresample.a(resample_init.o): relocation R_X86_64_32S against hidden symbol `ff_resample_linear_int16_sse2' can not be used when making a shared object
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: libavcodec/libavcodec.a(aactab.o): warning: relocation in readonly section `.rodata'
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: *** [/var/tmp/portage/media-video/ffmpeg-3.3.2/work/ffmpeg-3.3.2/Makefile:223: libffmpeg.so] Error 1
Comment 12 Peter Große 2017-07-25 00:14:30 UTC
Created attachment 486788 [details]
my emerge --info
Comment 13 James Le Cuirot gentoo-dev 2017-07-25 07:14:28 UTC
(In reply to Peter Große from comment #11)
> I tried using your patch, but the linker is not happy:

Strange. I know that static archives are often built without -fPIC but the ffmpeg build system seems to enable it on my system anyway. Please post the full build log.
Comment 14 James Le Cuirot gentoo-dev 2017-07-25 19:50:33 UTC
(In reply to James Le Cuirot from comment #13)
> (In reply to Peter Große from comment #11)
> > I tried using your patch, but the linker is not happy:
> 
> Strange. I know that static archives are often built without -fPIC but the
> ffmpeg build system seems to enable it on my system anyway. Please post the
> full build log.

I noticed you are on stable so I tried it in my chroot and reproduced the issue. Watch this space.
Comment 15 James Le Cuirot gentoo-dev 2017-07-25 21:17:09 UTC
(In reply to James Le Cuirot from comment #14)
> (In reply to James Le Cuirot from comment #13)
> > (In reply to Peter Große from comment #11)
> > > I tried using your patch, but the linker is not happy:
> > 
> > Strange. I know that static archives are often built without -fPIC but the
> > ffmpeg build system seems to enable it on my system anyway. Please post the
> > full build log.
> 
> I noticed you are on stable so I tried it in my chroot and reproduced the
> issue. Watch this space.

Figured it out. PIC is enabled by default on the new 17.0 profile so --enable-pic is needed for the older profiles.

https://github.com/chewi/gentoo/commit/79ec55dcc4857332abf2b880be66aa965f094f6e

I am confused about the situation for x86 so I'm asking around but the above should work for amd64.
Comment 16 Peter Große 2017-08-01 17:30:55 UTC
That seems to work as a drop-in replacement. Nice work! ;)

The vivaldi start script checks 4 locations:

# Check for libs in order that they are most likely to appear.
# Where possible, use other files/directories to confirm it's the correct variant.
VIVALDI_FFMPEG_FOUND=NO
checkffmpeg "/usr/lib/$DEBARCH/oxide-qt/libffmpeg.so" '/usr/share/doc/oxideqt-codecs-extra'
checkffmpeg '/usr/lib/chromium-browser/libffmpeg.so' '/usr/share/doc/chromium-codecs-ffmpeg-extra'

# Check if the user has manually placed suitable libs.
checkffmpeg "$HOME/.local/lib/vivaldi/libffmpeg.so"
checkffmpeg "$HERE/libffmpeg.so"


I'm not sure what other browser like Opera do, but it would be cool to have them loading the new library without requiring the user to do anything.
What would be the better option? Patching the browser start scripts? Or creating the locations these scripts are looking for?
Comment 17 James Le Cuirot gentoo-dev 2017-08-01 18:34:33 UTC
I was going to add a USE flag to the browser packages and symlink from their usual locations. IIRC Opera doesn't have a wrapper script.

aballier wanted my ffmpeg changes merged upstream. I was very doubtful they would accept them but he insisted so I submitted them to the mailing list anyway. It's looking very unlikely but I'll follow up on the points they raised for what it's worth. I don't know what aballier will say now.
Comment 18 Joonas Niilola gentoo-dev 2017-08-12 12:19:50 UTC
(In reply to James Le Cuirot from comment #17)
> aballier wanted my ffmpeg changes merged upstream. I was very doubtful they
> would accept them but he insisted so I submitted them to the mailing list
> anyway. It's looking very unlikely but I'll follow up on the points they
> raised for what it's worth. I don't know what aballier will say now.

First I want to say, good work here! I was so excited to see this kind of solution, and was hoping for it to work but it doesnt for me. I made the above changes in my local overlay to ffmpeg-3.3.3 ebuild, and it builds fine and installs the file into /usr/lib64/chromium/libffmpeg.so but sadly no HTML5 or MP4 video work after the installation. I got a long error in terminal that I googled a bit and the solutions I found was to build chromium with proprietary_codecs=true and I suspect Vivaldi isnt build with this flag? So Im wondering how you got it to work. I tried with both Vivaldi-stable and Vivaldi-snapshot, but neither did work. I also tried copying the libffmpeg.so to /opt/vivaldi but no good. 

I dont have chromium or opera installed. I was hoping my ffmpeg USE flags would be wrong, but tried many things with them and nothing worked. The error I got was 

MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: open context failed"}

Am I the only one?
Comment 19 James Le Cuirot gentoo-dev 2017-08-12 13:55:04 UTC
(In reply to Joonas Niilola from comment #18)
> (In reply to James Le Cuirot from comment #17)
> > aballier wanted my ffmpeg changes merged upstream. I was very doubtful they
> > would accept them but he insisted so I submitted them to the mailing list
> > anyway. It's looking very unlikely but I'll follow up on the points they
> > raised for what it's worth. I don't know what aballier will say now.
> 
> First I want to say, good work here! I was so excited to see this kind of
> solution, and was hoping for it to work but it doesnt for me. I made the
> above changes in my local overlay to ffmpeg-3.3.3 ebuild, and it builds fine
> and installs the file into /usr/lib64/chromium/libffmpeg.so but sadly no
> HTML5 or MP4 video work after the installation. 
>
> I also tried
> copying the libffmpeg.so to /opt/vivaldi but no good. 

The correct path for it is /opt/vivaldi/lib/libffmpeg.so. If this plan goes ahead, we will add a flag to the Vivaldi packages to create a symlink.
Comment 20 Joonas Niilola gentoo-dev 2017-08-12 14:23:07 UTC
(In reply to James Le Cuirot from comment #19)
> 
> The correct path for it is /opt/vivaldi/lib/libffmpeg.so. If this plan goes
> ahead, we will add a flag to the Vivaldi packages to create a symlink.

Wow, that did it! Ive been putting the custom-build libffmpeg.so into /opt/vivaldi and it has worked, so I thought that was the path. It works now, 

libffmpeg.so -> /usr/lib64/chromium/libffmpeg.so

hope to see this get into main portage! Good job.
Comment 21 James Le Cuirot gentoo-dev 2017-08-27 08:16:00 UTC
The ffmpeg change has been merged for 9999. I will backport to 3.3.3 later today.

jer, are you okay for me to apply the changes to the vivaldi* and opera* packages? As mentioned, it will just use a system-ffmpeg flag to replace libffmpeg.so with a symlink. I don't think the unstable versions require a revbump. The flags will be masked under package.use.stable.mask initially so I'll let you decide whether I should modify the stable vivaldi-1.11.917.43_p1 in place or revbump it.
Comment 22 James Le Cuirot gentoo-dev 2017-08-27 19:48:53 UTC
Created attachment 490930 [details, diff]
Example patch against vivaldi

The backport to 3.3.3 is now pushed. Here are the changes I would make against vivaldi as an illustration.
Comment 23 James Le Cuirot gentoo-dev 2017-09-04 20:56:59 UTC
Well jer, it's been a week now and I know you've been bumping these in that time. One more week and I'll press ahead anyway.
Comment 24 Jeroen Roovers (RETIRED) gentoo-dev 2017-09-04 22:44:31 UTC
(In reply to James Le Cuirot from comment #23)
> Well jer, it's been a week now and I know you've been bumping these in that
> time. One more week and I'll press ahead anyway.

You'll do what now?
Comment 25 James Le Cuirot gentoo-dev 2017-09-05 09:01:21 UTC
(In reply to Jeroen Roovers from comment #24)
> (In reply to James Le Cuirot from comment #23)
> > Well jer, it's been a week now and I know you've been bumping these in that
> > time. One more week and I'll press ahead anyway.
> 
> You'll do what now?

As stated, I would like to apply the patch above and make similar changes to the other opera and vivaldi packages. I hope you do not consider this small and optional addition to be a problem. No other solution would have resulted in such a small change.
Comment 26 Jeroen Roovers (RETIRED) gentoo-dev 2017-09-05 21:02:00 UTC
Comment on attachment 490930 [details, diff]
Example patch against vivaldi

(In reply to James Le Cuirot from comment #25)
> (In reply to Jeroen Roovers from comment #24)
> > (In reply to James Le Cuirot from comment #23)
> > > Well jer, it's been a week now and I know you've been bumping these in that
> > > time. One more week and I'll press ahead anyway.
> > 
> > You'll do what now?
> 
> As stated, I would like to apply the patch above and make similar changes to
> the other opera and vivaldi packages.

Yes, and you want to do it last week, without waiting for proper review. So you're forcing me to do a review in your time instead of in my time, or you will dump your unreviewed changes on unsuspecting users.

So, thanks?!

> I hope you do not consider this small
> and optional addition to be a problem. No other solution would have resulted
> in such a small change.

You mean a solution that involves changing /usr/bin/vivaldi-{snapshot,stable} which already checks paths for a useable libffmpeg through a function called checkffmpeg() is a "larger" change than creating that symlink? What if that meant that you didn't even need to introduce the USE flag?

And now that you've forced me to review this, I also checked if "having more codecs" is actually a better deal. I must say that I lose the ability to control YouTube through a keyboard. Maybe your mileage varies?
Comment 27 Jeroen Roovers (RETIRED) gentoo-dev 2017-09-05 21:09:14 UTC
(In reply to Jeroen Roovers from comment #26)
> I also checked if "having more
> codecs" is actually a better deal. I must say that I lose the ability to
> control YouTube through a keyboard. Maybe your mileage varies?

Oh, never mind, that turned out to be an unrelated window manager issue.
Comment 28 Jeroen Roovers (RETIRED) gentoo-dev 2017-09-05 21:16:41 UTC
Something along these lines:

diff -u vivaldi-snapshot-1.12.947.3_p1/work/opt/vivaldi-snapshot/vivaldi-snapshot /usr/bin/vivaldi-snapshot  | colordiff
--- vivaldi-snapshot-1.12.947.3_p1/work/opt/vivaldi-snapshot/vivaldi-snapshot   2017-08-31 05:07:12.000000000 +0200
+++ /usr/bin/vivaldi-snapshot   2017-09-05 23:07:36.253200451 +0200
@@ -32,14 +32,14 @@
       # Chromium's FFMpeg version N-82746-g6bb7ea7 is the oldest known working version
       # chromium/third_party/ffmpeg/chromium/config/Chromium/linux/x64/libavutil/ffversion.h
       if [ -r "$1" ]; then
-        if [ `grep -aom1 'FFmpeg version N-[0-9]\+-' "$1" | cut -f2 -d-` -ge "82746" ]; then
+#        if [ `grep -aom1 'FFmpeg version N-[0-9]\+-' "$1" | cut -f2 -d-` -ge "82746" ]; then
           if [[ -n "$LD_PRELOAD" ]]; then
             export LD_PRELOAD="$LD_PRELOAD:$1"
           else
             export LD_PRELOAD="$1"
           fi
           export VIVALDI_FFMPEG_FOUND=YES
-        fi
+#        fi
       fi
     fi
   fi
@@ -54,6 +54,7 @@
 # Check for libs in order that they are most likely to appear.
 # Where possible, use other files/directories to confirm it's the correct variant.
 VIVALDI_FFMPEG_FOUND=NO
+checkffmpeg "/usr/lib64/chromium/libffmpeg.so"
 checkffmpeg "/usr/lib/$DEBARCH/oxide-qt/libffmpeg.so" '/usr/share/doc/oxideqt-codecs-extra'
 checkffmpeg '/usr/lib/chromium-browser/libffmpeg.so' '/usr/share/doc/chromium-codecs-ffmpeg-extra'
Comment 29 James Le Cuirot gentoo-dev 2017-09-05 21:44:58 UTC
(In reply to Jeroen Roovers from comment #26)
> Yes, and you want to do it last week, without waiting for proper review. So
> you're forcing me to do a review in your time instead of in my time, or you
> will dump your unreviewed changes on unsuspecting users.

Seeing that you'd bumped the packages during that time left me feeling somewhat ignored but I can be exceedingly busy too so sorry for my impatience.

> You mean a solution that involves changing
> /usr/bin/vivaldi-{snapshot,stable} which already checks paths for a useable
> libffmpeg through a function called checkffmpeg() is a "larger" change than
> creating that symlink? What if that meant that you didn't even need to
> introduce the USE flag?

You mean that the user would just enable the chromium flag on ffmpeg to have it picked up automatically? That's an interesting suggestion but I suspect most users would not draw a connection unless it was explicitly pointed out in a post-install message. More importantly, we need to lock down ffmpeg to a specific subslot otherwise the browser may crash or even fail to start at all due to missing symbols. If you're concerned that we may later lack the required ffmpeg version then the flag could easily be temporarily masked/dropped until this is resolved. A symlink also allows us to handle this consistently between Opera and Vivaldi as Opera does not already have such a script. /usr/bin/opera points directly to the binary IIRC.
Comment 30 Jeroen Roovers (RETIRED) gentoo-dev 2017-09-11 18:36:32 UTC
=www-client/vivaldi-1.11.917.43_p1-r1 and =www-client/vivaldi-snapshot-1.12.955.3_p1 have the launcher script patched now.
Comment 31 James Le Cuirot gentoo-dev 2017-09-11 19:06:09 UTC
(In reply to Jeroen Roovers from comment #30)
> =www-client/vivaldi-1.11.917.43_p1-r1 and
> =www-client/vivaldi-snapshot-1.12.955.3_p1 have the launcher script patched
> now.

Okay. How does that avoid the potential breakages I mentioned above?
Comment 32 Adrien D 2017-09-22 20:24:59 UTC
How can it work ?
In your patch : +checkffmpeg "/usr/lib64/chromium/libffmpeg.so"


But i don't have this file...
Comment 33 James Le Cuirot gentoo-dev 2017-09-22 20:51:04 UTC
(In reply to Adrien D from comment #32)
> How can it work ?
> In your patch : +checkffmpeg "/usr/lib64/chromium/libffmpeg.so"
> 
> 
> But i don't have this file...

You need to emerge ffmpeg with the chromium USE flag enabled. jer's solution has left users to figure this out for themselves and also left them prone to potential crashes.
Comment 34 Adrien D 2017-09-22 21:31:53 UTC
(In reply to James Le Cuirot from comment #33)
> (In reply to Adrien D from comment #32)
> > How can it work ?
> > In your patch : +checkffmpeg "/usr/lib64/chromium/libffmpeg.so"
> > 
> > 
> > But i don't have this file...
> 
> You need to emerge ffmpeg with the chromium USE flag enabled. jer's solution
> has left users to figure this out for themselves and also left them prone to
> potential crashes.

It works with chromium USE enabled.

But you mask the chromium USE for ffmpeg in /usr/portage/profiles/base/package.use.stable.mask

I must 

echo "media-video/ffmpeg -chromium" >> /etc/portage/profile/package.use.mask

to unmask you have masked
Comment 35 James Le Cuirot gentoo-dev 2017-10-21 23:29:40 UTC
(In reply to Adrien D from comment #34)
> But you mask the chromium USE for ffmpeg in
> /usr/portage/profiles/base/package.use.stable.mask
I have now unmasked this flag.

I will close this now as we basically have what we need even though it could break your browser at any time...
Comment 36 James Le Cuirot gentoo-dev 2018-05-13 11:09:32 UTC
Just wanted to let you guys know that I'm aware that this has broken again though I'm not sure whether it's due to ffmpeg or Vivaldi changing yet. I'll look into it.
Comment 37 James Le Cuirot gentoo-dev 2018-05-14 20:57:34 UTC
(In reply to James Le Cuirot from comment #36)
> Just wanted to let you guys know that I'm aware that this has broken again
> though I'm not sure whether it's due to ffmpeg or Vivaldi changing yet. I'll
> look into it.

Unfortunately I'm struggling to find the cause. The version scheme that ffmpeg reports has changed so Vivaldi just doesn't load it but this is just as well because if you force it then it crashes immediately. Looking at the Chromium sources that match my Vivaldi version and the corresponding ffmpeg fork, I cannot spot anything that might cause a crash but they patch it heavily so it's not easy. It still seems to be targeting ffmpeg 3.4, which is what I have. Any help would be appreciated.

https://chromium.googlesource.com/chromium/src/+/65.0.3325.183
https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/c33a5ee8e7b013b43e7fa9e0224857abc21564c2/
Comment 38 James Le Cuirot gentoo-dev 2018-05-14 21:28:35 UTC
Ah, my bad, I was looking at the wrong ffmpeg commit. It looks like they're using 4.0 now, which explains the crash. Not sure how easily I can upgrade at this point with 4.0 being masked.

jer, I'm still concerned that this is being enabled unconditionally and not restricting to specific ffmpeg versions. I think it was mostly luck that prevented this from crashing all the time. Users with mismatching versions will also wonder why it's not working.

https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/b64dedac9d1d70148a50791d127eede2e7eb93ba/