Fullscreen HTML 5 video goes choppy after update(FF 44)

RESOLVED DUPLICATE of bug 1236112

Status

()

Core
Audio/Video: Playback
P1
normal
RESOLVED DUPLICATE of bug 1236112
2 years ago
2 years ago

People

(Reporter: kostadin.markov, Unassigned)

Tracking

({regressionwindow-wanted})

44 Branch
x86_64
Windows 10
regressionwindow-wanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160123151951

Steps to reproduce:

Just opened a local video sharing site, then tried youtube. Any video is doing it. FF had just been updated earlier that day to ver. 44, then installed "Windows 10 cumulative update KB3124262 (Build 10586.71)", which required restarts of the two systems I have. On one of them it's the 32bit version of FF, on the other is the 64bit. Just for comparison, IE and Chrome are doing fine


Actual results:

Only fullscreen is affected. The playback goes choppy


Expected results:

Smooth playback without choppiness
(Reporter)

Updated

2 years ago
Component: Untriaged → Menus
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
(Reporter)

Updated

2 years ago
Component: Menus → Untriaged
(Reporter)

Comment 1

2 years ago
Just reverted the windows update(KB3124262) and the chopping is still present. That's the 64bit FF on 64bit Windows

Comment 2

2 years ago
Coould you test with a fresh profile, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Flags: needinfo?(kostadin.markov)
(Reporter)

Comment 3

2 years ago
Just tested - no success - the playback is still choppy.
I tried again with the 32bit installation of FF and it seems ok now. Nothing happend since yesterday - no updates no settings chnaged. I'll give it a shot(reverting back to 32bit) and report whether there's a change...
Flags: needinfo?(kostadin.markov)
(Reporter)

Updated

2 years ago
Summary: Fullscreen HTML 5 video goes choppy after windows update(FF 44) → Fullscreen HTML 5 video goes choppy after update(FF 44)
(Reporter)

Comment 4

