search

w3c / webmediaporting

Web Media porting spec
2 stars 10 forks source link

requirements on MSE buffering and timing #10

Open mavgit opened 7 years ago

mavgit commented 7 years ago

From @jpiesing on March 7, 2017 15:21

Web video providers have found it necessary to make requirements on MSE buffering and timing.

Hopefully someone who has specified these requirements can provide some input on what they found necessary to specify and why.

Should WAVE say something about this?

Copied from original issue: w3c/webmediaapi#43

mavgit commented 7 years ago

From @jpiesing on May 16, 2017 8:10

Here is a straw-man proposal as requested.

SourceBuffers shall be capable of holding at least ?? media segments. When starting media playback, playback shall begin once at least ?? seconds of media data has been appended and must begin within ?? seconds of sufficient data being appended. When playing to the end of a stream, end of stream shall not be signalled until less than one second of media remains to be presented and all media shall be presented. It must be possible to append at least ?? MBytes of data before the coded frame eviction algorithm is triggered.

mavgit commented 7 years ago

From @bbcrddave on May 16, 2017 12:16

I have a few questions about this:

SourceBuffers shall be capable of holding at least ?? media segments

This appears to imply some size limit. Is this intended to have different meaning to the text about Mbytes before coded frame algorith is triggered?

When starting media playback, playback shall begin once at least ?? seconds of media data has been appended and must begin within ?? seconds of sufficient data being appended.

Surely the application should be in control of playback start when using MSE?

When playing to the end of a stream, end of stream shall not be signalled until less than one second of media remains to be presented and all media shall be presented.

For MSE, end of stream is only signalled in response to the application calling endOfStream (or an error occurs). Can you expand on this?

It must be possible to append at least ?? MBytes of data before the coded frame eviction algorithm is triggered.

Presumably the storage quota a vendor would choose to provide will be dependent on the presentation profiles the device intends to support?

mavgit commented 7 years ago

From @jpiesing on May 16, 2017 17:8

I have a few questions about this:

Someone who knows more about MSE than I do really needs to answer these but anyway ...

SourceBuffers shall be capable of holding at least ?? media segments

This appears to imply some size limit. Is this intended to have different meaning to the text about Mbytes before coded frame algorith is triggered?

I don't think this is a size limit but a minimum requirement which can be tested. Would it be a problem for content providers if some implementations have source buffers that can only hold one media segment?

When starting media playback, playback shall begin once at least ?? seconds of media data has been appended and must begin within ?? seconds of sufficient data being appended.

Surely the application should be in control of playback start when using MSE?

I have the impression that, regardless of when the app starts playback, implementations may only start playing once a certain minimum amount of data has been appended. Similarly some implementations might take some time to start once that minimum amount of data has been appended.

It must be possible to append at least ?? MBytes of data before the coded frame eviction algorithm is triggered.

Presumably the storage quota a vendor would choose to provide will be dependent on the presentation profiles the device intends to support?

Quite possibly.