DASH-IF-IOP
DASH-IF-IOP copied to clipboard
Dash-Industry-Forum
SegmentLossTimeline
In case of linear distribution, expected segments may not necessarily be present due to failures in different parts of the end-to-end system (see § 4.8 of DASH-IF IOP 4.0). SegmentLossTimeline allows the packager to state explicitly which segments are missing in a specific representation while all segments available in at least one representation within this adaptation set are still described using AdaptationSet.SegmentTimeline. This makes MPDs smaller and easier to parse. There is no performance improvement or loss for the unaware clients. The aware client, however, saves one or more requests and associated round-trip times. This makes a big difference in keeping the playback buffer size from draining fully, especially in low-latency scenarios where buffers are quite small. SegmentLossTimeline is most useful when the missing segments are specific to one or more representations but not all the representations in an adaptation set. More details are in MPEG contribution m41171. Comments are welcome.
I foresee great risk of lack of interoperability with any construct that allows segments to be missing. At the same time, I appreciate the reality that segments do get lost.
While an important feature that should be implemented in an interoperable way, we should not promote this as something that can be expected to work in mainstream DASH implementations at present day.
Can you be a bit more explicit in terms of what interoperability issues you are foreseeing?
On Mon, Apr 2, 2018 at 10:03 PM, Sander Saares [email protected] wrote:
I foresee great risk of lack of interoperability with any construct that allows segments to be missing. At the same time, I appreciate the reality that segments do get lost.
While an important feature that should be implemented in an interoperable way, we should not promote this as something that can be expected to work in mainstream DASH implementations at present day.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Dash-Industry-Forum/DASH-IF-IOP/issues/157#issuecomment-378012499, or mute the thread https://github.com/notifications/unsubscribe-auth/ARV9qxS8HiR6-Xw7Y1wPxtiCdPvNTr9-ks5tknYegaJpZM4P84bn .
I foresee that many clients will not implement SegmentLossTimeline. The biggest impact it has is on low latency and players doing low latency are, at least currently in 2018, not mainstream. Therefore, content that relies on this mechanism will only work on a subset of specialized players for the foreseeable future. To me, this means such content will not be interoperable.
An alternative solution that is more compatible across different players today is to start a new period on segment loss, dropping the representation that contains a gap. Obviously, this has some drawbacks but in terms of ecosystem interoperability multiperiod is likely to be far better supported by clients for some time to come.
If you do not implement SegmentLossTimeline, there is really not much additional cost to you other than that you get a 404 if you ask for a missing segment and then you make a new request.
Yes, you can make a new period every time there is a loss but in cases where the losses are happening frequently and in different representations, that MPD gets pretty large pretty quickly.
We implemented the new period approach, and had to abandon it. It sometimes resulted in MPDs with way too many periods. In this approach you get a large amount of periods when just a few segments are missing, and if representations come back at different times (Representation A misses 2 segments, while Representation B misses 1). We got to 300 period MPD before giving up. Secondly, you get a large amount of single segment (2-sec) periods which are confusing for a player. Lastly, you typically backfill the missing segments, at which point maintaining all 300 periods makes zero sense. The stopgap approach we went for is creating a hystersis threshold of 3 segments and thus creating a new period in case more than 3 segments are missing. This is an ugly hack, but it removed the vast majority of very short periods.
We have a similar approach but what we do is we delay re-introducing the tracks with a new period if there are gaps, to even out tracks that are not aligned in their gaps. It works "good enough" for now to eliminate very short periods and to avoid giving any 404s to players. Probably the best I can hope for if not targeting specialized players designed to handle this situation.
Nice fix! How long is the threshold (i.e., the amount of segments during which you don't acknowledge return of representation)? What happens when representations start losing segments at different but close times? What happens when you backfill the segment (e.g. a segment was created late due to multicast issues before the packager)?
On Tue, Apr 3, 2018, 09:42 Sander Saares [email protected] wrote:
We have a similar approach but what we do is we delay re-introducing the tracks with a new period if there are gaps, to even out tracks that are not aligned in their gaps. It works "good enough" for now to eliminate very short periods and to avoid giving any 404s to players. Probably the best I can hope for if not targeting specialized players designed to handle this situation.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Dash-Industry-Forum/DASH-IF-IOP/issues/157#issuecomment-378254321, or mute the thread https://github.com/notifications/unsubscribe-auth/AAxMZZqLhqVgRDmRk7qkbiFFYu3nl01bks5tk3xHgaJpZM4P84bn .
How long is the threshold (i.e., the amount of segments during which you don't acknowledge return of representation)?
I am unable to point to any specific number. I believe we use different values in practice but we have not yet collected enough experience and data to arrive at some standard practice.
What happens when representations start losing segments at different but close times?
We have a small lookahead buffer to avoid too much disruption but if it goes past that buffer then we have consecutive period changes, yes, which is a bit unfortunate but acceptable.
What happens when you backfill the segment (e.g. a segment was created late due to multicast issues before the packager)?
We do not use backfilling in our scenario.