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

Also, good point about the need to update the current time while seeking to
truncated duration expectation. I'll fix that too in an update to this pr.

On Sep 6, 2016 10:52 PM, "Matt Wolenetz" <wolenetz@google.com> wrote:

> I'll take a closer look in the morning here; I think s/appendWindowStart/timestampOffset/
> is what I was intending to do but forgot in the new subtest.
>
> On Sep 6, 2016 9:57 PM, "Jean-Yves Avenard" <notifications@github.com>
> wrote:
>
>> 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.
>>
>> —
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub
>> <https://github.com/w3c/web-platform-tests/pull/3655#issuecomment-245175163>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/ALCtwxcsPJWmpiBgM7QsATdW3Pq18yakks5qnkQdgaJpZM4J2hA_>
>> .
>>
>


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

Received on Wednesday, 7 September 2016 05:57:36 UTC