Bug 1288331: [ogg] P2. Fix fast seek mochitest. r?cpearce
Fast seek in the old OggReader is broken: the audio track isn't seeked to the video track in order to preserve A/V sync and we end up always performing an accurate seek which explain why this test succeeded before.
The page index is only made of two entries, and so the first video frame returned after a seek, if within the first index will always have a time of 0.
MozReview-Commit-ID: 2EYzLMWRZAi
--- a/dom/media/test/manifest.js
+++ b/dom/media/test/manifest.js
@@ -547,17 +547,18 @@ var gSeekTests = [
var gFastSeekTests = [
{ name:"gizmo.mp4", type:"video/mp4", keyframes:[0, 1.0, 2.0, 3.0, 4.0, 5.0 ] },
// Note: Not all keyframes in the file are actually referenced in the Cues in this file.
{ name:"seek.webm", type:"video/webm", keyframes:[0, 0.8, 1.6, 2.4, 3.2]},
// Note: the sync points are the points on both the audio and video streams
// before the keyframes. You can't just assume that the keyframes are the sync
// points, as the audio required for that sync point may be before the keyframe.
- { name:"bug516323.indexed.ogv", type:"video/ogg", keyframes:[0, 0.46, 3.06] },
+ // We can only seek at the boundary of a page index. see bug 1289438.
+ { name:"bug516323.indexed.ogv", type:"video/ogg", keyframes:[0, 3.06] },
];
function IsWindows8OrLater() {
var re = /Windows NT (\d.\d)/;
var winver = manifestNavigator().userAgent.match(re);
return winver && winver.length == 2 && parseFloat(winver[1]) >= 6.2;
}