Bug 1288331: [ogg] P2. Fix fast seek mochitest. r?cpearce draft
authorJean-Yves Avenard <jyavenard@mozilla.com>
Wed, 27 Jul 2016 00:12:28 +1000
changeset 394309 04bc9087076a975391d65189a6039bbe531ebe11
parent 394308 4c0507eeb12eb261c9dae5f32a3853cf9a76474a
child 394310 585eeed23f8b189573b99091ed658539d20033a8
push id24553
push userbmo:jyavenard@mozilla.com
push dateFri, 29 Jul 2016 16:10:03 +0000
reviewerscpearce
bugs1288331
milestone50.0a1
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
dom/media/test/manifest.js
--- 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;
 }