Re: chunked IMSC1

Neither IMSC nor TTML reqs explicitly address this use case. Both operate
on "document instances" as their input and require such instances to be
well-formed (in an XML sense).

To do what you suggest, it would be necessary to progressively reparse a
dynamically updated concretely encoded document instance, and only proceed
with subsequent processing (as an XML infoset) for parses that proved well
formed. This might require an underlying buffering layer to append a
temporary postfix to the buffer prior to each parse attempt in order to
supply missing close tags.

If I were designing such a system, I would first evaluate the potential use
of EXI <https://www.w3.org/TR/exi/>.


On Thu, Mar 17, 2022 at 2:34 PM Michael Dolan <mike@dolan.tv> wrote:

> All,
>
>
>
> Has anyone thought about this lately?  In the TTML1 days we pondered it a
> bit.  By “chunked” I mean in the HTTP sense.  That is, an IMSC1 document
> could be broken into pieces and delivered a few bytes at a time say every
> 500ms.  There are low latency use cases that need this sort of delivery
> where decode and presentation continues throughout a certain period. Today,
> when building ISO BMFF segments, one has to gather up all text over several
> seconds, create a well-formed document, and then deliver that well-formed
> document before presentation can begin. This inserts a delay relative to
> how 608 and Teletext work. And, it inserts the same delay into the video
> and audio as well – that is, the decoder cannot start decoding video and
> audio until the text is ready to go.
>
>
>
> Even if no one has pondered this lately, is there interest?
>
>
>
> Regards,
>
>               Mike
>
>
>
> "*keep calm and carry on"*
>
> -----------------------
>
> Michael DOLAN
>
> TBT Inc
>
> Del Mar, CA USA
>
> +1-858-882-7497 (mobile)
>
>
>