Closed Bug 1197051 Opened 4 years ago Closed 4 years ago
[EME] Playback stalls after seeking encrypted video (again)
This time for a different reason! (see bug 1195939 for STR) While the fix in bug 1195939 works on beta, on trunk we get hammered by lots of frames after a seek. Bug 1171257 looks very suspect -- flooding the reader with frames if decode is falling behind.
19:42 < jya> I guess here if no frames has been returned to the MDSM ; and it has started playback, the video queue size will become < 1 19:43 < jya> and it will start telling the reader to decode like crazy 19:43 < edwin> I wonder if that condition is triggered by the queue being flushed... say... by a seek? 19:44 < jya> edwin: ah good call Oh yes indeed.
Comment on attachment 8650834 [details] [diff] [review] seek-decodeahead.patch r? either/or.
Backed out for a youtube playback regression. See Bug 1199573. https://hg.mozilla.org/releases/mozilla-aurora/rev/5bb661db5c6c
Edwin: Does this affect Adobe EME on Firefox 41? If so we need to uplift.
I would revert the entire force decode ahead commit. I've done so in patch 2 of bug 1197075
(In reply to [PTO] Chris Pearce (:cpearce) from comment #6) > Edwin: Does this affect Adobe EME on Firefox 41? If so we need to uplift. 41 is unaffected.
pushed it as part of https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?changeset=7437f28133fc
You need to log in before you can comment on or make changes to this bug.