- From: wolenetz <web-platform-tests-notifications@w3.org>
- Date: Wed, 07 Sep 2016 05:52:23 GMT
- To: public-web-platform-tests-notifications@w3.org
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-245182192
Received on Wednesday, 7 September 2016 05:52:31 UTC