[Bug 24997] Add "Return values for Text.kind" table

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

--- Comment #12 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(In reply to Bob Lund from comment #10)
> (In reply to Bob Lund from comment #7)
> > (In reply to Bob Lund from comment #6)
> > > (In reply to Silvia Pfeiffer from comment #5)
> > > > I have prepared a patch for this in a branch at
> > > > https://github.com/w3c/html/commit/f91c1932220ab4272d2b2b4e6c9f3679251fefa1 .
> > > > 
> > > > Could you please check that this is all correct, in particular for MPEG-2,
> > > > MPEG-4 and DASH (I checked Ogg and WebM and am quite confident on those).
> > > 
> > > For MPEG-4 metadata text track, you've used a list of sample entry codes
> > > instead of 'meta' handler type. Beyond, 'mett' and 'metx', I do not know if
> > > this list is accurate or not.
> > > 
> > > The table for setting text track kind, label and language looks good. 
> > 
> > While the phrase "contain private sections ("payload_unit_start_indicator"
> > == 1)" for identifying an MPEG-2 TS metadata text track is technically
> > correct, it requires the UA to wait for private section before creating the
> > text track.
> > 
> > It might be more simple for the UA to create a metadata text track for
> > MPEG-2 TS stream_type 0x05, 0x80 - 0xff without waiting for a private
> > section indicated by a payload_unit_start_indicator == 1. If none are ever
> > received, no private section cues would ever be created.
> 
> I think the UA should create the metadata text track for these stream_types
> and NOT wait for packets to determine the payload_unit_start_indicator;
> script will know what to expect.
> 
> So, the specific change is at line 33161 in
> https://github.com/w3c/html/commit/f91c1932220ab4272d2b2b4e6c9f3679251fefa1.
> Drop the text "contain private sections ("payload_unit_start_indicator" ==
> 1)"

OK, fixed:
https://github.com/w3c/html/commit/bdb060f7c6a3836ef04e91d291cc50b8c63b8f10

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

Received on Monday, 24 March 2014 04:33:57 UTC