Re: Submitted HTML5 bugs and an MSE observation



On 3/17/14, 2:55 PM, "Clift, Graham" <Graham.Clift@am.sony.com> wrote:

>In my understanding the payload_start_indicator is present in the pid
>packet for the particular private section but that the  original
>expectation was that creation of the texttracks was done right after
>deciphering the PMT. Now are you suggesting that the UA doesn't create a
>texttrack until there is a private payload? This adds unnecessary
>complexity IMHO to the UA implementation without much benefit.

I wasn¡¯t suggesting anything. I said that I thought the language in
question was technically correct. It would be simpler if the UA created a
metadata track based solely on the stream_type; no cues would be generated
if there were no private sections.

> 
>
>Also, I am no sure that the UA should be decoding the private section
>table at all according to an ISO spec that is required to be purchased,
>i.e. IS 13818-1.

Presumably a UA that creates MPEG_2 TS text tracks also plays MPEG-2 TS
media and the implementor will have access to the spec.

> Why not just cue the complete 188 byte packets (which would include the
>payload_start_indicator) as they are received and let the application
>decode into relevant data?

Possible I guess but the UA is already processing the streams for the
media resource.

>
>Regards
>
>Graham  
>
>-----Original Message-----
>From: Bob Lund [mailto:B.Lund@CableLabs.com]
>Sent: Monday, March 17, 2014 12:23 PM
>To: Clift, Graham; Silvia Pfeiffer; Ota, Takaaki
>Cc: public-inbandtracks@w3.org
>Subject: Re: Submitted HTML5 bugs and an MSE observation
>
>After rereading the proposed text to resolve the bug, I think it is
>technically correct. Payload_start_indicator == 1 signifies presence of
>private sections. Stream_type == 0x05 by definition contains private
>sections, stream_type == 0x80 - 0xFF may contain private sections. So the
>UA, upon seeing 0x80 - 0xFF, could wait for indication of
>private_sections before creating the metadata track. On the other hand,
>if the UA creates a metadata track for stream_type, say 0xD8, but the
>stream doesn't contain private sections there would be no cues generated.
>
>Bob
> 
>
>On 3/17/14, 1:04 PM, "Bob Lund" <B.Lund@CableLabs.com> wrote:
>
>>
>>
>>On 3/17/14, 11:49 AM, "Clift, Graham" <Graham.Clift@am.sony.com> wrote:
>>
>>>It seems like for TextTrack creation in MPEG-2 TS that detection of
>>>the metadata private section is only through the stream_type code
>>>present in the PMT and that the payload_start_indicator==1 is only
>>>relevant to populating the DataCues that get added to the TextTrack
>>>later.
>>
>>Yes, you©öre right - the payload_start_indicator should not be used to
>>determine metadata track; only the stream_type.
>>
>>> Hence the patch and the wiki page seem incorrect to me when they
>>>suggest the payload_start_indicator==1 is used to detect that there is
>>>a stream type of kind metadata private section.
>>>
>>>This also raises another question which is how are the metadata
>>>private section table cues are generated. If the private section table
>>>is delivered as a payload split across multiple TS packets then
>>>presumably the UA must use the payload_start_indicator bit to begin to
>>>assemble the payload into the single private section table. However,
>>>when does the cue get created unless the UA knows how many packets to
>>>expect?
>>
>>The private_section_length field can be used by the UA to know when
>>it©ös received the last packet for an instance of the table.
>>
>>> My understanding is the UA does not know how many packets to expect
>>>so maybe it generates the cue only when a subsequent
>>>payload_satart_indicator==1 is detected. However, this could be long
>>>past the time when this cue is relevant to the media playback time.
>>>
>>>Regards
>>>
>>>Graham Clift
>>>
>>>
>>>
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
>>>Sent: Monday, March 17, 2014 1:21 AM
>>>To: Bob Lund
>>>Cc: public-inbandtracks@w3.org
>>>Subject: Re: Submitted HTML5 bugs and an MSE observation
>>>
>>>On Fri, Mar 14, 2014 at 5:56 AM, Bob Lund <B.Lund@cablelabs.com> wrote:
>>>> Hi CG,
>>>>
>>>> I have submitted the following HTML5 bugs 24986, 24977, 25005 and
>>>> 25044, reflecting the discussion we've had on the mailing list.
>>>
>>>[HTML editor hat on:]
>>>I've provided feedback and proposed patches in each of these bugs.
>>>Please review.
>>>
>>>Regards,
>>>Silvia.
>>>
>>>
>>>
>>
>
>

Received on Monday, 17 March 2014 21:03:49 UTC