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

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

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: Marie-Jose Montpetit [mailto:mariejose.montpetit@verizon.net]
> Sent: Monday, February 07, 2005 3:56 PM
> To: ipdvb@erg.abdn.ac.uk
> Cc: Goldberg, Adam; Allison, Art; Matthew Goldman
> Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto
> rs
> 
> I think we need to close on some of those issues and move forward.
> 
> Here is what I propose which would be inline with the conclusions of the
> Architecture Draft:
> (1) ULE is encapsulation only - it is not the purpose nor the usage of ULE
> to dwell in SI/PSI table issues nor any other protocol; so we leave the
> draft to be mostly what it is now (pending small changes proposed by
> Gorry)

This becomes a bit self-referential.  The proper definition of the data
stream is to say something like "a stream of stream_type 0xNN", but you
propose not doing this until later.

> (2) PSI/SI scanning is part of  the Address Resolution Draft as regard
> management of addressing; it will be further discussed there and focus
> given
> to the issues raised in this thread

Can someone provide a pointer to the "Address Resolution Draft"?

> (3) Someone (Adam and/or team) proposes WG work and a draft on ATSC
> concerns
> on PSI/SI issues and ULE; inclusion of cable TV concerns in addition to
> satellite would be welcome and has been one of my goals for the group
> (4) we close on ULE and get to discuss the other items further at IETF

Don't misunderstand my concerns (or Art's, I suppose) - they are not "ATSC
concerns" so much as concerns from one overly familiar with MPEG-2 Transport
Streams and their widespread use.


> 
> Thanks
> 
> Marie-Jose
> 
> ----- Original Message -----
> From: "Gorry Fairhurst" <gorry@erg.abdn.ac.uk>
> To: <ipdvb@erg.abdn.ac.uk>
> Cc: "Goldberg, Adam" <agoldberg@sharplabs.com>; "Allison, Art"
> <aallison@nab.org>; "Matthew Goldman" <mgoldman@3gfp.com>
> Sent: Monday, February 07, 2005 8:54 AM
> Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto
> rs
> 
> 
> >
> > So....
> >
> > 1. The term "TS Logical Channel" was discussed a lot at the begining of
> the
> > WG. As I recall, the reason for the new term, was that at this time the
> WG
> > could not find a suitably "unbiased" term for the set of TS Packets with
> a
> > common PID value (raw TS, DSMCC, Private Section, PES, etc). One key
> objective
> > was to find a term that did not carry extra semantics, and was
> understandable
> > by the networking community - this is after all intended as a part of
> the
> > RFC-series, and we need to make this accessible to people familiar with
> using
> > IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc.
> > T
> >
> > we shoudl note that the term "TS Logical Channel term already appears
> (and
> is
> > discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt
> and
> that
> > this HAS already complete WGLC.  If it IS WRONG we still have a chance
> to
> fix
> > the definition/term, if we have to. Specifically, is there already a
> > well-accepted term for the set of TS Packets with a common PID value
> (raw
> TS,
> > DSMCC, Private Section, PES, etc) that we should use or refer to?
> >
> >
> > 2. I'm not against defining another term "ULE Stream", "SNDU Stream",
> etc
> if
> > that helps to describe the set of TS packets with a specific PID used
> for
> ULE,
> > especially when talking about PSI.
> >
> > Bernhard, is there an opportunity of inserting a simple statement as the
> final
> > paragraph of the introduction which says that to use ULE streams within
> an
> > MPEG-2 compliant multiplex may require appropriate PSI entries... I
> think
> Art
> > already proposed some specific wording that could be used or modified?
> >
> >
> > 3) Once teh ULE spec is agreed and an RFC number issued, I can also see
> great
> > advantage in assigning a descriptor for this in ATSC. I think the WG
> SHOULD
> > should explore this at the next stage.
> >
> >
> > Gorry
> >
> > Bernhard Collini-Nocker wrote:
> >
> > > 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: 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
> > >>>>
> > >>>>
> > >>
> > >>
> > >
> > >
> >