RE: Submitted HTML5 bugs and an MSE observation

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. 

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. 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?

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 20:56:31 UTC