Closed Bug 1141433 Opened 9 years ago Closed 9 years ago

HTML5 video on YouTube is not scaled and resized properly with disabled OMTC

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Version:
37 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox37 + wontfix
firefox38 + unaffected
firefox39 + unaffected
firefox40 + unaffected
firefox-esr31 --- unaffected
firefox-esr38 38+ fixed

People

(Reporter: bugs, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

screenshot.png
682.71 KB, image/png
Details
Attached image screenshot.png — 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150305191659

Steps to reproduce:

In a fresh profile, disable OMTC, then view HTML5 video with an original resolution smaller than its container.

Example (360p): https://www.youtube.com/watch?v=CH1XGdu-hzQ


Actual results:

As of Firefox 37b1, video isn't scaled.


Expected results:

Video should be scaled.
Is there a particular reason you disable OMTC?
Freezes and graphical corruption -- the same reason everyone who disables it does so -- and the needle doesn't seem to be moving on that front. In fact, during the brief time I had it enabled in 37, I was dumbfounded to find things seem to have actually gotten WORSE. I'm not exactly running an edge-case configuration here (GTX 660 Ti with the latest WHQL drivers), so, to say the least, it's puzzling that these issues persist four major versions later.
Could you attach about:support graphics section with and without OMTC on?
Adapter Description NVIDIA GeForce GTX 660 Ti
Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM 3072
ClearType Parameters  Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 400
Device ID 0x1183
Direct2D Enabled  true
DirectWrite Enabled true (6.2.9200.16571)
Driver Date 2-5-2015
Driver Version  9.18.13.4752
GPU #2 Active false
GPU Accelerated Windows 1/1 Direct3D 11 (OMTC)
Subsys ID 36633842
Vendor ID 0x10de
WebGL Renderer  Google Inc. -- ANGLE (NVIDIA GeForce GTX 660 Ti Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote  true
AzureCanvasBackend  direct2d 1.1
AzureContentBackend direct2d 1.1
AzureFallbackCanvasBackend  cairo
AzureSkiaAccelerated  0

---

Adapter Description NVIDIA GeForce GTX 660 Ti
Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM 3072
ClearType Parameters  Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 400
Device ID 0x1183
Direct2D Enabled  true
DirectWrite Enabled true (6.2.9200.16571)
Driver Date 2-5-2015
Driver Version  9.18.13.4752
GPU #2 Active false
GPU Accelerated Windows 1/1 Direct3D 10
Subsys ID 36633842
Vendor ID 0x10de
WebGL Renderer  Google Inc. -- ANGLE (NVIDIA GeForce GTX 660 Ti Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote  false
AzureCanvasBackend  direct2d
AzureContentBackend direct2d
AzureFallbackCanvasBackend  cairo
AzureSkiaAccelerated  0
Have you had a moment to look at the output?
Flags: needinfo?(milan)
The OMTC off configuration is bad news; the code to support it is actually removed from the codebase in 38.

For the freezes and corruption, is it something similar to bug 1067470, or something different?
Flags: needinfo?(milan)
Unless we can figure this out in the next few weeks, then, I STRONGLY suggest you push hard to back out those changes until at LEAST 39 so the next ESR isn't affected. For those of us having issues with OMTC, Firefox is completely unusable. With the option to at least switch to 38ESR until solutions are found, those affected are less likely to switch browsers. Since rapid release precludes security updates, sitting on 37 indefinitely isn't an option.

Bug 1067470 is definitely the freezing issue. A related issue is that tabs sometimes just take their sweet time painting when you switch to them, despite the rest of the browser being responsive. As for the graphical corruption issue, in short, graphical elements sometimes hang around when they should be gone. Example:

http://i.imgur.com/OfO7t9L.png
http://i.imgur.com/vRG3fTA.png

In the first screenshot, you see what happened after closing a document with a black background -- the black background persists in some areas (along with some sort of symbol beneath the search icon on the right side), as does a small portion of the tab that was closed. For comparison, the second screenshot shows what should've happened after closing that tab.
Thanks for this!  I know the conversation has strayed a bit from the original report, but doesn't matter, important that we get to the bottom of this.
Is this an intermittent problem, or does it happen all the time?
Do you still run into the same problems with nightly and a clean profile?
If the document doesn't have a black background, do you see black or the document background color when you close it?
Do you get the corruption in the pages themselves, or is it always in the chrome of the browser?
Flags: needinfo?(milan)
(In reply to Milan Sreckovic [:milan] from comment #8)
> Is this an intermittent problem, or does it happen all the time?

It doesn't happen 100% of the time, no. If I had to put a percentage on it, maybe 15-25%?

> Do you still run into the same problems with nightly and a clean profile?

I wasn't able to reproduce bug 1067470 during the ~20 minutes I just spent messing around in nightly (though that doesn't necessarily mean it's fixed; I've gone similar lengths of time before without it occurring), but the other two issues persist. That said, they're significantly less pronounced in a fresh profile, both in nightly and beta -- you really have to be looking for it to notice. It's entirely possible everyone has these issues, but they're just going unnoticed. If I had to guess, I'd say the more custom styling being applied, the more likely the renderer is to choke.

> If the document doesn't have a black background, do you see black or the
> document background color when you close it?

Document background. But very rarely. Usually it's just stray images or text that are erroneously overlaid.

> Do you get the corruption in the pages themselves, or is it always in the
> chrome of the browser?

Both pages and chrome.
So what are we doing to address the OMTC situation? And can I get a fix for this particular issue in the meantime?
I can confirm the issues blackwind reported.

As far as I can tell things improved over time since Fx 33 and glitches occur less frequently in Fx37 betas than they did in older Fx versions, but they still occur randomly on many different systems and configurations. There is no pattern how and when the occur, so steps to reproduce them can not be offered.

So far I've tested Firefox 36-39 with and without new profiles on Windows 7 and 8.1 using five different PCs/Laptops with different graphics cards.

It might be a good idea not to force OMTC on Fx 38 (ESR) users and still allow to disable it.
I've been testing OMTC full-time for the past couple days to see if I can live with it in its current state, and for what it's worth, I believe the freezing issue to be resolved as of Fx37. It still makes browsing a complete and total nightmare, but I guess this counts as some degree of progress.
[Tracking Requested - why for this release]: Regression
Severity: normal → major
Status: UNCONFIRMED → NEW
status-firefox37: --- → affected
status-firefox38: --- → affected
status-firefox39: --- → affected
status-firefox40: --- → affected
tracking-firefox37: --- → ?
tracking-firefox38: --- → ?
tracking-firefox39: --- → ?
tracking-firefox40: --- → ?
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
Flags: needinfo?(jmuizelaar)
Found this ticket after mine being assigning as duplicate of this which I couldn't find via search. Can confirm that I also suffer the same issues as blackwind, including the reasons for disabling OMTC. In my case there are even moments when after closing a tab, the page that was inside that tab remains visible over the other page that should be showing.

It is only a graphical issue because the cursor changes according to the elements in the page that is hidden below the "ghost" page. The only way to make the page display correctly is by making the browser refocus, like minimizing and selecting a different window outside the browser.
Summary: HTML5 video not scaling properly in Firefox 37 with OMTC off → HTML5 video on YouTube is not scaled and resized properly with disabled OMTC
I'm tracking for 38+ but there are two issues in this bug:

1. the originally reported issue about YouTube video playback with OMTC disabled
2. the need to disable OMTC

We likely need to create a separate bug for the OMTC issue and then decide about the need to solve video playback or OMTC or both and in what time frame.
tracking-firefox38: ? → +
tracking-firefox39: ? → +
tracking-firefox40: ? → +
Just to add to this - my Bug 1150309 was, correctly, marked as a duplicate of this. I had disabled OMTC some time back due to browser lockups, re-enabling OMTC fixes the YouTube issue for me and no further issues have been immediately obvious so far. But just wanted to add, have now discovered having OMTC disabled was not only breaking YouTube, but was also causing Vine videos to no longer play and caused Google maps to display upside down and back to front (both were issues I also had since the FF37 update, both solved by re-enabling OMTC).

Worth noting, the popular add-on Classic Theme Restorer offers the option of disabling OMTC within it's UI with the recommendation it be done to solve "hanging tabs". So a possible cause of a large number of users experiencing this bug, not realising what had caused it.
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #18)
> I'm tracking for 38+ but there are two issues in this bug:
> 
> 1. the originally reported issue about YouTube video playback with OMTC
> disabled
> 2. the need to disable OMTC
> 
> We likely need to create a separate bug for the OMTC issue and then decide
> about the need to solve video playback or OMTC or both and in what time
> frame.

Can't find an appropriate bug report related to this OMTC issue, search always leads me to the OMTC implementation request made in 2010. Could you link it -if there is one already and if needed- so that we can contribute with any essential hard/soft information that might help solving the issue?
"Summary: HTML5 video not scaling properly in Firefox 37 with OMTC off → HTML5 video on YouTube is not scaled and resized properly with disabled OMTC"

This issue isn't limited to YouTube. The original title was correct.
(In reply to blackwind from comment #21)
> "Summary: HTML5 video not scaling properly in Firefox 37 with OMTC off →
> HTML5 video on YouTube is not scaled and resized properly with disabled OMTC"
> 
> This issue isn't limited to YouTube. The original title was correct.

I agree, the issue occurs on any video being served via the HTML5 player.
Setting layers.offmainthreadcomposition.enabled=false and Youtube default player = HTML5.
I can reproduce on Firefox37.0.1.
However, I cannot reproduce on Firefox38.0b1 and later.
Hmmm, I have updated to 37.0.1 and can no longer reproduce the YouTube scaling issue, or the non playing of Vine vids. Google maps is still broken with OMTC disabled though
(In reply to WKDPOWER from comment #24)
> Hmmm, I have updated to 37.0.1 and can no longer reproduce the YouTube
> scaling issue, or the non playing of Vine vids. Google maps is still broken
> with OMTC disabled though

If I am not wrong, the 37 HTML5 upgrade has been rolled back with 37.0.1 and so did the issue, apparently. If you visit YouTube it no longer shows the HTML5 player by default, unless you opt in via the YouTube system.
YouTube just forced Firefox users to use Flash Player per buggy HMTL5 MSE implementation in Firefox.
This is a bug in the deprecated d3d9/10 layers code, which no longer exists as of 38 onwards.

These layers backends don't take the mScaleToSize value of ImageLayer into account, so aren't scaling the videos correctly.

Given that this only affects users with custom prefs this probably isn't worth shipping 37.0.2 for.

Encouraging users to switch back to the default config is probably a good thing, though it's possible a small set of users have good reason to not want OMTC and broken video is unfortunate.
status-firefox38: affected → unaffected
status-firefox39: affected → unaffected
status-firefox40: affected → unaffected
As I understand it, this is fixed in 38, 39, 40, and given comment 27, not likely to get done for 37.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(milan)
Resolution: --- → FIXED
I should mention - I can reproduce on 37, but it works on 38, 39, 40.
Flags: needinfo?(jmuizelaar)
Given that this is fixed in 38+ and doesn't have a simple for for 37, I think we're going to have to live with this in 37. As such, I have marked 37 as wontfix.
status-firefox37: affected → wontfix
tracking-firefox37: ? → +
This is fixed in 38+, so maybe backporting the fix for 38 ESRs is worthwhile. Tracking for ESR.
status-firefox-esr38: ? → affected
tracking-firefox-esr38: ? → 40+
Should have been marked 38+ as this was fixed in Firefox 38.
tracking-firefox-esr38: 40+ → 38+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: