IMSC1 constraints

[mikedo]

Section 15 imposes some constraints that will force re-encoding of the IMSC1 internal timing on the fly, which is really not practical. In particular requiring the internal timing to be Period relative breaks in the ad insertion scenario where the main programming is restarted in the Period that follows the ad insertion Period. This could be adjusted with @presentationTimeOffset but it is forbidden. Also for post-produced IMSC1, it may be a single Segment/sample that is made available for the entire program. It could be copied into many identical Segments (to prevent sparse Segments/samples) and use @presentationTimeOffset to index into a Segment/sample as described in 14496-30. More thought needs to be given to not forcing the live re-encoding of IMSC1 content.

[sandersaares]

This chapter only applies to stand-alone plain text files, not segmented IMSC1/VTT. It exists largely to provide some single point of reference for legacy services that did not encapsulate their text tracks.

None of the constraints apply to segmented tracks (the timing of which is defined in ISO-IEC 14496-30).

Is it really the case that your scenario uses plain text IMSC1? If so, please explain why. If not, perhaps this means we need to make it more obvious that this chapter only applies to plaintext (and maybe also reference -30 for non-plaintext).

[mikedo]

My (ATSC) use case is both broadcast and OTT, both live and post produced, all with ad insertion (aka MultiPeriod). ATSC requires -30 conformance.

Yes, I understand section 15 is about sidecar files and why we have them today (for the same reasons my old CTA-contributed test content to DASH-IF uses an IMSC1 sidecar file).

But I read the document as implicitly recommending sidecar files rather than ISO BMFF. That should be clarified to add something like: “CMAF IMSC1 needs to conform to 14496-30. But If you have existing content with IMSC1 sidecar files, then note that some of the provisions in this section create limitations surrounding Multi-Period, ad-insertion and post-produced content with a single timeline.

[sandersaares]

What about this option: forbid sidecar files in the restricted timing model.

Since this timing model is a new profile, it makes sense to get rid of old legacy cruft that has accumulated (adding this chapter was done without much thought, just because it existed in v4 text in general and seemed useful). But given that it has issues when slicing one up into periods, it doesn't really seem to belong in this profile.

[mikedo]

That would be better, although I don't think it needs explicit forbidding. CMAF requires -30 conformance. Maybe a note? Also, I am planning on a contribution to address IMSC1 Segments since more needs to be said about @presentationTimeOffset. So, I'd prefer we keep the section but remove all the sidecar text. Give me a chance to propose something "soon".

[sandersaares]

although I don't think it needs explicit forbidding. CMAF requires -30 conformance. Maybe a note?

Good point. We can just mentionin that CMAF already assumes it.

Give me a chance to propose something "soon".

I await with interest!