[Bug 21431] Specify splicing behavior for text tracks

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21431

--- Comment #12 from Glenn Adams <glenn@skynav.com> ---
(In reply to comment #11)
> Discussed at the F2F meeting. Glenn will provide non-normative text to
> indicate that the format of the text track might override the default
> behaviour.

I'm not completely finished reviewing the current spec text, but at first order
I think we may need to qualify some of the terms used in 3.5.7 Coded Frame
Processing step 1 sub-steps 12-13:

* spliced frame => audio spliced frame
* overlapped frame => overlapped audio frame
* overlapped frame presentation timestamp => overlapped audio frame
presentation timestamp

Then, copy sub-steps 12-13 into new sub-steps 14-15, replacing 'audio' with
'text'.

Then, introduce new section 3.5.12 Text Splice Frame Algorithm with content
[TBD - I will propose something shortly].

I think we also need to add notes under 3.5.7 steps 1 and 2 regarding
presentation and decode timestamps for timed text "frames", since (1) these are
often not identified as such in timed text formats, (2) some time text formats
require processing in order to serialize time intervals, and (3) some time text
formats have only an implied (or even no) presentation or decode timestamp. For
example of the latter, consider a "metadata" text track which is used to expose
MPEG-2 PSI data (PAT, PMT).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 7 May 2013 15:30:23 UTC