CMAF + DASH Ingest - Githubissues

RufaelDev commented 4 years ago

This issue was created based on the MPEG exploration on this topic.

Based on requirements from MPEG additional text for combining interface 1 and 2 (CMAF + DASH) is needed,
In this case we would send an MPD with CMAF profile for DASH to indicate the content is CMAF conforming.

To CMAF ingest interface 1 add:

The client issues an HTTP POST with an MPD describing the set of representations the source intends to provide.

This MPD shall contain a single Period and conform with the following restrictions:

Only $Time$-based addressing
Only relative URLs in BaseURL and SegmentTemplate elements
MPD shall obey CMAF profile (ISO/IEC 23009-1:2019 AMD1)
The period start is zero and the availability start time (AST) shall be a fixed anchor, such as 1-1-1970 (epoch) or another well defined anchor, as to enable efective dual encoder (synchronized encoder ingest)

RufaelDev commented 3 years ago

call 13th november discussion

Important is if we should constrain to only time based addressing carefully
Time-based should be prefereable make it shall for the updated version
CMAF profile should instead of shall

TobbeEdgeware commented 3 years ago

Wouldn't SegmentTimeline with $Number$ be a possible approach? The segment start times and durations would still be in the MPD and allow for bigger variation compared to SegmentTemplate with $Number$. By using URLs with $Number$, it would be easier to use the same segments URLs for both DASH and HLS.

RufaelDev commented 3 years ago

call 20th nov.

check more on hls compatibility with HLS @technogeek00
no significant objections to time based, consider progressing at next cycle

nicoweilelemental commented 3 years ago

Sorry I missed one important point here: Epoch locked encoding will generate segments which names include a monotonically incrementing $Number$ value. We therefore would need $Number$+duration (default preference, as segments durations are stable over time with epoch locking, and that can work with a single manifest upload at the beginning of the encoding session), or $Number$+SegmentTimeline (which can also work by repeating segments with the same duration in the SegmentTimeline, but is not compatible with a one shot manifest upload) for this use case.

Here is an example of MediaLive Epoch locked streams (in HLS, as DASH is not supported on MediaLive): https://ur4a7f5tcty2i4.data.mediastore.us-east-1.amazonaws.com/referencestream_epochlocked/main.m3u8 https://ur4a7f5tcty2i4.data.mediastore.us-east-1.amazonaws.com/referencestream_epochlocked/backup.m3u8

GuillaumeBichot commented 3 years ago

Sorry I missed one important point here: Epoch locked encoding will generate segments which names include a monotonically incrementing $Number$ value. We therefore would need $Number$+duration (default preference, as segments durations are stable over time with epoch locking, and that can work with a single manifest upload at the beginning of the encoding session), or $Number$+SegmentTimeline (which can also work by repeating segments with the same duration in the SegmentTimeline, but is not compatible with a one shot manifest upload) for this use case.

Here is an example of MediaLive Epoch locked streams (in HLS, as DASH is not supported on MediaLive): https://ur4a7f5tcty2i4.data.mediastore.us-east-1.amazonaws.com/referencestream_epochlocked/main.m3u8 https://ur4a7f5tcty2i4.data.mediastore.us-east-1.amazonaws.com/referencestream_epochlocked/backup.m3u8

Nicolas, We are not sure what exactly is Epoch locked in relation with synchonising a main and backup server. The point is that in segment timeline, the synchronisation also work through relying on "tfdt" + duration.

nicoweilelemental commented 3 years ago

Epoch locking allows multiple encoders to align their outputs (segmentation cadence, contents, file names...) without having to communicate with each other. This can be used for main/backup purposes, or to process large bitrate ladders that span across multiple encoders. It works with $Number$.

ZmGorynych commented 3 years ago

@nicoweilelemental I think it works with both $Number$ and $Time$ . $Time$ can be made less sensitive to speed-of-light differences by reusing genlock, SCTE 35 time_signal, or other means of inband time signaling. $Number$ locked to epoch (divide distance from epoch by target segment duration) relies on rounding to nearest integer and thus requires constant segment duration. It will make a distributed system fragile in case of low latency,

P.S. -- speed-of-light distance matters: coast-to-coast ping distance in US can exceed 70ms, and with a ~16ms frame duration for 60fps content you end up with several frames of difference.

nicoweilelemental commented 3 years ago

@ZmGorynych Fine, we can make it work with $Time$+SegmentTimeline too. I guess we don't even really care about the content of the SegmentTimeline, with 'the “timeline extension” technique, where the $Time$ value is inferred from tfdt and not specified explicitly in the SegmentTimeline element of the MPD.' The text says "the above can be achieved using the “timeline extension” technique" which seems to mean that it's not mandatory to do so. In which case the SegmentTimeline will need to be leveraged, which implies regular manifests uploads. We should also be explicit about the exact box requirements of the “timeline extension” technique.

RufaelDev commented 3 years ago

Call 11 Dec: Agreement segment timeline with $Number$ / $Time$ optionally CMAF profile for DASH, timeline extension is used to avoid additional mpd upload requirements. Issues related to epoch locking are discussed in another issue. $Time still preferred

RufaelDev commented 3 years ago

adressed in https://github.com/Dash-Industry-Forum/Ingest/pull/143

Dash-Industry-Forum / Ingest

CMAF + DASH Ingest #111