Interoperable buffered.start(0) fudge room

[chcunningham]

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:

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

[wolenetz]

See also #205