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

Status: RESOLVED DUPLICATE of bug 1236112

(Core :: Audio/Video: Playback, defect, P1)

Description

[kostadin.markov]

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

Comment 1

[kostadin.markov]

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

Comment 2

[Loic]

Coould you test with a fresh profile, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 3

[kostadin.markov]

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...

Comment 4

[kostadin.markov]

(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.

Comment 5

[kostadin.markov]

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

[Loic]

Could you type about:support in the location bar and copy here the section "graphics".

Comment 7

[kostadin.markov]

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)

Comment 8

[kostadin.markov]

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

[Loic]

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.

Comment 10

[kostadin.markov]

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

Comment 11

[Loic]

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.

Comment 12

[Chris Peterson [:cpeterson]]

Anthony suspects this bug is related to or a duplicate of "shaky video" bug 1236112.

Comment 13

[kostadin.markov]

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 14

[kostadin.markov]

Just for clarification - since I ranged 27 - 28th of Oct, there were a couple more inbound builds. Here is what I found for them - not all are bad afterwards:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5430b2dba98b2a39ccdfd3700131f780a27be17c&tochange=393566e4fd28e3a55bb3d553b227859c0fb6ded5 - bad
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1829e3855b61178f8327bad8306961a2bdc403dc&tochange=393566e4fd28e3a55bb3d553b227859c0fb6ded5 - good
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1829e3855b61178f8327bad8306961a2bdc403dc&tochange=fbe8ec51aa386356cff2198d92a6e9bd5e8d6906 - bad
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8eb31a08c5b66fb68e949cb47857a124261fc742&tochange=fbe8ec51aa386356cff2198d92a6e9bd5e8d6906 - good

Comment 15

[Loic]

Could it be this bug?
David Anderson — Compute the compositor's damage region before composites, rather than layers updates. (bug 1217560, r=mattwoodrow)

Comment 16

[Cosmin Muntean [:cmuntean], Ecosystem QA]

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.

Comment 17

[kostadin.markov]

(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...