search

Dash-Industry-Forum / DASH-IF-IOP

DASH-IF Interoperability Points issue tracker and document source code
32 stars 7 forks source link

Do we want to encourage/discourage restarting a presentation on the same URL? #288

Open sandersaares opened 5 years ago

sandersaares commented 5 years ago

From a Slack chat the topic came up - what if you wish to restart a presentation after signal loss? If you just set a new MPD@availabilityStartTime and start offering content from a new start point, can a service provider expect clients to successfully work? Should clients implement and test for this?

I was unable to find existing recommendations on this point, so I propose we make some.

My first thoughts are: it is difficult to test client behavior in such situations, so good behavior is not easy to ensure. Therefore, we should forbid this and say that live presentation URL shall be unique for each start.

PS. I seem to recall changing MPD@availabilityStartTime being part of the leap seconds topic, which might also have some interaction here.

sandersaares commented 5 years ago

I'm testing many devices: browsers, mobiles and lately lots of OTT tvs and they work great with this "start over", from the point of view of a server it is easy to do that.

Relevant comment in Slack from @leandromoreira

RufaelDev commented 5 years ago

From our perspective we prefer the server to be stateless, hence changing the mpd because a client failed is not something that we consider a good approach as the client behavior needs be tracked. Our preference is signalling the discontinuity instead in the timeline in case of segment loss at higher level (for all clients)

leandromoreira commented 5 years ago

I also prefer the server to be stateless that's why I think that updating the AST is easier and simpler, let me try to clarify:


[Live Transmission Source] --> [ Encoder ] ---> [ Packager ] <--- [ CDN ] <--- [ Client ]

In the up above scenario, it is easier for my packager to restart the timeline when:

  1. the source has failed (for a short period of time but has recovered)
  2. the encoder has failed (for a short period of time but has recovered)

In these scenarios, in order to be stateless, my packager just dectect there was a failure, longer than a short discontinuity, and generate a fresh manifest.

PS: short being longer than 2 x segment size.

RufaelDev commented 5 years ago

I believe you that this can work ant this solves the stateless, but I have doubts that this can be an overall recommended practice, as other functions may be broken (archiving the presentation, DVR window, trick play functions, timed metadata), we would prefer signalling the discontinuity, such as with the segment timeline. This proposal may work for some pure live cases, but I really don't believe it is a good recommended practice overall for the above reasons.