SmoothStreaming: Support LiveBackOff (and any other necessary latency parameters)

[dobrusev]

Hello,

Recently the live stream content was reconfigured and chunk size changed from 6 seconds to 2 seconds and I start receiving error 412 for loading the content chunks. Instructions that I have are that I have to make the bufferingTime to 12 seconds and liveBackOff to 6 seconds.

I tried different combination changing the BUFFER_SEGMENT_SIZE, VIDEO_BUFFER_SEGMENTS and LIVE_EDGE_LATENCY_MS but nothing works.

What is that I'm missing here?

If needed I can send manifest url to the email.

Regards

[ojw28]

If you're getting a 412 status code, that sounds like a server issue?

[dobrusev]

yes it is a server issue but the answer I have is "the server will return 412s if the playhead is too close to the live point. We need to increase the buffer time and live back off figures as before."

Documentation for the BufferingTime and LiveBackOff SS properties: https://msdn.microsoft.com/en-us/library/microsoft.web.media.smoothstreaming.smoothstreamingmediaelement.bufferingtime%28v=vs.95%29.aspx?f=255&MSPPError=-2147217396

I guess LiveBackOff for ExoPlayer is LIVE_EDGE_LATENCY_MS.

Does that make sense?

[ojw28]

Got it. I think our current implementation works on the assumption that any segments listed in the manifest are available from the server. We'd probably need to add support for parsing and applying LiveBackOff to support your content; there's no existing way to achieve something equivalent in the library.

[dobrusev]

I understand.

Another question: "are we 100% confident that the segments listed in the manifest are not available, or is the exoplayer simply calculating what it expects as the next segment URL? i.e. the segment URLs are predictable in their pattern, so the player could be requesting future segments that aren’t actually described in the manifest..."?

[ojw28]

We don't infer future URLs. I'm not sure I fully understand why you'd list segments that aren't available in conjunction with LiveBackOff. Suppose LiveBackOff=10 and there are 10s worth of segments not yet available. Why wouldn't you just list 10s fewer segments and set LiveBackOff=0? It feels like it would be pretty much equivalent, and less error prone.

[dobrusev]

You are right if the segments are not available they should be not part of the manifest.

I'm working now to provide evidence to the content provider that the segments in the manifest are not valid and ideally this should be fixed on server side. any ideas how can I do that?

What we see on other players though is that they handle those live streams nicely without error and smooth playback.

Also spend some time looking into the the exoplayer code. Saw that in SmoothStreamingChunkSource class there is a property called currentManifestChunkOffset. Will setting it with a default value make a difference and work around the current issue?

Thanks in advance!

[ojw28]

I'm working now to provide evidence to the content provider that the segments in the manifest are not valid and ideally this should be fixed on server side. any ideas how can I do that?

It should be pretty easy to verify that the most recent segments aren't available (just by fetching the latest manifest, parsing the latest segment, and trying to request it).

What we see on other players though is that they handle those live streams nicely without error and smooth playback.

As an aside: Just because it works doesn't mean its handled nicely. Players may do things like hammer the server until the segment becomes available, for example. Unless you're looking at the requests using Wireshark or something, it's quite hard to validate how nicely (or otherwise) the case is handled.

Also spend some time looking into the the exoplayer code. Saw that in SmoothStreamingChunkSource class there is a property called currentManifestChunkOffset. Will setting it with a default value make a difference and work around the current issue?

There is no way to work around this issue.