Re: [media-source-tests] Add duration coverage found missing during review of PR #3232 (#3655)

The value don't appear good to me, in particular for the video track.
The video you're adding is 2s long only or close to, so setting the new duration to a value close to 2 will be a problem.

It happens to be okay with mp4, because the last frame that still fit with the append window happened to also be the last sample of the file and have an end time of 2.066666 so you'll have your assert.


With webm however:
FAIL: Truncating the duration throws an InvalidStateError exception when new duration is less than a buffered coded frame presentation time
assert_throws: function "function () { mediaSource.duration = newDuration; }" did not throw
after the audio appendBuffer we have the sourceBufferAudio.buffered equal to (0.808000, 1.783000)

The reason for 1.783 end time is that we have an overlapping frame:
with a start time of 1.784000 and end time of 1.807000
Per spec:
9. If frame end timestamp is greater than appendWindowEnd, then set the need random access point flag to true, drop the coded frame, and jump to the top of the loop to start processing the next coded frame.
so that frame is dropped.

For video however we have the last frame of the file with a start time of 1.967000 and end time of 2.000333

setting duration to 2 will succeed because it's greater than the highest *starting* time

So I suggest the following:
do not set sourceBufferVideo.appendWindowEnd.
set new duration to a value greater than the sourceBufferAudio.appendWindowEnd : say 1.9

Or:
have a specific check for webm and mp4.
webm: must fail if new duration is < 1.967000
mp4: must fail if new duration is < 2.033333

the later is probably more thorough.

Be careful that due to chrome issue of misusing dts, the last mp4 frame has a dts of 1.966666, that complicates the matter if you attempt to verify the issue with chrome or edge.

Tested with Firefox Nightly, which is fully up to date with the current specs.
You can test yourself with going into about:support and setting the preference:
media.mediasource.mp4.enabled to false
This will enable the webm mediasource by default.

I should point out that running current master with just this patch I see failures there for:
Test seek starts on duration truncation below currentTime
Test appendBuffer completes previous seek to truncated duration
Test endOfStream completes previous seek to truncated duration

each due to "assert_equals: Playback time is truncatedDuration while seeking expected 1.522 but got 1.527"
The test incorrectly assume that seeking will seek to the truncatedDuration, however as duration is set to the highest end time across all tracks, that it seeks to 1.527 is correct.

The tests haven't been updated for the last duration change spec change from a few days ago.


View on GitHub: https://github.com/w3c/web-platform-tests/pull/3655#issuecomment-245175163

Received on Wednesday, 7 September 2016 04:57:04 UTC