Subject: RE: Allocation of a stream descriptor for MPEG-2

From: "Allison, Art" <[email-masked]>
Date: Mon, 14 Mar 2005 14:57:05 -0500

Well, of course, non-standard means can be used, but by definition, these
are not Standard/RFC means. Non-MPEG-2 means can be used as well. But I
don't see any relationship of those facts to the discussion on the table.
(A transponder full of just ULE packets would clearly not be MPEG-2
complaint, and would be at least suboptimal to use packetization with such
heavy (2.1%) overhead in such a transponder.) 
So suggesting that one can rent the entire TS does not answer the question
which was clear to me from the thread context.  I read Mr. Dolan's question
to be the same as the longer question: "How will you know without ambiguity
in a Standard manner that the stream contains ULE packets if you don't?"

I have reviewed Mr. Dolan's contribution and am convinced he has outlined
how to send ULE packets in a way that uses the MPEG-2 transport in a way
that is not only consistent with 13818-1 but also is consistent with ATSC. I
am less expert with DVB, but it appears to be consistent with DVB transport
as I understand it as well. 

As to  MPEG-2 users standards 'magic'; well, sorry if this is sufficiently
advanced technology that the difference is not discernable... but how to put
ULE packets into the MPEG-2 transport stream so that MPEG-2 TS systems work
well simply uses private table section structures that are linked with
pointers.
And you seem to be referring to the ULE encapsulation -- that is not on the
table to discuss as that RFC is moving on in the process -- we are now
addressing how one standardizes how this class of packet is not confused
with other packets in a Standard MPEG-2 transport stream. 
    
Only if one asserts that ULE packets are never expected to be used with any
other packets in an MPEG-2 TS can one sustain a claim that there is no
standardization needed.

Discussions of non-standard alternatives may be interesting but it is hard
to see how they progress development of the standard means/RFC. 

I support documenting Mr. Dolan's contribution as the approach to
identifying and enabling location of ULE in MPEG-2 TSs.
__________________
Art Allison
Director, Advanced Engineering
NAB Science & Technology
1771 N St NW, Washington Dc 20036
202 429 5418 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carsten Bormann
Sent: Sunday, March 13, 2005 6:56 PM
To: [email-masked]
Cc: Carsten Bormann
Subject: Re: Allocation of a stream descriptor for MPEG-2

On Mar 13 2005, at 23:50 Uhr, Michael A Dolan wrote:

> How will you know without ambiguity that the stream contains ULE 
> packets if you don't?

By previous agreement. (E.g., after renting an entire transponder
exclusively for ULE packets.)

What I'm trying to say is that the ULE encapsulation is not dependent on the
DVB/ATSC magic around it doing its thing (or, more precisely, is only
dependent on it if that magic is in actual use by some component on the
way).  So it would be a mistake for ULE to stipulate that those tables are
maintained properly.

Or, in other words, if the DVB/ATSC magic is required to properly transport
the ULE packets, this is not a conformance requirement on the ULE packets,
but on the system that injects them into the DVB/ATSC world.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Mar 2005 21:29:56 +0100

> with other packets in a Standard MPEG-2 transport stream.

Ah, you seem to be addressing writing a new document that describes 
this mapping.
This is certainly one good way to do this.

In Minneapolis last week, we discussed the possibility of inserting the 
code point for the stream descriptor into the existing ULE document, in 
an "IANA action" like way (i.e. late in the RFC editor pipeline).
Only in that context does my comment (the MPEG tables should not be a 
mandatory part of the ULE encapsulation) make any sense.

Gruesse, Carsten

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 15 Mar 2005 20:59:15 +0000

See below...

Carsten Bormann wrote:
> Ah, you seem to be addressing writing a new document that describes this 
> mapping.

Ah, yes Carsten, I now see where the confusion may have come from. Indeed, the 
suggestion at the working group meeting was that we should try to define one 
or descriptors that could be directly referenced as a small addition to the 
ULE RFC.  There is still a small time period in which we could propose such a 
final addition to ammend the document (with IESG approval), before it is 
published as an RFC.

I suggest this is worth considering, since such descriptors are *required* in 
the context of MPEG-2 TV networks. If we need to describe more of the 
mechanisms by which this should be done, we could include this as a part of 
the Address-Resolution (AR) Working Group document, when this is written.

Gorry