f4f41b355cf02a757995e18bd4878efb90086818: Bug 1294345 - Remove the TrackSet parameter from MediaDecoderStateMachine::InitiateDecodeRecoverySeek(). r=kaku
JW Wang <jwwang@mozilla.com> - Thu, 11 Aug 2016 15:03:15 +0800 - rev 400076
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +0000
Bug 1294345 - Remove the TrackSet parameter from MediaDecoderStateMachine::InitiateDecodeRecoverySeek(). r=kaku MozReview-Commit-ID: 7iXecyVAIXq
31e906fb345e5a378e862645a23dd19192db3fc9: Bug 1293613: don't assume playback won't be finished by the time the seeked event is fired. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 22:11:43 +1000 - rev 400075
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +0000
Bug 1293613: don't assume playback won't be finished by the time the seeked event is fired. r=gerald The data added in the sourcebuffer is very short (less than one second); it is possible that playback has completed prior the event being fired. MozReview-Commit-ID: INHAFmEhSut
0318e5ab46a8771236a3cdfe268307afb6a36146: Bug 1294324 - Remove MediaDecoderStateMachine::IsPausedAndDecoderWaiting. r=bechen
JW Wang <jwwang@mozilla.com> - Thu, 11 Aug 2016 11:40:53 +0800 - rev 400074
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +0000
Bug 1294324 - Remove MediaDecoderStateMachine::IsPausedAndDecoderWaiting. r=bechen MozReview-Commit-ID: CepvbVjoN1k
1335339b74bee2c76d78c50b4448ff85321dc3ad: Bug 1294320 - Remove MediaDecoderStateMachine::IsVideoDecodeSuspended() r=kaku
JW Wang <jwwang@mozilla.com> - Thu, 11 Aug 2016 11:32:14 +0800 - rev 400073
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +0000
Bug 1294320 - Remove MediaDecoderStateMachine::IsVideoDecodeSuspended() r=kaku MozReview-Commit-ID: 9iTzmMhw686
7462a01bd90629806d86a3df35bd421b015b6865: Bug 1293613: amend expected MSE web-platform-tests expected results. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 15:20:25 +1000 - rev 400072
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +0000
Bug 1293613: amend expected MSE web-platform-tests expected results. r=gerald They should all run properly now. MozReview-Commit-ID: YLjQ8jkNcf
9f514918f33580ea6c4f9d765aca0f8d6476eec0: Bug 1293613: Never attempt to read past end of manifest table. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 11 Aug 2016 15:17:34 +1000 - rev 400071
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +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
bde91881654fbd0bc8f3f591cbc97871159ab1dd: Bug 1293613: Don't assume that once playing event has fired, the earlier appendBuffer has completed. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 15:10:47 +1000 - rev 400070
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +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
07b2fa5b4c94bbd8fb10e49190c3a2615edd98f3: Bug 1293613: Update test using new manifest details. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 14:43:24 +1000 - rev 400069
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +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
d5e63c7b5409b67598d91adaf1b3838c2a1b9f85: Bug 1293613: Make liveseekable test run. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 14:22:11 +1000 - rev 400068
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +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
c4a4c5ead421a430586962f44c983a35883bd16e: Bug 1293613: Don't assume that all videos start at 0. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 13:22:35 +1000 - rev 400067
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +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
bf05ed42e18a87eba149e995210572b6254e18f3: Bug 1293613: Don't assume all segments audio and video track start at the same time point. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 12:12:08 +1000 - rev 400066
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +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
1ea1ecf7d4b0571a57e0d1adee4525e01e7042d9: Bug 1293613: An invalid or revoked MediaSource URI can't be trace to a MediaSource object. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 12:01:13 +1000 - rev 400065
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +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
0db1ed3d603b9a6da31ef7d2a8935817269abde5: Bug 1293613: Correct mediasource-duration.html r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 11:57:32 +1000 - rev 400064
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +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
2cae41cf5ea565dbf0c9fcdfc4d5a5c8eb720951: Bug 1293613: Update manifest with new test scripts. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 11:50:42 +1000 - rev 400063
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +0000
Bug 1293613: Update manifest with new test scripts. r=gerald MozReview-Commit-ID: C8vMTcWiDJ5
96e477498ea41097e65ca3ac3ae332d2e8733467: Bug 1293613: Don't assume that all videos start at 0. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 09 Aug 2016 21:40:37 +1000 - rev 400062
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +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
b9c9444d6a05371ac480f75a9151db00ed296b7b: Bug 1258539 - [mozharness] Refactor name and arguments of download and unpack methods. r=jlund
Henrik Skupin <mail@hskupin.info> - Thu, 04 Aug 2016 15:07:30 +0200 - rev 400061
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +0000
Bug 1258539 - [mozharness] Refactor name and arguments of download and unpack methods. r=jlund Given that we have a universal unpack method now do not keep 'unzip' in method names. Also adapt arguments to be better understandable. MozReview-Commit-ID: ClDB5mSVcI2
07273f73c50c0174251c23fc670411d800328b21: Bug 1258539 - [mozharness] Use ZipFile and TarFile classes for unpacking archives. r=jlund
Henrik Skupin <mail@hskupin.info> - Mon, 18 Jan 2016 19:50:26 +0100 - rev 400060
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +0000
Bug 1258539 - [mozharness] Use ZipFile and TarFile classes for unpacking archives. r=jlund Get rid of external unpack tools (unzip and tar) and use the Python internal classes instead. This patch only changes this behavior for the base script class but not for custom code in other test scripts and modules, which would make it too complex. A follow-up bug will be filed instead. MozReview-Commit-ID: L0eoITlqTdC
4b946dd315c8cb1c53bb6d666adb2ccaa88d8177: Bug 1284177 - P2: Video decode suspend mochitests. r=jwwang
Dan Glastonbury <dglastonbury@mozilla.com> - Mon, 04 Jul 2016 12:35:25 +1000 - rev 400059
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +0000
Bug 1284177 - P2: Video decode suspend mochitests. r=jwwang Test: - That video decode suspends when enabled and delay is reached. - That video decode doesn't suspend when disabled. - That video decode doesn't suspend when video finishes before suspend delay. These tests need to run from content process to observe the suspend notifications via nsIObserverService, but access to gBrowser is in chrome process in e10s. Thus, the reason for loading background_video_chrome.js into chrome process and invoking functions via async messages. MozReview-Commit-ID: 2eE97FEUMPu
24602315090f4177915dab87f60d908a661916ae: Bug 1284177 - P1: Provide observable notification for video suspend. r=jwwang
Dan Glastonbury <dglastonbury@mozilla.com> - Mon, 04 Jul 2016 14:35:21 +1000 - rev 400058
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +0000
Bug 1284177 - P1: Provide observable notification for video suspend. r=jwwang To support mochitests, report change in video decode suspend state via events mozentervideosuspend/mozexitvideosuspend. MozReview-Commit-ID: EwMduLzcMVg
197e4391064f5b87e40e0184090a2b4d2a989e27: Bug 1293576: [MSE] P2. Fix mochitest. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 10 Aug 2016 16:21:36 +1000 - rev 400057
Push 26077 by bmo:lclark@mozilla.com at Fri, 12 Aug 2016 16:50:32 +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
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip