[media-source] Interoperable buffered.start(0) fudge room (#267)

chcunningham has just created a new issue for https://github.com/w3c/media-source:

== Interoperable buffered.start(0) fudge room ==
I accidentally created a demo (for a separate issue) that didn't work in Safari because the video buffer didn't start at zero. The demo does work in Chrome and Firefox. 
https://oxidized-tide-seeder.glitch.me/start_time_bug.html

@jernoble [wrote](https://github.com/whatwg/html/issues/6359#issuecomment-773661713):

> There's a couple of weird things about this test. In Firefox & Safari, the video track seems to start at 0.2s, and the audio exactly at 0.0s. Chrome, meanwhile, seems to think the video track starts at 0.766s. All browsers think the first appended video segment ends at 3.1s (or 3.0999s for Chrome). Looking at the file itself, it has a an edit list which looks like it intends to shift the first sample back one frame-duration so both tracks start at 0s, but also has a sidx box indicating the first frame is available at 0.2s.
> 
> Firefox and Chrome allow the user to play through a 0.2s or 0.766s gap at the start of a video; both have a readyState of HAVE_ENOUGH_DATA. Safari treats this as an unbuffered range and stalls waiting for data to be appended, and has a readyState of HAVE_METADATA. I would argue Safari's behavior here is correct, since we literally do not have data for the current time available for decoding.

The spec might clarify:
- what to do when edit list and sidx conflict
- whether some amount of mismatch between audio/video start should be allowed

Please view or discuss this issue at https://github.com/w3c/media-source/issues/267 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 5 February 2021 22:28:54 UTC