Subject: Repost: WGLC ULE - Data Broadcast

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 08 Feb 2005 11:46:47 +0000

This mail failed to reach the ipdvb list yesterday.

I am forwarding it to the list, see below.

Best wishes,

Gorry Fairhurst
(ipdvb WG Chair)

-------- Original Message --------
Subject: (Fwd) Re: Forward from Art Alison:  WGLC ULE - Data Broadcast
Date: Tue, 08 Feb 2005 09:10:38 -0000
From: Rupert Goodings <[email-masked]>
Reply-To: [email-masked]
To: <[email-masked]>

Gorry

Here is a copy of the mail I *thought* I sent..it went ok and
no bounce seen here.

Rupert

------- Forwarded message follows -------
From:           	Rupert Goodings <[email-masked]>
To:             	[email-masked]
Subject:        	Re: Forward from Art Alison:  WGLC ULE - Data Broadcast 
Descripto rs
Send reply to:  	[email-masked]
Date sent:      	Mon, 07 Feb 2005 14:32:30 -0000

Dear all,

As an interested observer to this discussion there seems to be a
possible confusion here.

For me it is unclear whether the concept of TS Logical Channel (and
the discussions) refer to:

a) all of the MPEG packets/segments in a given PID

b) all of the MPEG packets/segments in a given ULE session.

For (a) I think TS logical channel is good.  Second choice "PID
stream".  Note that I am *assuming* that a single PID can support
multiple "sessions" (I'm not sure what level of submux exactly is
supported here).

For (b) I suggest a new term "ULE Stream".

I don't like the new proposal "SNDU stream" since it doesn't resolve
this ambiguity and possibly makes it worse.

best regards

Rupert Goodings
(observing, not wearing my ETSI hat!)

Date sent:      	Mon, 07 Feb 2005 13:48:43 +0100
From:           	Bernhard Collini-Nocker <[email-masked]>
To:             	[email-masked]
Copies to:      	"Goldberg, Adam" <[email-masked]>,
        	"Allison, Art" <[email-masked]>, Matthew Goldman <[email-masked]>
Subject:        	Re: Forward from Art Alison:  WGLC ULE - Data Broadcast Descripto
  	rs
Send reply to:  	[email-masked]

> Hello,
> 
> let me try to summarize the two major points being raised and what the 
> discussion is about:
> 1. the name/definition of "TS Logical Channel" is not well received and 
> the name/definition of a "SNDU stream" is proposed instead
> 2. it is proposed to consider MPEG-2 conformance in specifying that ULE 
> requires a specific stream_type value for the PMT
> 
> Personally I have no objection against 1., because it is easy to change 
> and improves wording and naming (unless somebody has an even  better 
> name for it).
> For 2. my concern is that mentioning stream_type may require some 
> additional wording about PSI/SI in general, which is likely out of scope 
> of the ULE draft. Even worse, in introducing a "world" besides the 
> encapsulation/decapsulation of ULE, this may result in further confusion 
> about what the MPEG-2/Section layer does in addition to and/or in 
> comparison to ULE/IP. Actually some difficult question may arise from 
> this direction, for example whether it is a wishful requirement for ULE 
> to support PAT/PMT/NIT/INT/... table parsing?
> 
> Any opinions, recommendations or suggestions about this?
> 
> Regards,
> Bernhard
> 
> Goldberg, Adam wrote:
> > 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: [email-masked]; 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: [email-masked] [mailto:[email-masked]]
> >>
> >>On
> >>
> >>>>Behalf Of Gorry Fairhurst
> >>>>Sent: Friday, February 04, 2005 6:56 AM
> >>>>To: [email-masked]; Bernhard Collini-Nocker
> >>>>Cc: [email-masked]
> >>>>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
> >>>
> >>>
> > 
> > 
> 

------- End of forwarded message -------