2 years ago
(In reply to Loic from comment #2)
> Coould you test with a fresh profile, please.
> https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-
> firefox-profiles

One more thing - the two installations are localized differently: the one that's causing the problem has BG(Bulgarian locale), while the one that's ok has EN-US.
(Reporter)

Comment 5

2 years ago
Ok, moving to 32bit didn't fix it.

Any other suggestions?

PS: Sorry for not including the correct quote for the answer, but I'm a newbie with bugzilla.

Comment 6

2 years ago
Could you type about:support in the location bar and copy here the section "graphics".
(Reporter)

Comment 7

2 years ago
Here you are:

Direct2D Enabled	Blocked for your graphics card because of unresolved driver issues.
DirectWrite Enabled	false (10.0.10586.0)
GPU #2 е Active	false
Subsys ID	02291025
Vendor ID	0x8086
Device ID	0x2a42
Adapter RAM	Unknown
windowLayerManagerRemote	true
Asynchronous Pan/Zoom	none
Driver Version	8.15.10.2702
Driver Date	3-11-2013
Adapter Drivers	igdumd64 igd10umd64 igdumd32 igd10umd32
Adapter Description	Mobile Intel(R) 4 Series Express Chipset Family (Microsoft Corporation - WDDM 1.1)
Supports Hardware H264 Decoding	Yes
Рендер на WebGL	Google Inc. -- ANGLE (Mobile Intel(R) 4 Series Express Chipset Family (Microsoft Corporation - WDDM 1.1) Direct3D9Ex vs_3_0 ps_3_0)
GPU Accelerated Windows	1/1 Direct3D 11 (OMTC)
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0



My graphics would be the integrated into the chipset Intel graphics(MHD 4000 or something), which must have the necessary acceleration. The video rendering was smooth a couple of days ago. To some extent I am aware of the driver things and the blocklisting, but I only tried force enabling directwrite to improve fonts' rendering.

Note that the order of the fields is different because in my locale they appear in different order(I made efforts to translate the fields and two of the values)
(Reporter)

Comment 8

2 years ago
A little bit more info:
The chopping is like the described 'stutter' from this reddit-discussion post(https://www.reddit.com/r/firefox/comments/3zbg07/its_me_or_youtube_html5_works_poorly_on_firefox/cyncnmg):

"Firefox 43.0.3 64bit on win10 on 3 machines.

Two of the machines have problems with extream stutter ever since firefox 43 was released and none of the updates have fixed it. The stutter is of a kind where the video jumps a few frames back and then returns again.

Worse on fullscreen on these two machines. The last machine however has the problem only in fullscreen.

Been searching for a solution ever since 43 was released, and i can't find anyone with the same problem...

Tried disabeling all addons and resetting all firefox settings, with no effect."

Comment 9

2 years ago
As you are able to reproduce the issue, could you narrow down a possible regression in FF44 (or 43), please.
You can install Mozregression for that, see http://mozilla.github.io/mozregression/ (you need to install python 2.7)
After that, run mozregression --good=42 (e.g) and copy here the final pushlog from the console output.
Flags: needinfo?(kostadin.markov)
Keywords: regressionwindow-wanted

Updated

2 years ago
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
(Reporter)

Comment 10

2 years ago
Here you are(that's from the gui-version of mozregression, but I guess it should be similar) - logs from the first problematic version:
2016-01-31T21:17:55: INFO : Running mozilla-central build for 2015-10-28
2016-01-31T21:18:01: INFO : Launching c:\users\dasbo\appdata\local\temp\tmpdyounn\firefox\firefox.exe
2016-01-31T21:18:01: INFO : application_buildid: 20151028030432
2016-01-31T21:18:01: INFO : application_changeset: fc706d376f0658e560a59c3dd520437b18e8c4a4
2016-01-31T21:18:01: INFO : application_display_name: Nightly
2016-01-31T21:18:01: INFO : application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
2016-01-31T21:18:01: INFO : application_name: Firefox
2016-01-31T21:18:01: INFO : application_remotingname: firefox
2016-01-31T21:18:01: INFO : application_repository: https://hg.mozilla.org/mozilla-central
2016-01-31T21:18:01: INFO : application_vendor: Mozilla
2016-01-31T21:18:01: INFO : application_version: 44.0a1
2016-01-31T21:18:01: INFO : platform_buildid: 20151028030432
2016-01-31T21:18:01: INFO : platform_changeset: fc706d376f0658e560a59c3dd520437b18e8c4a4
2016-01-31T21:18:01: INFO : platform_repository: https://hg.mozilla.org/mozilla-central
2016-01-31T21:18:01: INFO : platform_version: 44.0a1

So, it seems that the nightly build on the 27th of October had been fine, but the following day(the 28th of October 2015), the bug got present.

Note that I needed to disable an option in the settings: "Enable multi-process Nightly", which caused excessive cpu load on my tiny system. From some date on(around the beginning of October), it felt as if the HW acceleration was off. I also noticed the process "Plugin container for Nigthly" using up to around 50% of the CPU, which lead me to disable the multi-process option
Flags: needinfo?(kostadin.markov)

Comment 11

2 years ago
You should obtain a complete pushlog, like that:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=XXXXX&tochange=YYYYYY

Using the command-line version is better (more options). You can create a custom profile with e10s disabled inside (and all the settings you want like HWA disabled) and use it with mozrregression with the command "--profile=C:/Users/Profile --profile-persistence=reuse"

Could you test again, please.
Priority: -- → P1
Anthony suspects this bug is related to or a duplicate of "shaky video" bug 1236112.
Depends on: 1236112
(Reporter)

Comment 13

2 years ago
Loic, here it is the output from the console, the first build the bug is present:
app_name: firefox
build_date: 2015-10-28 00:58:04.832000
build_file: c:\users\dasbo\appdata\local\temp\tmp_joxb3\e7929212ce5c--mozilla-inbound--firefox-44.0a1.en-US.win32.zip
build_type: inbound
build_url: https://queue.taskcluster.net/v1/task/y9TJA-8aQG60vWCpdy6oQg/runs/0/artifacts/public%2Fbuild%2Ffirefox-44.0a1.en-US.win32.zip
changeset: e7929212ce5c8ca6511ad5b425e2c821bc1aa174
pushlog_url: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5430b2dba98b2a39ccdfd3700131f780a27be17c&tochange=e7929212ce5c8ca6511ad5b425e2c821bc1aa174
repo_name: mozilla-inbound
repo_url: https://hg.mozilla.org/integration/mozilla-inbound
task_id: y9TJA-8aQG60vWCpdy6oQg

Chris, yes, I think it is the same behavior. Other bugs I browsed here also call it "frame reordering"

Comment 15

2 years ago
Could it be this bug?
David Anderson — Compute the compositor's damage region before composites, rather than layers updates. (bug 1217560, r=mattwoodrow)
No longer depends on: 1236112
See Also: → bug 1236112
Hi Kostadin,

I have tested this issue on latest Firefox (44.0.2) release, latest Nightly (47.0a1) build an I could not reproduce it. The video was played smoothly.

Firefox: 44.0.2, Build ID: 20160210153822
User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Firefox: 47.0a1, Build ID: 20160222030212
User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 

Can you please look over the bug 1236112 and tell me if that issue is similar with yours? If it is the same behavior we can mark this issue as RESOLVED - DUPLICATE.

Thanks,
Cosmin.
Flags: needinfo?(kostadin.markov)
(Reporter)

Comment 17

2 years ago
(In reply to Cosmin Muntean [:CosminMCG] from comment #16)
> Hi Kostadin,
> 
> I have tested this issue on latest Firefox (44.0.2) release, latest Nightly
> (47.0a1) build an I could not reproduce it. The video was played smoothly.
> 
> Firefox: 44.0.2, Build ID: 20160210153822
> User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101
> Firefox/44.0
> Firefox: 47.0a1, Build ID: 20160222030212
> User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101
> Firefox/47.0 
> 
> Can you please look over the bug 1236112 and tell me if that issue is
> similar with yours? If it is the same behavior we can mark this issue as
> RESOLVED - DUPLICATE.
> 
> Thanks,
> Cosmin.

Yes, I think it's the same. The latest nightly is fine(smooth again) with "Enable multi-process Nightly"-disabled. Looking forward for the fix getting official...
Flags: needinfo?(kostadin.markov)
(Reporter)

Updated

2 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1236112
You need to log in before you can comment on or make changes to this bug.