MSE: Add basic sequence AppendMode layout tests

MSE: Add basic sequence AppendMode layout tests

Adds some basic layout tests for 'sequence' SourceBuffer.mode.

Without WebM stream parser support, Chromium MP4 parser causes the new
test to fail. Bug 371947 tracks that failure, which will not show on
Chromium bots since they don't support mp4_stream_parser.

R=acolwell@chromium.org
BUG=249422
TEST=(webm on local Linux) http/tests/media/media-source/mediasource-sequencemode-append-buffer.html

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=174336

[wolenetz, 2014-05-09 19:16:10]

acolwell: PS1 is for helping diagnose an issue (bug 371947). It should not be
committed. 

(depends on https://codereview.chromium.org/180153003/ landing first)

[wolenetz, 2014-05-10 00:08:26]

PTAL @ PS2.
Thanks!

[acolwell GONE FROM CHROMIUM, 2014-05-12 14:00:08]

looks good. Just a few comments/questions

https://codereview.chromium.org/273153002/diff/20001/LayoutTests/http/tests/m...
File
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html
(right):

https://codereview.chromium.org/273153002/diff/20001/LayoutTests/http/tests/m...
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:63:
// segment timecodes, hence allowance of up to 10% deviation from expectation
here.
What? Why is this the case? If the timecode info isn't correct we should fix it
not add an approximation here. Also 10% seems rather high, why is such a wide
margin needed? It seems like a time bound should be specified instead of a
percentage.

https://codereview.chromium.org/273153002/diff/20001/LayoutTests/http/tests/m...
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:88:
// segment timecodes, hence allowance of up to 10% deviation from expectation
here.
ditto re: time bound instead of percentage

https://codereview.chromium.org/273153002/diff/20001/LayoutTests/http/tests/m...
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:102:
expected_offset / 10,
ditto.

[wolenetz, 2014-05-12 20:21:38]

On 2014/05/12 14:00:08, acolwell_OOO_5-12_to_5-15 wrote:
> looks good. Just a few comments/questions
> 
>
https://codereview.chromium.org/273153002/diff/20001/LayoutTests/http/tests/m...
> File
>
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html
> (right):
> 
>
https://codereview.chromium.org/273153002/diff/20001/LayoutTests/http/tests/m...
>
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:63:
> // segment timecodes, hence allowance of up to 10% deviation from expectation
> here.
> What? Why is this the case? If the timecode info isn't correct we should fix
it
> not add an approximation here. Also 10% seems rather high, why is such a wide
> margin needed? It seems like a time bound should be specified instead of a
> percentage.
> 
>
https://codereview.chromium.org/273153002/diff/20001/LayoutTests/http/tests/m...
>
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:88:
> // segment timecodes, hence allowance of up to 10% deviation from expectation
> here.
> ditto re: time bound instead of percentage
> 
>
https://codereview.chromium.org/273153002/diff/20001/LayoutTests/http/tests/m...
>
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:102:
> expected_offset / 10,
> ditto.

(For WebM now, MP4 later), I believe I can make the expectations accurate
instead of using approx if I include enough data into mediasource-util.js
segment info for the tests to be able to generate a prediction for
|group_end_timestamp| (GETS) in a muxed stream like this test uses. For example,
webm segment info.media[1] could use some of the following extra information:
// Last audio PTS=0.756 (dur=0.023), last video PTS=0.764 (dur=0.033), DTS==PTS
for WebM

This lets test calculate GETS after appending in sequence mode after init just
media[1]:
GETS (including accounting for initial timestamp offset of -0.385) should be
(max(0.756+0.023, 0.764+0.033) - 0.385) == 0.412.
Because of the 'jagged end' where GETS is potentially not the same after last
audio vs last video coded frame in the media segment, GETS is not always equal
to the next media segment's timecode. This is root of why approx was being used
to check that 0.412 is near to 0.385.

Next patch set will include enough information for at least WebM-based sequence
mode append layout tests to use exact-match expectations instead of
approx_equal.

[wolenetz, 2014-05-19 21:20:43]

PTAL @ PS3.
Thanks!

https://codereview.chromium.org/273153002/diff/20001/LayoutTests/http/tests/m...
File
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html
(right):

https://codereview.chromium.org/273153002/diff/20001/LayoutTests/http/tests/m...
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:63:
// segment timecodes, hence allowance of up to 10% deviation from expectation
here.
On 2014/05/12 14:00:09, acolwell wrote:
> What? Why is this the case? If the timecode info isn't correct we should fix
it
> not add an approximation here. Also 10% seems rather high, why is such a wide
> margin needed? It seems like a time bound should be specified instead of a
> percentage.

Done.

https://codereview.chromium.org/273153002/diff/20001/LayoutTests/http/tests/m...
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:88:
// segment timecodes, hence allowance of up to 10% deviation from expectation
here.
On 2014/05/12 14:00:09, acolwell wrote:
> ditto re: time bound instead of percentage

Done.

https://codereview.chromium.org/273153002/diff/20001/LayoutTests/http/tests/m...
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:102:
expected_offset / 10,
On 2014/05/12 14:00:09, acolwell wrote:
> ditto.

Done.

[acolwell GONE FROM CHROMIUM, 2014-05-19 22:12:48]

lgtm % nits

https://codereview.chromium.org/273153002/diff/50001/LayoutTests/http/tests/m...
File
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html
(right):

https://codereview.chromium.org/273153002/diff/50001/LayoutTests/http/tests/m...
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:41:
test.waitForExpectedEvents(function() { callback(); });
You can just use test.waitForExpectedEvents(callback);

https://codereview.chromium.org/273153002/diff/50001/LayoutTests/http/tests/m...
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:46:
return Number(number.toFixed(3));
Why do you need the Number()?

https://codereview.chromium.org/273153002/diff/50001/LayoutTests/http/tests/m...
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:89:
segmentInfo.media[1].timecode /* + timestampOffset of 0 */,
nit: Remove the comments. I think they are more confusing than helpful. If you
are looking for consistancy between tests, just put sourceBuffer.timestampOffset
like you have below.

[wolenetz, 2014-05-19 22:23:03]

https://codereview.chromium.org/273153002/diff/50001/LayoutTests/http/tests/m...
File
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html
(right):

https://codereview.chromium.org/273153002/diff/50001/LayoutTests/http/tests/m...
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:41:
test.waitForExpectedEvents(function() { callback(); });
On 2014/05/19 22:12:49, acolwell wrote:
> You can just use test.waitForExpectedEvents(callback);

Done.

https://codereview.chromium.org/273153002/diff/50001/LayoutTests/http/tests/m...
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:46:
return Number(number.toFixed(3));
On 2014/05/19 22:12:49, acolwell wrote:
> Why do you need the Number()?

By example:
var a = 3.14159265;
a.toFixed(3) == "3.141" (string type)
and comparing numbers vs strings fails. So I convert the string back to a
number. My JS fu isn't extremely deep, so if you have a better way, please share
:) (e.g. someKindOfIntegerTruncateMethod(a * 1000) / 1000.0 might do the trick,
too.)

