1156860 - Webm video freezes

Status: RESOLVED WORKSFORME

(Core :: Audio/Video, defect)

Description

[Adam Frisby]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150402191859

Steps to reproduce:

URL: http://giant.gfycat.com/DiligentMediumBangeltiger.webm


Actual results:

Video playback freezes at about 0:01, 0:03, and 0:05.

Progress bar doesn't advanced when frozen.


Expected results:

Not freeze

Application Basics
------------------

Name: Firefox
Version: 40.0a1
Build ID: 20150421030209
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0
Multiprocess Windows: 1/1 (default: true)

Crash Reports for the Last 3 Days
---------------------------------

All Crash Reports

Extensions
----------

Graphics
--------

Adapter Description: AMD Radeon R7 200 Series
Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 1024
Asynchronous Pan/Zoom: none
Device ID: 0x6613
Direct2D Enabled: true
DirectWrite Enabled: true (6.3.9600.17415)
Driver Date: 11-20-2014
Driver Version: 14.501.1003.0
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 00000000
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon R7 200 Series Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Important Modified Preferences
------------------------------

browser.cache.disk.capacity: 358400
browser.cache.disk.filesystem_reported: 1
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.cache.frecency_experiment: 4
browser.download.importedFromSqlite: true
browser.places.smartBookmarksVersion: 7
browser.sessionstore.upgradeBackup.latestBuildID: 20150421030209
browser.startup.homepage_override.buildID: 20150421030209
browser.startup.homepage_override.mstone: 40.0a1
dom.apps.reset-permissions: true
dom.mozApps.used: true
extensions.lastAppVersion: 40.0a1
gfx.direct3d.last_used_feature_level_idx: 0
media.gmp-gmpopenh264.lastUpdate: 1429371355
media.gmp-gmpopenh264.version: 1.3
media.gmp-manager.lastCheck: 1429371355
network.cookie.prefsMigrated: true
places.history.expiration.transient_current_max_pages: 104858
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
privacy.sanitize.migrateFx3Prefs: true

Important Locked Preferences
----------------------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.10.8
Version in use: 4.10.8

NSS
Expected minimum version: 3.19 Basic ECC Beta
Version in use: 3.19 Basic ECC Beta

NSSSMIME
Expected minimum version: 3.19 Basic ECC Beta
Version in use: 3.19 Basic ECC Beta

NSSSSL
Expected minimum version: 3.19 Basic ECC Beta
Version in use: 3.19 Basic ECC Beta

NSSUTIL
Expected minimum version: 3.19 Beta
Version in use: 3.19 Beta

Experimental Features
---------------------

Comment 1

[Alice0775 White]

[Tracking Requested - why for this release]: performance regression of video playback


Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=db233d1e9887&tochange=d1f3c8d40cdf


Suspect: Bug 1114840

Comment 2

[Alice0775 White]

Via local build,
Last Good: 0f80e83ac9e5
First Bad: cb7e862569a1

Triggered by: cb7e862569a1	Bobby Holley — Bug 1114840 - Don't start playback during prerolling. r=cpearce

Comment 3

[Lawrence Mandel [:lmandel] (use needinfo)]

Tracking 38+ on the assumption that bug 1114840 (fixed in 37) is the cause.

Bobby - Bug 1114830, which you fixed, is suspected. Do you have time to look into this?

Comment 4

[Bobby Holley (:bholley)]

Hm, looks like this only happens with e10s enabled. The difference is pretty stark, so hopefully it should be relatively straightforward to debug. I'll have a look.

Comment 5

[Adam Frisby]

