RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs

["Goldberg, Adam" <agoldberg@sharplabs.com>]

ARGH.  I fat-fingered 'send' before completing the email.  See below.

Adam Goldberg
Director, Television Standards & Policy Development
Sharp Laboratories of America
8605 Westwood Center Drive, Suite 206
Vienna, VA  22182
+1-703-556-4406
+1-703-556-4410 fax
+1-571-276-0305 cell
 

> -----Original Message-----
> From: Goldberg, Adam
> Sent: Monday, February 07, 2005 12:42 AM
> To: 'Bernhard Collini-Nocker'; Goldberg, Adam
> Cc: ipdvb@erg.abdn.ac.uk; Allison, Art; Matthew Goldman
> Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto
> rs
> 
> See below...
> 
> Adam Goldberg
> Director, Television Standards & Policy Development
> Sharp Laboratories of America
> 8605 Westwood Center Drive, Suite 206
> Vienna, VA  22182
> +1-703-556-4406
> +1-703-556-4410 fax
> +1-571-276-0305 cell
> 
> 
> Bernhard Collini-Nocker wrote:
> >
> > Goldberg, Adam wrote:
> > > I apologize for being "late to the party", but:
> > >
> > > I do not see a particular need to define new term "TS Logical
Channel",
> > and
> > > indeed doing so creates risks of ill-specification (such as those Art
> > points
> > > out), as well as confusion heaped upon someone familiar with MPEG-2
> > > Transport (as typically used in entertainment delivery).
> >
> > Unfortunately the MPEG-2 standards do not provide a reasonable term for
> > the purpose of networking. The question is whether other terms, for
> > example "PID network" or "PID stream" would be better received and
> > understood?
> > The term "TS logical channel" tries to verbally visualize that the
> > encapsulation uses a continouos stream of transport stream packets using
> > one specific packet identifier to transport subnetwork data units. Maybe
> > the term "TS (virtual) circuit" better names this?
> 
> It is perhaps not well defined in 13818-1, but the term of art is
> "streams".  Many people use "PID stream" which is a poor combination of
> words.  I'd have no objection to defining a "SNDU Stream" as something
> like "a sequence of MPEG-2 Transport Stream packets identified by a common
> PID value" (or some such).
> 
> Perhaps discussing 'virtual circuits' relative to a Transport Stream is
> begging for confusion.  Use of any such words ("TS (virtual) circuit")
> needs careful definition, likely requiring the above SNDU Stream
> definition plus an explanation of what it means for multiple SNDU Streams
> to exist in a single Transport Stream.
> 
> > > Furthermore, the definition is quite wrong with respect to ATSC and
> DVB
> > use
> > > of "specific TS Logical Channels".  To my knowledge, this internet-
> draft
> > is
> > > the only document anywhere which uses such terms.  It is certainly
> true
> > that
> > > MPEG, DVB and ATSC define //elementary streams// identified by
> > stream_type
> > > values. I suspect this is what is meant by "TS Logical Channel", but
> it
> > is
> > > difficult for me to tell.
> >
> > I am not so sure, whether this analysis is correct. Elementary streams
> > are those that are transported as Packetized ES, whereas "auxillary"
> > data and signalling is transported as sections. Although a stream_type
> > in the program map section is used to reference both PESs and sections
> > the term elementary stream is used very vague and we tried to avoid
> > using it in the same vague manner.
> 
> Perhaps I overstepped with "elementary stream".
> 
> Consider the 13818-1 definition of "Packetized Elementary Stream":  "A
> continuous sequence of PES packets of one elementary stream with one
> stream ID may be used to construct a PES Stream." (ISO/IEC 13818-1:2000 p.
> xiii)
> 
> Stuff carried as payload of Transport Stream packets are merely 'payload'.
> What the draft starts to define is a new type of payload stream (that is,
> a new way to carry data in a transport stream).  The definition is not
> compete.
> 
> > According to, for example EN301192 v1.3.1, defines Data Piping as:
> > " The data broadcast service shall insert the data to be broadcast
> > directly in the payload of MPEG-2 TS packets."
> > That raises the question, how to call a continouos stream of MPEG-2 TS
> > packets with a certain PID?
> >
> > Further the standard details that:
> > "The data broadcast service may use the payload_unit_start_indicator
> > field and the transport_priority field of the MPEG-2 Transport Stream
> > packets in a service private way. The use of the adaptation_field shall
> > be MPEG-2 compliant."
> > ULE uses PUSI and does not utilize the AF.
> >
> > "The delivery of the bits in time through a data pipe is service private
> > and is not specified in the present document."
> > It seems obvious that the use of the term "TS Data Pipe" would lead to
> > the wrong conclusion that ULE equals Data Piping. But Data Piping is not
> > detailed at all, whereas ULE tries to be.
> 
> I'm not going to argue that DVB's specification is complete.  I will argue
> that ULE isn't complete.
> 
> > > (from the draft)
> > >    TS Logical Channel: Transport Stream Logical Channel. In this
> > >    document, this term identifies a channel at the MPEG-2 level [ISO-
> > >    MPEG]. It exists at level 2 of the ISO/OSI reference model. All
> > >    packets sent over a TS Logical Channel carry the same PID value
> > >    (this value is unique within a specific TS Multiplex). According to
> > >    MPEG-2, some TS Logical Channels are reserved for specific
> > >    signalling purposes. Other standards (e.g., ATSC, DVB) also reserve
> > >    specific TS Logical Channels.
> > >
> > > While I'm commenting on this definition, it also seems to me that
> > "channel
> > > at the MPEG-2 level" is either wrong or also ill-specified.  What's a
> > > channel?  If you're talking about MPEG-2, it's certainly conceivable
> > that
> > > the reader may associate "channel" with "[television] channel" - which
> > are
> > > the subject of a large amount of ATSC and DVB systems.
> >
> > The term channel is indeed problematic in the context of television,
> > however, network engineers might have a different understanding about
> > what a channel is.
> > According to ATIS a channel is "1. A connection between initiating and
> > terminating nodes of a circuit. 2. A single path provided by a
> > transmission medium via either (a) physical separation, such as by
> > multipair cable or (b) electrical separation, such as by frequency- or
> > time-division multiplexing. ..."
> 
> I understand that 'channel' vis-à-vis networking has a different meaning
> than 'channel' vis-à-vis television.  This was my point actually, that
> those familiar with MPEG transport should not be assumed to be networking-
> types (even when speaking with respect to ULE).
> 
> > > Additionally, it is also wrong or ill-specified to say "According to
> > MPEG-2
> > > ... TS Logical Channels ...".  There is no such concept defined or
> used
> > > within MPEG (unless what you really mean is elementary stream, in
> which
> > case
> > > what do you need this extraneous term for anyhow?).
> >
> > Again, elementary stream is not exactly what is being meant:
> > For example EN 300468 v1.5.1 defines:
> > "component (ELEMENTARY Stream): one or more entities which together make
> > up an event, e.g. video, audio, teletext"
> >
> > and says further:
> > "The component descriptor identifies the type of component stream and
> > may be used to provide a text description of the elementary stream"
> >
> > where:
> > "component_type: This 8-bit field specifies the type of the video, audio
> > or EBU-data component. The coding of this field is specified in table
> 26."
> > Table 26 then lists all kinds of video, audio, and teletext formats, but
> > unfortunately no networking formats.
> >
> > At other places this standard is as innovative/creative in naming:
> > "event: grouping of elementary broadcast data streams with a defined
> > start and end time belonging to a common service, e.g. first half of a
> > football match, News Flash, first part of an entertainment show"
> > What is a "elementary broadcast data streams"? Not by guessing but by
> > definition?
> >
> > > In any case, Art is certainly correct that merely identifying a "TS
> > Logical
> > > Channel" as a sequence of packets identified with a common PID value
> > without
> > > identifying the PSI details is an invitation to multiplexers and
> > > remultiplexers to drop those packets on the floor.
> >
> > Oh yes, this is the real problem of defining something outside
> > television standardiszation bodies: one risks that ULE packets are being
> > dropped.
> > We have discussed basically two approaches:
> > 1. define the PSI and get an ID, or tag, or "stream_type" for ULE, or 2.
> > define ULE and let somebody else do the PSI work.
> > We have had some reasons for choice 2.
> 
> This is a very easy thing to fix and something which should be done.
> Without defining a stream_type for ULE data, it is neither possible to
> construct a transport stream compliant with MPEG-2 nor one that
> interoperates with other ULE equipment.
> 
> ATSC maintains a 'codepoint registry', and would be happy to allocate a
> stream_type value for ULE data upon request from IETF.  Furthermore, the
> text to specify usage of the stream_type would be reasonably easy (and
> perhaps ties in to my suggested "SNDU Stream" definition (that is, define
> it as

SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified by a
common PID value of stream_type <0xnn>.

All that then remains, I think, would be to signal when a Program carries
SNDU Stream(s), and what it means when there are more than one SNDU Stream
per program, or more than one Program that carries one or more SNDU Streams.

> > > If there remains an opportunity to repair what I believe to be errors
> in
> > the
> > > draft, I'm eager and willing to participate from a MPEG-2
> entertainment
> > > (which is to say, legacy use of MPEG-2 Transport) point of view.
> >
> > Of course the terms in the document should not conflict with meaning in
> > another context. However, ambiguous terms in other documents should be
> > avoided as well.
> >
> > > [Apologies for being strident at all, to say nothing of at such an
> > > apparently late stage - if the above is perceived as such]
> > >
> > > Regards,
> > > Adam Goldberg
> > > Director, Television Standards & Policy Development
> > > Sharp Laboratories of America
> > > 8605 Westwood Center Drive, Suite 206
> > > Vienna, VA  22182
> > > +1-703-556-4406
> > > +1-703-556-4410 fax
> > > +1-571-276-0305 cell
> > >
> > >
> > > -----Original Message-----
> > > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]
> On
> > > Behalf Of Gorry Fairhurst
> > > Sent: Friday, February 04, 2005 6:56 AM
> > > To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker
> > > Cc: AAllison@nab.org
> > > Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast
> > Descriptors
> > >
> > >
> > > 1) Done - point 1 was an edit mistake.
> > >
> > > 2) I think some text on data broadcast descriptors, stream-type,
> or/and
> > PSI
> > > entries would be a valuable addition.
> > >
> > > On thinking about this, I wonder if the text about this should go at
> the
> > end
> > >
> > > of the Introduction (1.0) to the whole document, where people can see
> it
> > > clearly and then undesrtand that there may be something else needed
> for
> > > those
> > > networks that rely on PSI for remultiplexing!
> > >
> > > - Bernhard & others who understand PSI, can you work with Art to agree
> > the
> > > exact wording please?
> > >
> > > Gorry Fairhurst
> > > (ipdvb WG Chair)
> > >
> > > Gorry Fairhurst wrote:
> > >
> > >
> > >>WG please read and respond to this message.
> > >>
> > >>The following message was received on January 22nd before WGLC, but
> was
> > >>dropped because the email source address was not verified by the list
> > >>server.
> > >>
> > >>The exact text of the message follows.
> > >>
> > >>best wishes,
> > >>
> > >>Gorry
> > >>(ipdvb WG Chair)
> > >>
> > >>-----
> > >>
> > >
> > > 1)
> > >
> > >>Thanks for considering my previous input...
> > >>I note that the new draft has an editorial oversight in that it
> contains
> > >>two definitions of PSI. I suggest the second should be deleted.
> > >>
> > >
> > > 2)
> > >
> > >>I previously made a comment about the ancillary requirements when
> adding
> > a
> > >>TS logical channel to a TS multiplex and asserted there appeared to be
> > >>under
> > >>specification. Perhaps it was viewed as out of scope, or perhaps I
> > simply
> > >>don't recognize the change that resulted.  I can not find what
> > stream_type
> > >>is required to be used for the ULE stream when a "TS Logical Channel"
> is
> > >>added to a multiplex.
> >
> > The problem here is the same as above. Without "applying" for a
> > "stream_type" for ULE there is no stream_type for ULE. In contrary why
> > should one register a stream_type value for ULE earlier than ULE is
> > standardized?
> >
> > >>I suggest at least an informative note be added in Section 6 (after
> the
> > >>third line which says: "These are transmitted using a single TS
> Logical
> > >>Channel over a TS Multiplex.") The note should say "PSI entries to be
> > >>consistent with [ISO-MPEG] when constructing a conformant TS Multiplex
> > and
> > >>means for Receivers to locate each such TS Logical Channel are outside
> > the
> > >>scope of this recommendation."
> >
> > Thanks, this is a very helpful suggestion for potential readers. In
> > addition the ipdvb-wg works on providing signalling other than PSI/SI.
> >
> > >>Reason:
> > >>Just inserting a "TS Logical Channel" without including a
> > >>TS_Program_map_section that lists the PID and a stream_type does not
> > >> appear to me to result in a strictly MPEG-2 conformant bit stream;
> and
> > >> practically
> > >>could result in the PIDs being dropped by a remultiplexer.   If the
> > means
> > >>for binding the inserted element into a multiplex and subsequent
> > discovery
> > >>is to be covered in another document, a pointer to that document would
> > be
> > >>more helpful than this warning. It seems at least a warning is needed
> > and
> > >>preferably a pointer to where this next level of TS construction is
> > >>defined.
> >
> >  From an architectural point of view it is a reasonable assupmption that
> > whatever is being sent in a TS multiplex should be referenced. However,
> > the reality is that "ghost" PIDs do occur in many services either
> > accidentially or for well-defined reasons.
> >
> > What is the penalty for not being strictly MPEG-2 conformant/compliant?
> >
> > >>Art Allison
> > >>Director, Advanced Engineering
> > >>NAB Science & Technology
> > >>1771 N St NW, Washington Dc 20036
> > >>202 429 5418
> >
> >
> > Regards,
> > Bernhard Collini-Nocker
> >
> >