https://codereview.chromium.org/273153002/diff/50001/LayoutTests/http/tests/m...
LayoutTests/http/tests/media/media-source/mediasource-sequencemode-append-buffer.html:89:
segmentInfo.media[1].timecode /* + timestampOffset of 0 */,
On 2014/05/19 22:12:49, acolwell wrote:
> nit: Remove the comments. I think they are more confusing than helpful. If you
> are looking for consistancy between tests, just put
sourceBuffer.timestampOffset
> like you have below. 

Done.

[wolenetz, 2014-05-19 22:23:32]

The CQ bit was checked by wolenetz@chromium.org

[commit-bot: I haz the power, 2014-05-19 22:23:50]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/wolenetz@chromium.org/273153002/70001

[commit-bot: I haz the power, 2014-05-19 23:39:52]

FYI, CQ is re-trying this CL (attempt #1).
Please consider checking whether the failures are real,
and report flakes to chrome-troopers@google.com.
The failing builders are:
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/8196)

[commit-bot: I haz the power, 2014-05-20 00:29:13]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-05-20 00:29:14]

Try jobs failed on following builders:
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/8206)

[wolenetz, 2014-05-20 01:14:44]

The CQ bit was checked by wolenetz@chromium.org

[commit-bot: I haz the power, 2014-05-20 01:15:06]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/wolenetz@chromium.org/273153002/70001

[commit-bot: I haz the power, 2014-05-20 01:50:52]

Change committed as 174336