(In reply to Bobby Holley (:bholley) from comment #4)
> Hm, looks like this only happens with e10s enabled. The difference is pretty
> stark, so hopefully it should be relatively straightforward to debug. I'll
> have a look.

Happens here with e10s on and off. This bug is present in FF 37.

Comment 6

[Alice0775 White]

Yes, this problem is reproducible regardless of e10s.

(If there is the problem of the network, download the webm file and then play the local file)

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Bobby, 38 beta 7 gtb is today. So, a patch would have to arrive soon. Thanks

Comment 8

[Bobby Holley (:bholley)]

(In reply to Sylvestre Ledru [:sylvestre] from comment #7)
> Bobby, 38 beta 7 gtb is today. So, a patch would have to arrive soon. Thanks

It is very unlikely that this will be fixed by EOD or be safe enough to land on beta 7.

Comment 9

[Bobby Holley (:bholley)]

So, this appears to be more skip-to-keyframe shenanigans. I don't think bug 1131563 fixed this properly, and there seems to be a significant lack of clarity in the code as to what we're even trying to do here. For starters, what is the meaning of aTimeThreshold, exactly? The current code seems to be trying to find a keyframe _after_ aTimeThreshold, which means that we'll end up displaying that keyframe for an arbitrary amount of time until the audio catches up.

I propose the following semantics. When the MDSM says passes skipToKeyframe=true and aTimeThreshold=aCurrentTime, the reader performs the following steps:
(1) Read in packets up to aTimeThreshold (i.e. until demuxing is up-to-date).
(2) Identify the _last_ keyframe K in the queue whose pts is <= aTimeThreshold. If no such keyframe exists, abort this algorithm.
(3) Drop all frames that come before K.

Does this make sense to everyone?

Comment 10

[Bobby Holley (:bholley)]

So, ignore comment 9 for the most part, and see bug 1158236.

The main impact on this bug here is that we're currently stuck with the suboptimal skip-to-keyframe logic, whereby we sacrifice video playback for smooth audio playback (because both are decoding on the same thread). And even though there doesn't seem to be any audible audio in this video, there _is_ an audio track, so that condition applies here. This will hopefully get better with bug 1158236.

skip-to-keyframe is a very non-deterministic realtime heuristic that gets activated when decode doesn't happen fast enough (which is to say, it's machine-dependent). My machine is very fast, so I can only reproduce the problem with e10s enabled (where it appears to be very normal skip-to-keyframe). I rewound and did builds before and after the changeset in comment 2, and wasn't able to detect a significant change.

If someone is interested in confirming that this really is skip-to-keyframe, it would be interesting to capture a log (by setting the following environmental variables: MEDIA_LOG_SAMPLES=1 NSPR_LOG_MODULES="MediaDecoder:5,Nestegg:5"), especially one with a build where it works and one where it doesn't (i.e. immediately before and after the changesets in comment 2). I can then compare the logs and see if there's anything fishy going on.

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Florin, can someone on your team try to reproduce the bug with logging setup as described in comment 10? Thanks. 

Bobby it also sounds like maybe bug 1148292 will change the situation a bit if that work lands soon.

Comment 12

[Bobby Holley (:bholley)]

(In reply to Liz Henry (:lizzard) from comment #11)
> Bobby it also sounds like maybe bug 1148292 will change the situation a bit
> if that work lands soon.

Correct - that's the long-term strategy on this issue.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

This is too late for 38 but we could take a patch for 39.

Comment 14

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

I picked up logs on Windows 8.1 x64 using Nightly from December 29th (without the issue) and Nightly from December 31st (with the issue). You can find the logs attached below.

Comment 15

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Attachment: log29.txt.child-1

Comment 16

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Attachment: log31.txt.child-1

Log for Nightly 2014-12-31 (with the issue)

Comment 17

[Liz Henry (:lizzard) (relman/hg->git project)]

It is getting to late to get this into 39 but we would likely still take a patch for aurora. 

Bobby is this still on your radar? Thanks.

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Ralph, any chances that bug 1151175 is going to fix this bug? Thanks

Comment 19

[Ralph Giles (:rillian)]

No, bug 1151175 only affects the decode of individual frames. This is an issue with higher level code.

Comment 20

[Bobby Holley (:bholley)]

Sorry for the lag - I'm not working on this stuff anymore, so forwarding this to someone who is.

Comment 21

[Jean-Yves Avenard [:jya]]

hopefully this will be fixed by bug 1148102 ; decoding will now be fully asynchronous and audio and video using their respective thread to decode.
Won't be happening until 42 however.

Comment 22

[Sylvestre Ledru [:Sylvestre]]

OK. I am going to mark it as wontfix for 40 as we shipped a few releases with this bug...

Comment 23

[nivtwig]

I still see a problem with webm video freezes/stuttering here (on the Visual Studio 2015 keynote event video), on the latest Nightly 42.0a1 (2015-07-21):

https://channel9.msdn.com/Events/Visual-Studio/Visual-Studio-2015-Final-Release-Event/Keynote-Visual-Studio-2015-Any-app-Any-developer

It doesn't affect the UI responsiveness of the rest of the browser.
Platform : Windows 7 32bit
It happens with and without e10s

I tested this multiple times, and Chrome plays this video without problems therefore it is not a problem with network connection.

Comment 24

[Adam Frisby]

Can confirm. Original video still freezes for me.

Comment 25

[Jean-Yves Avenard [:jya]]

can you try nightly and setting:
media.format-reader.webm to true

?

Comment 26

[Adam Frisby]

Video plays correctly with media.format-reader.webm set to true.

Comment 27

[nivtwig]

Yes, video plays fine with media.format-reader.webm set to true, for me too.