Janky performance on background-video at top of Wired article on Crispr / DNA Editing, if you don't have H.264 video support, due to 1st fallback being a 4K ogv file

RESOLVED WONTFIX

Status

P3
normal
RESOLVED WONTFIX
3 years ago
26 days ago

People

(Reporter: dholbert, Unassigned)

Tracking

Trunk

Firefox Tracking Flags

(firefox42 affected)

Details

(Whiteboard: [country-us] [video] [sitewait], URL)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
STR:
 1. Load http://www.wired.com/2015/07/crispr-dna-editing-2/
 2. Hit the "x" on the video popup that appears.
 2. Watch the eyeball animation that plays in the background of the page.

ACTUAL RESULTS: The animation is extremely janky.
EXPECTED RESULTS: Smooth animation.

(It's smooth in Chrome 45, for comparison)

I'm using Firefox Nightly 42.0a1 (2015-07-29)

Profile, with e10s enabled:
http://people.mozilla.org/~bgirard/cleopatra/#report=500178e3c1899156e21d061c4044619fd8880abc

Profile with e10s disabled:
http://people.mozilla.org/~bgirard/cleopatra/#report=2c276f7736f9ea9b9395749c8598368968fbf073

(Both have janky animation.)

Not sure where this belongs. Starting it out in Graphics.  (I don't immediately understand the profile -- it looks like we're spending most of our time in __poll...?)
(Reporter)

Comment 1

3 years ago
BenWa, can you make any sense of these profiles?
Flags: needinfo?(bgirard)
Summary: Janky performance on animation at top of Wired → Janky performance on animation at top of Wired article on Crispr / DNA Editing
Looks like your compositor bound. We might be overwhelming X/Window Server with too much work. Can you turn on layers.dump and grab the stdout output and paste it here? Let's see if the layer tree is sane.
Flags: needinfo?(bgirard) → needinfo?(dholbert)
Actually first you should try forcing GL layers first?

Looks like we have a large video frames that we're converting from YCbCr -> RGB then drawing with XRender. It's a bad path for video but it shouldn't really be -that- slow. But I'm not too familiar with Linux perf.
(Reporter)

Comment 4

3 years ago
(In reply to Benoit Girard (:BenWa) from comment #3)
> Actually first you should try forcing GL layers first?

Not sure how to do that. But I just noticed I get smooth performance in Firefox 39 (current release), so I'll give mozregression a shot as a first diagnosis step here.
Keywords: regression
(Reporter)

Comment 5

3 years ago
Just kidding -- this isn't actually a regression. (Not from Firefox release, at least.)

Rather, in comment 4, I'm seeing a difference between Ubuntu-packaged Firefox (which includes "--enable-gstreamer=1.0", which provides e.g. native H.264 support) vs. Mozilla-provided Firefox (which does not use that build flag).

(So: Ubuntu-provided Firefox 39 (at /usr/bin/firefox ) is nice and smooth on this Wired article's background video up top. But official Mozilla Firefox 39 is janky.)
Keywords: regression
(Reporter)

Comment 6

3 years ago
(In reply to Benoit Girard (:BenWa) from comment #3)
> Actually first you should try forcing GL layers first?

(Sorry for going quiet here; this dropped in my priority queue after I realized in comment 5 that it isn't really a regression.)

How do I force GL layers?
Flags: needinfo?(bgirard)
On nightly now I believe it's just a matter of setting 'layers.acceleration.force-enabled;true'. Double check about:support to make sure it worked.
Flags: needinfo?(bgirard)
(Reporter)

Comment 8

3 years ago
I set layers.acceleration.force-enabled to true, restarted firefox, and verified that the pref showed up on about:support under "important modified preferences". (and it also showed "GPU Accelerated Windows	1/1 OpenGL (OMTC)")

Bug still reproduces.

I'll try comment 2 now.
(Reporter)

Comment 9

3 years ago
Created attachment 8649497 [details]
layers.dump stdout output (navigating from about:blank to Wired article & letting janky animation play for a little while)
Flags: needinfo?(dholbert)
(Reporter)

Comment 10

3 years ago
Layers (In reply to Benoit Girard (:BenWa) from comment #2)
> Can you turn on layers.dump and grab the stdout output
> and paste it here? Let's see if the layer tree is sane.

Output attached.

When the animation/video is playing (jankily), the logging settles into a repeated section with 5 back-to-back "ShmemTextureHost" lines per animation frame, or something.
(Reporter)

Comment 11

3 years ago
OK, so I found the video sources in the page's HTML:
> <video class='render-layer hide-mob hide-ipad hide-sm hide-med' data-js='parallaxTarget' autoplay loop >
> <source src='http://www.wired.com/wp-content/uploads/2015/07/EYES_003.mp4-1.mp4' type='video/mp4'>
> <source src='http://www.wired.com/wp-content/uploads/2015/07/EYES_003.oggtheora.ogv' type='video/ogg'>
> <source src='http://www.wired.com/wp-content/uploads/2015/07/EYES_003.webmhd.webm' type='video/webm'>

My Nightly can't handle the mp4 version, so it fails over to the ogv version.

And if I load the ogv version directly (visit http://www.wired.com/wp-content/uploads/2015/07/EYES_003.oggtheora.ogv ) it's super-janky.  In contrast, the webm version is fine.
(Reporter)

Updated

3 years ago
Summary: Janky performance on animation at top of Wired article on Crispr / DNA Editing → Janky performance when playing ogv video (used at top of Wired article on Crispr / DNA Editing)
(Reporter)

Comment 12

3 years ago
vlc and totem each crash when they try to play the ogv file, too.

I think this ogv file is just pathological. I'll reach out to Wired on Twitter and see if they can at least change the fallback order here (to prefer webm over ogv).
(Reporter)

Updated

3 years ago
Component: Graphics → Desktop
Product: Core → Tech Evangelism
Summary: Janky performance when playing ogv video (used at top of Wired article on Crispr / DNA Editing) → Janky performance on Wired article on Crispr / DNA Editing, if you don't have H.264 video support, due to 1st fallback being a 4K ogv file
You've got several image host that are 4k x 2k in size. This is probably coming from http://www.wired.com/wp-content/uploads/2015/07/EYES_003.oggtheora.ogv

For some reason the ogv is 4k but the mp4 is 1080p. The ogv looks terrible when played back in VLC. It looks like a resolution much much smaller than 1080p and it's running at about 5 FPS.

Might be interesting to see if we're just bad at 4k ogv or if it's this particular encoding that's bad.
(Reporter)

Comment 14

3 years ago
BenWa discovered that the ogv file is 4K resolution, while the mp4 and webm files are 1080.

Reclassified bug as Tech Evangelism. My request to Wired (if a Wired webdev reads this comment) is:
 (1) Please adjust http://www.wired.com/2015/07/crispr-dna-editing-2/ to swap the order of the ogv & webm source tags. (WebM is more modern than ogv, so seems reasonable to prefer it.)
...and/or:
 (2) Please adjust the ogv video to be lower resolution like the webm and mp4 videos.

(Also, for the record -- this bug affects Opera 12.16 [Presto-based, before they switched to Blink] as well, on my system. So it's not just Gecko having trouble with the ogv video here. [and vlc/totem linux video players also completely fall over, per comment 12.])
(Reporter)

Comment 15

3 years ago
contacttwitter
(Reached out over Twitter: https://twitter.com/CodingExon/status/633742282139697152 )
(Reporter)

Comment 16

3 years ago
contactemail
(Reached out over email to their wiredlabs email address, too.)
(Reporter)

Comment 17

3 years ago
(In reply to Daniel Holbert [:dholbert] from comment #14)
> (Also, for the record -- this bug affects Opera 12.16 [Presto-based, before
> they switched to Blink] as well, on my system. So it's not just Gecko having
> trouble with the ogv video here. [and vlc/totem linux video players also
> completely fall over, per comment 12.])

One more "not just us" data-point here -- if I force Chrome to render the OGV version of the video, by directly loading this data URI...
data:text/html,<video src="http://www.wired.com/wp-content/uploads/2015/07/EYES_003.oggtheora.ogv" autoplay loop width="400">
...it plays just as jankily as Firefox does (on my Linux machine).

Updated

3 years ago
Whiteboard: [country-us] [video] [sitewait]
(Reporter)

Updated

3 years ago
Summary: Janky performance on Wired article on Crispr / DNA Editing, if you don't have H.264 video support, due to 1st fallback being a 4K ogv file → Janky performance on background-video at top of Wired article on Crispr / DNA Editing, if you don't have H.264 video support, due to 1st fallback being a 4K ogv file
Daniel, I don't experience any jank with the eyeballs anymore -- can you verify?
Flags: needinfo?(dholbert)
(Reporter)

Comment 19

6 months ago
I don't experience jank on the actual Wired article, BUT that's because my current machine supports H.264 (mp4) video, and that's the video that is loading for me (which I verified using View Page Info).

The data URI from comment 17 is still super-janky -- and if I look at the DOM of the Wired article, I can see that that janky OGV version is still listed as the first fallback.  So, users with no H.264 support will still get super-janky behavior.  (See comment 11.)

Having said that: probably only a small fraction of our user-base are missing H.264 support these days, and this particular article is probably not getting a lot of hits these days either, so maybe it's not worth investing much time in outreach here.
Flags: needinfo?(dholbert)
The eyeball video is no longer displayed on Chrome 67, Canary or Opera 54.
It is working however on Firefox Nightly 63, Microsoft Edge and Safari.
Status: NEW → RESOLVED
Last Resolved: 26 days ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.