How to set initial buffer size for faster playback start

[biswarupdasgupta]

Hi,

Wanted to know which parameter we can set for initial buffer size in dashjs so that playback can be started faster?

We are playing media files where each segment is of 4s. Hence we want to set the buffer size such a way that playback can start after downloading 2 segments i.e. 8s

Any pointers will be very helpful.

Thanks.

[dsilhavy]

@biswarupdasgupta I did some investigation on that, and it looks like minBufferTime is ignored during startup. So dash.js starts playback as soon as there is data in all SourceBuffers. I am not sure when and why this was introduced. In any case it is not spec compliant:

The client buffers media for at least a duration matching the value of @minBufferTime attribute before starting the presentation

We will change this and add a parameter to control the minBufferTime via API.

[dsilhavy]

We discussed this with @haudiobe in the IOP Testasset call:

• The sentence from above taken from the MPEG spec is a little confusing Thomas will bring this up in the MPEG call
• It is ok to start playback as soon as a segment is in the buffer. However, certain restrictions apply for low latency streaming. We should not start playback with a single chunk in the buffer
• @minBufferTime is intended to account for bandwidth fluctuation or segments with different bitrates. For instance if the content provider uses a capped CRF encoding segments will have different sizes.

@haudiobe : What happens if the player runs into an empty buffer and has to fill its buffer again. Should we wait for @minBufferTime to be reached or should we start playback again as soon as data is in the buffer again.

[wilaw]

4th edition of DASH spec is a little clearer. It specifically says that "The value of the minimum buffer time does not provide any instructions to the client on how long to buffer the media". It is a terribly named attribute and everyone confuses it as an instruction for how to set the player's starting buffer.

I think dash.js should continue to ignore the @minBufferValue in the manifest for startup buffers and instead you should provide a separate API which the player developer can use to set the desired starting buffer.

[acbegen]

We should get rid of minBufferTime once and for all :)

[biswarupdasgupta]

@biswarupdasgupta I did some investigation on that, and it looks like minBufferTime is ignored during startup. So dash.js starts playback as soon as there is data in all SourceBuffers. I am not sure when and why this was introduced. In any case it is not spec compliant:

The client buffers media for at least a duration matching the value of @minBufferTime attribute before starting the presentation

We will change this and add a parameter to control the minBufferTime via API.

@dsilhavy what is meant by when there is data in all SourceBuffers ? If we have segments each of 4s, by what time we should expect playback to start? Do we need to define the number of source buffers to control playback start time?

[dsilhavy]

@biswarupdasgupta It depends on the download time of the segments. If your content has audio and video dash.js will create two SourceBuffer objects (one for audio one for video). As soon as there is audio and video data in the SourceBuffers playback should start.

[biswarupdasgupta]

Hi @dsilhavy , does this mean playback will start as soon as one decodable segment of audio and video are downloaded?

[dsilhavy]

Yes if you enable autostart playback will start immediately

[biswarupdasgupta]

Thanka @dsilhavy

[dsilhavy]

Added setting to define an initial buffer level when playback is started:

       buffer: {
                initialBufferLevel: NaN
            }

Available in nightly: http://reference.dashif.org/dash.js/nightly/samples/