Original text:
of the past 30 seconds and replay them in order to "synchronize" the video decoder.  4.9. 4.9.1.

Reviewer comments:
I suspect this may require a little bit more thought, but want to sense-check the direction. NAME any feedback you have would be welcome.
NAME NAME thank you both for your feedback, I've rewritten the block again based on your feedback and hope this is a lot more clearer.
MoQ Transport, in combination with a MoQ Streaming Format, needs to support mechanisms to allow ad insertion. This ad insertion: Should be compliant with current IAB and SCTE standards such as SCTE-35, which specifies signals that can be used to identify advertising breaks, advertising content, and programming content. VAST (Video Ad Serving Template) VPAID (Video Player Ad-serving Interface Definition) VMAP (Video Multiple Ad Playlist) Should be able to participate in both server-side and client side ad insertion schemes. The server-side solution may have a mode in which the ad is stitched seamlessly into the primary content and the ad boundaries are indistinguishable to the client. Should be dynamic in nature, allowing for just-in-time decisions to be made for choosing which content to insert. Should allow access to, and compatibility with, a subset of existing ad inventory.
Some of my initials thoughts: To stick to the separation model of "church and state", we should also have agility to support more than SCTE-35/IAB specs in the transport layer Is it required that all streaming formats must support event tracks? Or is the requirement here that just the transport through the catalog enables it? Is there a benefit to describing these requirements more generically - although enabling advertising for live broadcast is clearly the obvious use case having this functionality could be useful for other reasons, such as: In teleconferencing, a presenter switching one (or all) viewer's video to a different source such as the slide show or the presenters camera Falling viewers over to another source when the current one ends e.g Twitch's "raiding"
Given the PR above is merged, I'm closing this noting the above issue on ingest will carry on.

Revised text:
of the past 30 seconds and replay them in order to "synchronize" the video decoder. <ins> 4.8.6. In all of the applicable use cases defined in overallusecases it may be necessary for consumers to be aware of changes to the source of media being inserted, or be instructed to consume media from a different source.  These may be done for the insertion of advertising or for operational movement of consumers, amongst other reasons. Within the media insertion scenario an existing stream being consumed may change as a result of a different source being spliced which necessitates the decoder being reset as parameters such as video frame rate, image resolution etc may have changed.  For redirection, consumers may be signalled to consume media from a different source which may also require re-initialization of decoder. In both of these scenarios, triggering may occur either through an event provided in the media such as a SCTE-35 marker, or through an external trigger.  Both should be supported. </ins> 4.9. 4.9.1.