Manifest Format

[KevinCJohns]

In reading over the Section Overall Media Ingest Protocol Behavior Specification, I am unclear as to what is contained in the Manifest posted by the Encoder and when it is posted. The text implies the Manifest contains a list of Media Segments? and is posted before each segment? I am not sure this is the intent nor that I agree with this approach. IMO, the Manifest should describe the media that will be posted, only posted once and not with each subsequent segment being posted.

Can someone clarify, within the document, what is expected to be contained within the Manifest?

I agree this is key issue, without this we cannot make many assertions about the manifests, so I kept most text around the manifest optional untill this is resolved. In this case the manifest is only used to that passive entities can pass it through, it is not used for the active media processing targeted in the spec.

@wilaw could you follow up on this ?

[wilaw]

I was not envisaging that SegmentList would be used, therefore the manifest would not contain a list of segments. SegmentTemplate/$Number addressing would be sufficient and the manifest only needs to be posted once per session, or when the nature of what the encoder is publishing changes.

Unifed have a strong public position on the use of SegmentTimeline vs SegmentTemplate, which is documented here: http://www.unified-streaming.com/blog/stop-numbering-underappreciated-power-dashs-segmenttimeline. I will point out that most of the issues identified in that blog post have to do with timing, which don't apply in this contribution use case because the origin is not requesting the segments. The ability of SegmentTimeline to describe a gap in content is valid. However, the same gap could be described using SegmentTemplate/Number by adding a new period and updating the manifest.

In this case, using SegmentTimeline would also work for contribution, in the r=-1 mode, which would prevent the encoder having to issue a new manifest with each segment. If the segment durations vary, then a new manifest would have to be sent with each variation in segment duration.

@unifiedstreaming say that "In this case the manifest is only used to that passive entities can pass it through". This is purely the position of Unifed Streaming, who are intent on ignoring the manifest content and instead parsing every media segment to extract the same information. While I respect their right to do that, other active origins may choose to trust the manifest to describe the content and therefore the manifest would have a utility beyond that of a pass-through object.

@wilaw we would like to have an input on the format of the manifest to be used what exact profile etc., this is why this issue is still open. If we don't get input on this it will remain that any manifest can be used. The active passive differentiation is another issue that was already resolved and closed

[wilaw]

The format options would be one of the DASH IF "Simple Live" 4.4 or "Main Live" 4.5 as specified in http://dashif.org/wp-content/uploads/2017/09/DASH-IF-IOP-v4.1-clean.pdf. The difference is really the reliance on embedded EMSG. Since much of the proposal assumes the origin will be parsing the incoming segments anyway, the logical candidate is probably Main Live in sect 4.5 . The relevant profiles are defined at http://dashif.org/identifiers/profiles/

profiles="urn:mpeg:dash:profile:isoff-live:2011,http://dashif.org/guidelines/dash-if-main"

The input spec may want to constrain this even further to allow only one type of addressing. That is a subject of much debate however!

@wilaw thanks for the additional update, this is helpful! Would it also make sense to ingest other types of manifests such as based on HLS that now also supports fragmented MPEG-4 ?