[Dash] Support negative @r in SegmentTimeline

[SLepUbIn]

Hi, when trying to parse this .mpd playlist from DashIf test vectors : http://dash.edgesuite.net/dash264/TestCases/2c/qualcomm/1/MultiResMPEG2.mpd

the negative @r in <SegmentTimeline><S d="24576" r="-1" /> gives me an empty list of representation method getFirstSegmentNum() returns 1 but trying to access a representation causes java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 The specs say :

A negative value of the @r attribute of the S element indicates that the duration indicated in @d attribute repeats until the start of the next S element, the end of the Period or until the next MPD update.

How could I deal with that ? Manually editing the playlist and replacing "r=-1" by the actual number of chunks works fine, but obviously I can't rely on that. Thanks !

[ojw28]

This is something we'd need to add support for. Marking as an enhancement. It should be noted that this kind of manifest is pretty obscure. I'm fairly sure they could just omit the SegmentTimeline completely and inline the segment duration into the SegmentTemplate element, like:

<SegmentTemplate timescale="12288" duration="24576" media="ED_512_640K_MPEG2_video_$Time$.mp4" initialization="ED_512_640K_MPEG2_video_init.mp4"/>

As an aside, I notice you've filed a few bugs about obscure DASH manifests. What's the actual use case your developing for? The DASH spec is so broad it's not generally a sane goal to play arbitrary DASH manifests. Pretty much every service provider generating DASH manifests will do so according to a significantly more constrained (and sensible!) DASH profile.

[SLepUbIn]

Hi, and thanks for the feedback again ! It's very much appreciated. Actually I'm only beginning to interest in the MpegDash specs. And as you said above, the spec is very broad. So I was trying some playlists found on the two websites I have referred to in the 2 issues I opened. And I just happened to find some corner-cases that needed some explanations. So everything is ok on my side, I think you are right, most of the playlists do not fall in the "obscure" category and smart service providers will try to make things less error prone.

[ojw28]

No worries, and thanks. Please do continue to report edge cases as you find them. It's useful to know of cases we don't support even if we decide that we don't want to support them. For this one, we will aim to support the case, but it's low priority since I'm not aware of any providers who are generating this style of manifest in production.

[zhanghuicuc]

Hi, I have met the same problem. I think that you can't just omit the SegmentTimeline completely and inline the segment duration into the SegmentTemplate element. As the spec said: "A negative value of the @r attribute of the S element indicates that the duration indicated in @d attribute repeats until the start of the next S element, the end of the Period or until the next MPD update." So there may be something like <SegmentTimeline> <S d="24576" r="-1" /> <S d="96000" r="100" /> </SegmentTimeline>

Thanks.

[ojw28]

You can definitely omit the SegmentTimeline. There is no requirement for one to be present and there's typically only value in including one if some segments are of different duration than others.

We're aware that r=-1 is valid according to the spec, as already indicated above. We will get around to fixing it at some point, but would still advise omitting SegmentTimeline in the case where all segments are of equal duration, since its inclusion in unnecessary.

[Mr-Clam]

As an encoder implementer, we don't think that this is an obscure feature. For live events in particular, we have to cope with gaps or missing frames. This can result in varying duration segments if the missing frames occur at the segment boundary. Akamai require their qualified encoders to wait up to 30s per MPD update, and it seems the negative r value is the most efficient way to handle this situation.

Also note that although this is an optional item in the DASH spec, this surely is only optional to encoders/packagers. Decoders/players should implement the whole spec, although I can see that you need to prioritise the order you implement the required features.

[ojw28]

It's not particularly viable to implement the whole DASH spec. It's also not a great way to invest time because it contains a long tail of features that are rarely used.

I don't think I fully understand the case you describe, because I don't see that missing frames would result in the segment duration changing. Every time you shorten the duration of a segment the player will move slightly closer to the live edge, because you're misrepresenting time. That would most likely have undesirable consequences (e.g. the player will end up maintaining a smaller buffer than it intended). It seems preferable to have a segment with the correct real-time duration that has some frames missing. I'm also not sure how r=-1 helps, since it doesn't help with specifying that a segment has a different duration. Please can you clarify exactly how this case works? Thanks!

[ojw28]

Note: I've also seen quite a few providers generating live stream MPDs that use only SegmentTemplate and so have a completely fixed segment duration. Which suggests this is not an insurmountable problem.

[ojw28]

Support was added in https://github.com/google/ExoPlayer/pull/6286.