@john-53 Long story short....It was just a matter of updating the script that i use to install the plugin (libffmpeg) that I precompiled. Once I updated that script and installed 96.0.4664.110 -- the crashes stopped.

@tito69 Might be related to hardware acceleration.

opera://settings/system and disable hardware acceleration
https://forums.opera.com/topic/35298/solved-color-problem-in-opera-browser

It also looks to me like color/hue is being inverted on per-color basis (which could be directly linked to hardware acceleration and/or color controls, etc).
Eg. Red color is inverted to something more like cyan.

@leocg said in Menus with black borders:

@spikespiegel Appears as fixed in Opera 79 changelog:

DNA-94506 [Linux] Menu border has a thick black edge with hardware acceleration on

@leocg Seems so in 79.0.4128.0.

https://forums.opera.com/topic/50097/opera-dev-79-news/4

New build for Mac and Windows - 79.0.4128.0 ;-)

Some changes, fixes and improvements:
- DNA-94506 [Linux] menu border has a thick black edge with hardware acceleration on.

I'm on Linux at 78.0.4093.147.
I guess I'll just need to wait for for 79.0.4128.0 to hit stable.
And/or turn off accleration for the time being.

@A Former User said in Menus with black borders:

Re: Menus with black borders

Ubuntu 20.04 Gnome
Opera 78.0.4093.112

After the update, there are also stripes. However, if you turn off hardware acceleration, the stripes disappear.
Bug

I'm not sure what you mean by stripes.

If you are talking about the horizontal lines in the menu, those are not part of the bug -- they are menu item separators. They are there even if hardware acceleration is turned of (well at least for me anyway) .

@john-53

