6af48593fbb4d39d6d0bb9006501de8bda8fa573: Bug 1293613: Never attempt to read past end of manifest table. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 11 Aug 2016 15:17:34 +1000 - rev 399479
Push 25846 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:48:53 +0000
Bug 1293613: Never attempt to read past end of manifest table. r?gerald Should the events being waited for take a while to fire, we could have attempted to append more segments than the table contain causing an exception. MozReview-Commit-ID: HnmLTqNQ5rb
cb4aec06a8883d385c9fc3df4ec890b7fc18de8e: Bug 1293613: Don't assume that once playing event has fired, the earlier appendBuffer has completed. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 15:10:47 +1000 - rev 399478
Push 25846 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:48:53 +0000
Bug 1293613: Don't assume that once playing event has fired, the earlier appendBuffer has completed. r?gerald The two operations are asynchronous and independent. MozReview-Commit-ID: D2woSoIzE6p
f443d14ebdb69af1503788f481d130e842cd5244: Bug 1293613: Update test using new manifest details. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 14:43:24 +1000 - rev 399477
Push 25846 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:48:53 +0000
Bug 1293613: Update test using new manifest details. r?gerald Do not assume that the element is still seeking when the seeking event is actually fired (the seeking operation is asynchronous) MozReview-Commit-ID: Ap24kUQK8R2
e51fb05e733356cc2de7555793ae4319a0849822: Bug 1293613: Make liveseekable test run. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 14:22:11 +1000 - rev 399476
Push 25846 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:48:53 +0000
Bug 1293613: Make liveseekable test run. r?gerald - No html document existed, preventing the test to run. - Remove test related to the updating attribute being cleared: see https://github.com/w3c/media-source/issues/118 MozReview-Commit-ID: GxOBnr5mqyh
ef996bbb17007f826e57f507e59d0b019e77551a: Bug 1293613: Don't assume that all videos start at 0. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 13:22:35 +1000 - rev 399475
Push 25846 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:48:53 +0000
Bug 1293613: Don't assume that all videos start at 0. r?gerald See issue https://github.com/w3c/web-platform-tests/issues/1939 MozReview-Commit-ID: LgDQRS8Xz3L
8ed9693ad9d11492ab0f1e2c1f93c813d57f4e1b: Bug 1293613: Don't assume all segments audio and video track start at the same time point. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 12:12:08 +1000 - rev 399474
Push 25846 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:48:53 +0000
Bug 1293613: Don't assume all segments audio and video track start at the same time point. r?gerald Audio track and video tracks have under most cases a different start and end time. Additionally, the mp4 file is poorly muxed and contains out of order frames. As such we keep a table of time and duration for each media segments. The test itself was right, however it had an invalid time table to start with as it incorrectly used the dts (decode timestamp) instead of the pts (presentation timestamp). MozReview-Commit-ID: G2uwK3rroj3
de13d19fccfdab932b21b788b201492f64ed4b3d: Bug 1293613: amend expected MSE web-platform-tests expected results. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 15:20:25 +1000 - rev 399473
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293613: amend expected MSE web-platform-tests expected results. r?gerald They should all run properly now. MozReview-Commit-ID: YLjQ8jkNcf
904b824c8da4ff9d63d92ca74b47d6a8c394a52d: Bug 1293613: Never attempt to read past end of manifest table. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 11 Aug 2016 15:17:34 +1000 - rev 399472
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293613: Never attempt to read past end of manifest table. r?gerald Should the events being waited for take a while to fire, we could have attempted to append more segments than the table contain causing an exception. MozReview-Commit-ID: HnmLTqNQ5rb
a13aaf62aa70dadf733ab5f6608ef0631a8965d4: Bug 1293613: Don't assume that once playing event has fired, the earlier appendBuffer has completed. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 15:10:47 +1000 - rev 399471
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293613: Don't assume that once playing event has fired, the earlier appendBuffer has completed. r?gerald The two operations are asynchronous and independent. MozReview-Commit-ID: D2woSoIzE6p
a1cb0b9790cf3de46c25d84a732571b89ee99d9f: Bug 1293613: Update test using new manifest details. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 14:43:24 +1000 - rev 399470
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293613: Update test using new manifest details. r?gerald Do not assume that the element is still seeking when the seeking event is actually fired (the seeking operation is asynchronous) MozReview-Commit-ID: Ap24kUQK8R2
75398b4b69adeaad11d55017474940a6fd5b21ff: Bug 1293613: Make liveseekable test run. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 14:22:11 +1000 - rev 399469
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293613: Make liveseekable test run. r?gerald - No html document existed, preventing the test to run. - Remove test related to the updating attribute being cleared: see https://github.com/w3c/media-source/issues/118 MozReview-Commit-ID: GxOBnr5mqyh
b9f6780f3bb790e3e01bcbbc1cdcef68308d67a1: Bug 1293613: Don't assume that all videos start at 0. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 13:22:35 +1000 - rev 399468
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293613: Don't assume that all videos start at 0. r?gerald See issue https://github.com/w3c/web-platform-tests/issues/1939 MozReview-Commit-ID: LgDQRS8Xz3L
5b1cd30bec1114100a7fbd2341732ec05ee617eb: Bug 1293613: Don't assume all segments audio and video track start at the same time point. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 12:12:08 +1000 - rev 399467
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293613: Don't assume all segments audio and video track start at the same time point. r?gerald Audio track and video tracks have under most cases a different start and end time. Additionally, the mp4 file is poorly muxed and contains out of order frames. As such we keep a table of time and duration for each media segments. The test itself was right, however it had an invalid time table to start with as it incorrectly used the dts (decode timestamp) instead of the pts (presentation timestamp). MozReview-Commit-ID: G2uwK3rroj3
4fb60cf715fc6dd81afdd972a97ef0b167e5ebb4: Bug 1293613: An invalid or revoked MediaSource URI can't be trace to a MediaSource object. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 12:01:13 +1000 - rev 399466
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293613: An invalid or revoked MediaSource URI can't be trace to a MediaSource object. r?gerald https://w3c.github.io/media-source/index.html#mediasource-attach: "If the resource fetch algorithm absolute URL matches the MediaSource object URL, ignore any preload attribute of the media element, skip any optional steps for when preload equals none" A dummy URL or a revoked one no longer matches the MediaSource object URL, as such, the preload attribute isn't to be ignored. MozReview-Commit-ID: EW5TOv9SSf
92dd3d9c4b9ccdc8a47ac419bcd40fb74ab80aa6: Bug 1293613: Correct mediasource-duration.html r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 11:57:32 +1000 - rev 399465
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293613: Correct mediasource-duration.html r?gerald - The WebM file manifest correctly indicates the duration as reported in the metadata. However, the last frame has an end time 0f 6.05s which would adjust the duration. As such it is incorrect to assume that after a full appendBuffer the duration will remain the same as set in the metadata. (source: https://w3c.github.io/media-source/index.html#sourcebuffer-coded-frame-processing "5. If the media segment contains data beyond the current duration, then run the duration change algorithm with new duration set to the maximum of the current duration and the group end timestamp") - When setting the duration, the actual final duration may be different to what was set as it will be aligned to the highest end time (source: https://w3c.github.io/media-source/index.html#duration-change-algorithm ("4.1 Update new duration to the highest end time reported by the buffered attribute across all SourceBuffer objects in sourceBuffers.") MozReview-Commit-ID: EpzSaSg8pWW
cff35a95c21cf83e469fd6c35eb1dcd8ddc761c7: Bug 1293613: Update manifest with new test scripts. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 11:50:42 +1000 - rev 399464
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293613: Update manifest with new test scripts. r?gerald MozReview-Commit-ID: C8vMTcWiDJ5
b11f0839ddc6a68c9dde9dfc8f17122832a1217b: Bug 1293613: Don't assume that all videos start at 0. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 09 Aug 2016 21:40:37 +1000 - rev 399463
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293613: Don't assume that all videos start at 0. r?gerald The tests incorrectly assume that all videos start at 0. However this is often not the case, in particular for the mp4 files. The buffered range is the intersection of the audio track and the video track. As such, if the video track starts at a later time than 0, the buffered range of the source buffer can't be starting at 0. Rather than using different videos, we properly use the correct values; this is done to ensure that buffered range are calculated correctly, regardless of the video content. timestamps verify with mkvinfo utility for webm and ffprobe for mp4. See issue https://github.com/w3c/web-platform-tests/issues/1939 MozReview-Commit-ID: AMKgJHEJsWr
5fb1b40ae4a97663acacdb59460bc2d11d03ed1c: Bug 1293927: Always use MediaSource seekable range regardless of readyState. r?jwwang draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 14:14:37 +1000 - rev 399462
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293927: Always use MediaSource seekable range regardless of readyState. r?jwwang MozReview-Commit-ID: 7ae467k5PSf
ca3756def65fc7f354e91525e94602b8ae7a6326: Bug 1293576: [MSE] P2. Fix mochitest. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 16:21:36 +1000 - rev 399461
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293576: [MSE] P2. Fix mochitest. r?gerald The mochitest relied that the video track was processed first. Additionally, change for the file with only a single video track as the previous video didn't have aligned segments, making the use of sequence mode useless. We swap the segment around, which allow to more easily visually inspect the result (counter goes forward and then back) MozReview-Commit-ID: 33PsrmRF1GL
d19275cd6ee470a9655822fcf1e978e8b27195d3: Bug 1293576: [MSE] P1. Always process the earliest frames first when in sequence mode. r?gerald draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 09 Aug 2016 23:11:36 +1000 - rev 399460
Push 25845 by bmo:jyavenard@mozilla.com at Thu, 11 Aug 2016 05:43:30 +0000
Bug 1293576: [MSE] P1. Always process the earliest frames first when in sequence mode. r?gerald MozReview-Commit-ID: 2b3EyYCtNai
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip