- From: Bob Lund <B.Lund@CableLabs.com>
- Date: Tue, 18 Mar 2014 14:58:34 +0000
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- CC: "Clift, Graham" <Graham.Clift@am.sony.com>, "Ota, Takaaki" <Takaaki.Ota@am.sony.com>, "public-inbandtracks@w3.org" <public-inbandtracks@w3.org>
On 3/18/14, 4:18 AM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote: >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. Done. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=24997#c10 Bob > >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 14:59:08 UTC