Closed Bug 1156860 Opened 5 years ago Closed 4 years ago

Webm video freezes


(Core :: Audio/Video, defect)

37 Branch
Not set



Tracking Status
firefox37 --- wontfix
firefox38 + wontfix
firefox39 + wontfix
firefox40 + wontfix


(Reporter: AdamBugzilla, Assigned: jya)



(Keywords: perf, regression)


(2 files)

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

Steps to reproduce:


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



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


Incremental GC: true


Activated: false
Prevent Accessibility: 0

Library Versions

Expected minimum version: 4.10.8
Version in use: 4.10.8

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

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

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

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

Experimental Features
Component: Untriaged → Video/Audio
Ever confirmed: true
Keywords: regression
OS: Unspecified → Windows
Product: Firefox → Core
Hardware: Unspecified → x86
[Tracking Requested - why for this release]: performance regression of video playback

Regression window:

Suspect: Bug 1114840
Blocks: 1114840
Keywords: perf
Via local build,
Last Good: 0f80e83ac9e5
First Bad: cb7e862569a1

Triggered by: cb7e862569a1	Bobby Holley — Bug 1114840 - Don't start playback during prerolling. r=cpearce
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?
Flags: needinfo?(bobbyholley)
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.
Assignee: nobody → bobbyholley
(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.
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)
Bobby, 38 beta 7 gtb is today. So, a patch would have to arrive soon. Thanks
(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.
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?
Depends on: 1157840
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.
Flags: needinfo?(bobbyholley)
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.
Flags: needinfo?(florin.mezei)
(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.
This is too late for 38 but we could take a patch for 39.
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.
Flags: needinfo?(florin.mezei)
Attached file log31.txt.child-1
Log for Nightly 2014-12-31 (with the issue)
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.
Flags: needinfo?(bobbyholley)
Ralph, any chances that bug 1151175 is going to fix this bug? Thanks
Flags: needinfo?(giles)
No, bug 1151175 only affects the decode of individual frames. This is an issue with higher level code.
Flags: needinfo?(giles)
Sorry for the lag - I'm not working on this stuff anymore, so forwarding this to someone who is.
Flags: needinfo?(bobbyholley) → needinfo?(jyavenard)
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.
Flags: needinfo?(jyavenard)
Depends on: 1148102
OK. I am going to mark it as wontfix for 40 as we shipped a few releases with this bug...
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):

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.
Can confirm. Original video still freezes for me.
can you try nightly and setting:
media.format-reader.webm to true

Video plays correctly with media.format-reader.webm set to true.
Assignee: bobbyholley → jyavenard
Yes, video plays fine with media.format-reader.webm set to true, for me too.
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.