TobbeEdgeware
commented
4 years ago I think Will's idea on providing the resync info into the MPD is a good one. However, putting requirements byte positions for sync points at byte positions inside segments seems very hard to both achieve and to agree on. In particular, if we should make content that can be the same for both HLS and DASH. I also think that adding extra resync boxes inside the segments is a lot of work and will take time to get propagated into all encoders/packagers.
Therefore I started thinking about a simple solution, which I drop here:
In my view, a virtue of the LL-HLS approach is that allows for short segments (parts) at the live edge and longer segments later back in history. The need for frequent playlist updates are of course a major drawback. Since DASH already has a way of providing segments without MPD requests, I think it would make sense to extend it to provide a template for individually addressable parts similar to LL-HLS.
For example, we could add SegmentTemplate attributes like part="$Representation/$Number$_$PART.m4s" nrParts="12" resyncParts="0,3,6,9" segmentWindowasParts="3" with the interpretation that only the 3'rd last segments can be fetched as individual parts, and parts 0, 3, 6, 9 are resync points. This structure could then describe the whole session in an analogous way to Will's proposal.
This would allow for serving the same segments and individually addressable parts to both HLS and DASH with the same URLs. There would be two different mechanisms to get segments as they are produced:
1) HTTP chunked-transfer encoding 2) fetching individual parts
An optimal client could then use 2 instead of 1 just when joining a session. The CDN would cache the parts in the same way for DASH as for LL-HLS.
haudiobe
wilaw
mstattma
Will,
as discussed in the call, some comments inline:
Thomas
From: Law, Will wilaw@akamai.com Sent: Montag, 24. Februar 2020 18:24 To: Thomas Stockhammer tsto@qti.qualcomm.com Cc: iop@dashif.org Subject: Resync - simplified approach
CAUTION: This email originated from outside of the organization. Hi Thomas
Thanks for putting this deck together.
It seems that the implementation of Resync (especially for live services , which coincidentally is where it is most useful) is all about providing information for the player to parse the media object to find a valid entry point. [TS] This is the last resort if none of the other cases hold. Discussed in details in the client implementation.
This is unfortunate because up to this point much work has been done in DASH to allow a player to play a stream without having to parse any media objects.
[TS] This is not true as we need to parse segments anyways for event messages or SEI messages for 608/708. I understand that this is not the best option, but it is one that potentially provides benefits. We tested the case to submit unstructrured byte ranges into MSE source buffers, but did not work.
This is especially useful for MSE/EME players, where the object requests and ABR logic is decoupled from the box and codec parsing. It is also a strength of the LL-HL:S approach that it explicitly describes each resync point, at the expense of playlist polling. [TS] Understood
It would be a useful extension to Resync if some means were made available to find a resync point only by reading a manifest and without having to poll the manifest at a frequency equal to the chunk duration (as is done with LL-HLS).. One solution would be to indicate a fixed time and byte offset for each resync point in a segment. This could look something like this [TS] As said, this is supported by setting dImin and dImax to the same. On the timing, it says max for now, and we may need a flag to fix this being constant. Good comment for MPEG.
The above snippet describes a low latency stream with 4s segment duration, in which each segment contains 8 resync points each spaced 500ms apart. The beauty of this approach is that the player does not need to parse the media segments in order to switch bitrates at a resync point. The obvious caveat is that the encoder needs to make byte-predictable chunk boundaries. The only way to do this would be to encoder with perfect CBR, or else to have tight-capped VBR and then pad-out each chunk. The padding-out sounds inefficient, however on encoder optimized for this may not present too significant a bit-increase compared to the non-resynce’d stream and the simplicity for players may be well worth that increase, especially for ULL streams.
Has though been given within MPEG to such a scheme? If not, are there any supporters of such an approach? [TS] I added this thread to the MPEG LS information.
Cheers Will