Re: chunked IMSC1

Hi Mike,

I haven’t thought about this, and would have concerns about mid-stream acquisition and the ability for the parser to know if it has completed, in the absence of some elements’ end tags. Those concerns would include not knowing when it is possible for a parser to correctly compute the set of ISDs.

Some years ago we did some research into document size vs duration, and of course there is a trade-off in TTML generally where data rate increases non-proportionally as segment duration reduces, due to duplication of header information. However, it is not clear if there’s a use case for doing that – I don’t believe it is necessary to deliver TTML in chunked HTTP since the data rate in general is low, especially compared to video chunks. Also the time taken to encode video, even for low latency, must be significantly greater than subtitle and caption encoding and I’ve probably assumed that removes the need for chunked delivery of subtitles, which may not be a valid assumption.

I’ve also assumed that the reason for chunked delivery is to begin playback before the document has been fully delivered. Conversely, if it’s okay for the player to wait until the chunked delivery is complete before parsing and presenting the content, then I think the chunked delivery makes no practical difference to any TTML specification.

Not sure if that all helps?

Kind regards,

Nigel



From: Michael Dolan <mike@dolan.tv>
Date: Thursday, 17 March 2022 at 19:34
To: "public-tt@w3.org" <public-tt@w3.org>
Subject: chunked IMSC1
Resent from: <public-tt@w3.org>
Resent date: Thursday, 17 March 2022 at 19:34

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)