It looks like the github project (https://github.com/Ld-Hagen/fix-opera-linux-ffmpeg-widevine/) provides pre-built binaries (that the project has compiled directly from the chromium src).

Using pre-built binaries will be hit-and-miss due to required depedencies or a version of libc that is not installed or not available.

I actually build the library from the chromium src (on one Debian/Buster system it works, but on another one it crashes).

When the page crashes (on that one system) reinstalling opera (and using the shipped version of libffmpeg) the crash does not happen.

So, while it works for some -- it will not work for all (since it will depend largely on the individual system).

@somegeiser said in Get "Access Denied" going to some websites - Like Home Depot:

Access Denied
You don't have permission to access "http://www.homedepot.com/b/Outdoors-Outdoor-Cooking-Grill-Replacement-Parts-Grill-Grates/N-5yc1vZbxde" on this server.
Reference #18.20a9645f.1564065244.47ff7a7

Why is this happening? Is it because I am using VPN?

I got an 'access denied' message with vpn enabled only if the location was set to Europe -- this is probably an issue with the GDPR (or just a server misconfiguration). (it works fine if the location is set to something other than Europe)

@john-53 Long story short....It was just a matter of updating the script that i use to install the plugin (libffmpeg) that I precompiled. Once I updated that script and installed 96.0.4664.110 -- the crashes stopped.

@john-53

It looks like the github project (https://github.com/Ld-Hagen/fix-opera-linux-ffmpeg-widevine/) provides pre-built binaries (that the project has compiled directly from the chromium src).

Using pre-built binaries will be hit-and-miss due to required depedencies or a version of libc that is not installed or not available.

I actually build the library from the chromium src (on one Debian/Buster system it works, but on another one it crashes).

When the page crashes (on that one system) reinstalling opera (and using the shipped version of libffmpeg) the crash does not happen.

So, while it works for some -- it will not work for all (since it will depend largely on the individual system).

@tito69 Might be related to hardware acceleration.

opera://settings/system and disable hardware acceleration
https://forums.opera.com/topic/35298/solved-color-problem-in-opera-browser

It also looks to me like color/hue is being inverted on per-color basis (which could be directly linked to hardware acceleration and/or color controls, etc).
Eg. Red color is inverted to something more like cyan.

@dejwid Yup I can confirm that this works [Debian 10/Buster] (opera --use-gl=desktop), no black borders and hardware acceleration still works.

It looks like (after viewing opera://gpu/) that --use-gl=desktop disables Google ANGLE and uses the system version of GL.

Diff of opera://gpu (between default and --use-gl=desktop):

-Passthrough Command Decoder	true

+Passthrough Command Decoder	false

-GL_VENDOR	Google Inc. (NVIDIA Corporation)
-GL_RENDERER	ANGLE (NVIDIA Corporation, GeForce GTX 550 Ti/PCIe/SSE2, OpenGL 4.5.0 NVIDIA 390.143)
-GL_VERSION	OpenGL ES 2.0.0 (ANGLE 2.1.0 git hash: unknown hash)

+GL_VENDOR	NVIDIA Corporation
+GL_RENDERER	GeForce GTX 550 Ti/PCIe/SSE2
+GL_VERSION	4.5.0 NVIDIA 390.143
 	
-Window system binding vendor	Google Inc. (NVIDIA Corporation)
-Window system binding version	1.5 (ANGLE 2.1.0 git hash: unknown hash)

+Window system binding vendor	NVIDIA Corporation
+Window system binding version	1.4

@A Former User said in Menus with black borders:

Re: Menus with black borders

Ubuntu 20.04 Gnome
Opera 78.0.4093.112

After the update, there are also stripes. However, if you turn off hardware acceleration, the stripes disappear.
Bug

I'm not sure what you mean by stripes.

If you are talking about the horizontal lines in the menu, those are not part of the bug -- they are menu item separators. They are there even if hardware acceleration is turned of (well at least for me anyway) .

@leocg said in Menus with black borders:

@spikespiegel Appears as fixed in Opera 79 changelog:

DNA-94506 [Linux] Menu border has a thick black edge with hardware acceleration on

@leocg Seems so in 79.0.4128.0.

https://forums.opera.com/topic/50097/opera-dev-79-news/4

New build for Mac and Windows - 79.0.4128.0 ;-)

Some changes, fixes and improvements:
- DNA-94506 [Linux] menu border has a thick black edge with hardware acceleration on.

I'm on Linux at 78.0.4093.147.
I guess I'll just need to wait for for 79.0.4128.0 to hit stable.
And/or turn off accleration for the time being.

@somegeiser said in Get "Access Denied" going to some websites - Like Home Depot:

Access Denied
You don't have permission to access "http://www.homedepot.com/b/Outdoors-Outdoor-Cooking-Grill-Replacement-Parts-Grill-Grates/N-5yc1vZbxde" on this server.
Reference #18.20a9645f.1564065244.47ff7a7

Why is this happening? Is it because I am using VPN?

I got an 'access denied' message with vpn enabled only if the location was set to Europe -- this is probably an issue with the GDPR (or just a server misconfiguration). (it works fine if the location is set to something other than Europe)

@neoh4x0r said in Videos in HTML5 will not work:

A second, but more complicated option, is to directly build libffmpeg from the chromium-browser source -- which is exactly what every packager of chromium-codecs-ffmpeg-extra does.

(the latter is what I do -- compile from source; only because I was having issues finding the extract version of chromium-codecs-ffmpeg-extra (depending on the version I might find it or not).

Like I was saying compiling libffmpeg is not easily done as it requires checking out the entire code-based for chromium browser and then checking out the specific revision -- tied to the tagged version that is needed.

Also even before checkout, there is a complicated dance needed to be done to run the depot_tools gclient (which is a custom client used to stage and build the source).

Yes, telling people just to use a different browser is an option, but for people who are largely tied to the browser that they use....that isn't really an actual option for them.

And, so since opera does not ship a proper libffmpeg.so (it is built based on chromium, the target can be changed to a chrome build). The chromium target lacks support for certain codec, but chaning the target to chrome exposes all of the extra codecs (changing the target is as simple as editing a single file and replacing a string).

in third_party/ffmpeg/ffmpeg_options.gni :
change ffmpeg_branding = _default_ffmpeg_branding
to ffmpeg_branding = "Chrome"

It means that every user who is not running Ubuntu will have to resort to some out-of-band/out-of-channel process or procedure to get proper libffmpeg support in opera (meaning taking pre-build packages and extacting the plugin, or building from source, etc -- it just the way things are.

The might even be Google trying to force people to use chrome -- since the only official build that supports the codec is a "chrome" branded build.

@jimunderscorep said in Videos in HTML5 will not work:

If you are on ubuntu (or derivative distro, (e.g. mint, kde neon, k/u/lubuntu etc), why don't you just install chromium ffmpeg codecs extra?

@jimunderscorep said in opera beta 51.0.2830.23 linux debian x64 problem with display films into faceboobk tweeter etc (adobe flash player):

Expert's advice on the above
From time to time, someone will post a "solution" to the libffmpeg problem. This will either be "install this ubuntu's chromium ffmpeg codecs package by hand to get the... precious html5 support" or "get that tar,gz from herecura's repo, untar it and move libffmpeg to the right place to make it work".
Both are wrong because they refer to packages built for a different distro (ubuntu in the first case, arch in the second), and definitely built with a different set of libraries and compilers. Do not do that unless you want to break your system or browser.

I looked at the post in your signature....

If someone is on debian and they extract libffmpeg.so from the ubuntu package: chromium-codecs-ffmpeg-extra

They won't break their browser (assuming that they grab a compatible version) and they won't break their system.

Ubuntu uses the same libraries and compilers that Debian does (since it based on debian).

Furthermore, the way that the source for libffmpeg is written (with standard inferfaces: libav, etc) means that code compiled for one system will work on other systems that are also use the same libraries, etc.

(In other words, something compiled on a derivative system can be used on the parent system, provided that the compiled code only relies on code from the parent system).

A second, but more complicated option, is to directly build libffmpeg from the chromium-browser source -- which is exactly what every packager of chromium-codecs-ffmpeg-extra does.

(the latter is what I do -- compile from source; only because I was having issues finding the extract version of chromium-codecs-ffmpeg-extra (depending on the version I might find it or not).

@mayune
You will have to download the version of chromium-codecs-ffmpeg-extra that matches the version of chrome that opera uses -- this can be seen in your user-agent or on the 'Help->About Opera' page

I'm running Opera 62.0.3331.99 and on the help page the version of chrome is: Chrome/75.0.3770.100

The only matching version at the following url is: 75.0.3770.90 (make sure to match the arch: amd64, arm64, armhf, i3866)

https://launchpad.net/ubuntu/disco/+package/chromium-codecs-ffmpeg-extra

Once you click on the appropdate version and arch -- you will be taken to a page where you can download the .deb file: listed under Downloadable files -- note that you do not need the chromium-browser file, only the one for chromium-codecs-ffmpeg-extra.

After you have downloaded the .deb file you will need to open it in an archive manager that supports deb files -- the goal is to extract libffmpeg.so.

You would then copy that file into your opera installation's path (this where the opera binary is located).

To get the binary path for opera run this command in a terminal
readlink -f $(which opera)
/usr/lib/x86_64-linux-gnu/opera/opera

copy libffmpeg.so into /usr/lib/x86_64-linux-gnu/opera/

** depending on your arch and system that path could be different