Closed Bug 1156860 Opened 5 years ago Closed 4 years ago
Webm video freezes
Status: UNCONFIRMED → NEW
Component: Untriaged → Video/Audio
Ever confirmed: true
OS: Unspecified → Windows
Product: Firefox → Core
Hardware: Unspecified → x86
[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
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?
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?
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.
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.
(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.
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.
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.
Ralph, any chances that bug 1151175 is going to fix this bug? Thanks
No, bug 1151175 only affects the decode of individual frames. This is an issue with higher level code.
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.
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): 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.
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.
Yes, video plays fine with media.format-reader.webm set to true, for me too.
4 years ago
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.