Re: Submitted HTML5 bugs and an MSE observation

I am not following this discussion (I don't know enough about MPEg-2),
so if there are any bugs in the patches that I proposed, can you
please post actual text change suggestions in the bug? Thanks.

Cheers,
Silvia.

On Tue, Mar 18, 2014 at 8:03 AM, Bob Lund <B.Lund@cablelabs.com> wrote:
>
>
> 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 Tuesday, 18 March 2014 10:18:50 UTC