Visual frame drop from an uncached video

RESOLVED FIXED in Firefox 39

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Fanolian+bugzilla, Assigned: bholley)

Tracking

({regression, reproducible})

Trunk
mozilla40
x86_64
Windows 8.1
regression, reproducible
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox38 unaffected, firefox39+ fixed, firefox40 fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150325030206

Steps to reproduce:

Last good Nightly: 2015-03-16
First bad Nightly: 2015-03-17

0. Perhaps a slow internet connection is needed, so the test url (video) is not cached instantly.
1. Load https://streamable.com/c1p8 in a new profile. Make sure the link has not been visited/cached before.


Actual results:

Video skips frames in the very first few seconds while audio plays smoothly. Subsequent replays are smooth. Reloading the page will play the video smoothly too, even for the first few seconds.

To reproduce the issue (and why I think it may be cache related):
1. Close the video tab.
2. Clear cache in Options > Advanced > Network > Cached Web Content > Clear now a few times.
3. Wait for more than 10 seconds (If not, the video will have a 80% chance of playing smoothly). Or close and reopen the browser.
4. Open a new tab and visit the video again ( https://streamable.com/c1p8 ).

Or to 100% reproduce the issue with an extension:
1. In a new profile, install Imagus (https://addons.mozilla.org/en-US/firefox/addon/imagus/versions/)
2. Visit https://www.reddit.com/r/nba/comments/3079mp/russell_westbrook_with_a_ferocious_finish_on_an/ .
3. In the reddit page, hover on the title containing the video link (Russell Westbrook with a ferocious finish on an alley-oop pass by D.J. Augustin.)
4. The first ever playback should have frame drops at the beginning.
5. Clear cache.
6. Without waiting, instantly switch back to the reddit page and hover on the link. The first playback should have frame drops again.


Expected results:

Before the bad build (2015-03-17), there is no frame drops as long as internet speed can catch up the download.

P.S.
There are more video examples without being cached before by searching streamable.com or gfycat.com in google:
https://www.google.com/search?q=site:streamable.com
https://www.google.com/search?q=site:gfycat.com

Search results, however, may contain NSFW contents.
(Reporter)

Updated

4 years ago
Keywords: regressionwindow-wanted, reproducible

Comment 1

4 years ago
I can reproduce the initial frame drop on windows7.

Steps
1. Clear cahce and restart
2. Open https://streamable.com/c1p8

Regression pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ff73dd4e2d62&tochange=08bb5eab67b7

Regressed by: Bug 1135424
Blocks: 1135424
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(bobbyholley)
Keywords: regressionwindow-wanted → regression

Comment 2

4 years ago
[Tracking Requested - why for this release]: regression
status-firefox38: --- → unaffected
status-firefox39: --- → affected
tracking-firefox39: --- → ?
(Assignee)

Comment 3

4 years ago
Thanks for the awesome regression hunting!

We were expecting that there might be stutters due to bug 1135424 (and others) when multiple videos were playing at the same time. The idea was that bug 1142336 (which landed a few days ago) should fix it. Alice, can you confirm that this issue still happens with the latest Nightly (i.e. with bug 1142336)?
Flags: needinfo?(alice0775)

Comment 4

4 years ago
(In reply to Bobby Holley (:bholley) from comment #3)
> Thanks for the awesome regression hunting!
> 
> We were expecting that there might be stutters due to bug 1135424 (and
> others) when multiple videos were playing at the same time. The idea was
> that bug 1142336 (which landed a few days ago) should fix it. Alice, can you
> confirm that this issue still happens with the latest Nightly (i.e. with bug
> 1142336)?


I can still reproduce the problem on latest Nightly39 with/without e10s.
https://hg.mozilla.org/mozilla-central/rev/6082a98d3861
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 ID:20150330030203


And of course, I cannot not reproduce the problem on Aurora38.
https://hg.mozilla.org/releases/mozilla-aurora/rev/9e57e9776571
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 ID:20150330004006


I tested with newly created profile each.
Flags: needinfo?(alice0775)
(Assignee)

Comment 5

4 years ago
This is a great bug report, thanks. Confirmed and investigating.
Assignee: nobody → bobbyholley
(Assignee)

Comment 6

4 years ago
Created attachment 8585755 [details] [diff] [review]
Part 1 - Invert the ordering of our priority queue. v1

Well this is embarassing.
Attachment #8585755 - Flags: review?(matt.woodrow)
(Assignee)

Comment 7

4 years ago
Created attachment 8585757 [details] [diff] [review]
Part 2 - Implement logging for MediaTimer. v1

Did this along the way - might as well get it into the tree.
Attachment #8585757 - Flags: review?(matt.woodrow)
(Assignee)

Comment 9

4 years ago
Comment on attachment 8585755 [details] [diff] [review]
Part 1 - Invert the ordering of our priority queue. v1

We're definitely going to want to get this into aurora after the merge.

The logging patch is also low risk and could be helpful to uplift. I'm happy either way on that one.

Approval Request Comment
[Feature/regressing bug #]: bug 1135424
[User impact if declined]: Frame skipping
[Describe test coverage new/current, TreeHerder]: I added an assertion that would catch this bug.
[Risks and why]: Very low risk. I just got a |<| backwards.
[String/UUID change made/needed]: None
Attachment #8585755 - Flags: approval-mozilla-aurora?
Attachment #8585755 - Flags: review?(matt.woodrow) → review+
Attachment #8585757 - Flags: review?(matt.woodrow) → review+
https://hg.mozilla.org/mozilla-central/rev/749de9ff2be9
https://hg.mozilla.org/mozilla-central/rev/653362b54e99
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox40: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Comment on attachment 8585755 [details] [diff] [review]
Part 1 - Invert the ordering of our priority queue. v1

Taking this for aurora uplift. Thanks for adding test coverage!
Attachment #8585755 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
tracking-firefox39: ? → +
You need to log in before you can comment on or make changes to this bug.