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

Status: RESOLVED WONTFIX

(Web Compatibility :: Site Reports, defect, P3)

Description

[Daniel Holbert [:dholbert]]

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

Comment 1

[Daniel Holbert [:dholbert]]

BenWa, can you make any sense of these profiles?

Comment 2

[Benoit Girard (:BenWa)]

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.

Comment 3

[Benoit Girard (:BenWa)]

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.

Comment 4

[Daniel Holbert [:dholbert]]

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

Comment 5

[Daniel Holbert [:dholbert]]

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

Comment 6

[Daniel Holbert [:dholbert]]

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

Comment 7

[Benoit Girard (:BenWa)]

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.

Comment 8

[Daniel Holbert [:dholbert]]

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.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: layers.dump stdout output (navigating from about:blank to Wired article & letting janky animation play for a little while)

Comment 10

[Daniel Holbert [:dholbert]]

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.

Comment 11

[Daniel Holbert [:dholbert]]

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.

Comment 12

[Daniel Holbert [:dholbert]]

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

Comment 13

[Benoit Girard (:BenWa)]

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.

Comment 14

[Daniel Holbert [:dholbert]]

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

Comment 15

[Daniel Holbert [:dholbert]]

(Reached out over Twitter: https://twitter.com/CodingExon/status/633742282139697152 )

Comment 16

[Daniel Holbert [:dholbert]]

(Reached out over email to their wiredlabs email address, too.)

Comment 17

[Daniel Holbert [:dholbert]]

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

Comment 18

[Mike Taylor [:miketaylr]]

Daniel, I don't experience any jank with the eyeballs anymore -- can you verify?

Comment 19

[Daniel Holbert [:dholbert]]

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.

Comment 20

[Sergiu Logigan [:sergiu]]

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.