Fix permafail for mda on WinXP which has no h264
MozReview-Commit-ID: 35tlO5vPTLD
--HG--
extra : rebase_source : 4d0edc219f75bd2107a3828a4df6419d7449657a
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
--HG--
extra : rebase_source : 864c2a9623d672859b0ab836e25403e90ee2090c
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
--HG--
extra : rebase_source : f9b703a0ed1f3b950428dc55dd7943068bc6aa2d
The two operations are asynchronous and independent.
MozReview-Commit-ID: D2woSoIzE6p
--HG--
extra : rebase_source : bd9bb272d1040d20edbba53d43041cf7d5eb7bbc
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
--HG--
extra : rebase_source : 6bf251e5156e2c306fe004c2c6d959549cddab77
- 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
--HG--
extra : rebase_source : 8b5573a444b9d19e2326bc1329ab7dc7ac7934c4
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
--HG--
extra : rebase_source : 13e0c020ed825f4285291b81dd1fa9da6956dd4b
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
--HG--
extra : rebase_source : f3019139d5c6d198555dc623cd13d7294055e0f6
- 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
--HG--
extra : rebase_source : f4b998ba2a08edabd7eb3607101747ea7fa472d3
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
--HG--
extra : rebase_source : 23420db6acf13e1e12928dfb2057fe9846abfe78
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
--HG--
extra : rebase_source : a98bb26748536115d254842df8257ba050ec8eac
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
--HG--
extra : rebase_source : c8bb3447bece192d6d8cbf3f505f840ec2843112
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
--HG--
extra : rebase_source : e48cc4dab54648bf0830f59f346a09ab3fb73f6e
To support mochitests, report change in video decode suspend state via
events mozentervideosuspend/mozexitvideosuspend.
MozReview-Commit-ID: EwMduLzcMVg
--HG--
extra : rebase_source : 5f1fed90964fae182f06d9fb480491728c5f1c97
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
--HG--
extra : rebase_source : e98a7714f81f5c7913091128b5ee04cf41c2d09b
With MSE, the actual duration is always exact as it is amended when data is added. We do not want to fire ended when we attempt to seek to unbuffered data once endOfStream has been called. Instead we will fire the waiting event.
MozReview-Commit-ID: Cl2uBLk2qRQ
--HG--
extra : rebase_source : 6763c6f5a6e15264e276e486fab4d39491ea7f1b
Otherwise, the ended event would never be fired should the decoder have reached the end of the stream prior endOfStream being called.
MozReview-Commit-ID: CbWCnzi3nxj
--HG--
extra : rebase_source : 729e25919fdb7f8a8918c4d5a9bcae17d8c8bdc5
We were previously using PacketizeFuA which stripped the NAL header. Since the
fragment fit in a single packet it would then be sent without any header
causing difficulties on the receiving side. This adds a PacketizeMode0 which
leaves the header intact.
MozReview-Commit-ID: 91rbveSuXtT
--HG--
extra : rebase_source : 95092f5e3cbb31f9c4697ed4fd272cd458eb4e94
Dan Glastonbury
Ravi Shankar
Jean-Yves Avenard
JW Wang
Henrik Skupin
Dan Minor
Wes Kocher
Georg Fritzsche
James Long
Ehsan Akhgari
Eddy Bruel
Carsten "Tomcat" Book