Subject: RE: Proposed Changes to ULE text - Format descriptors for SI signalling

From: "Allison, Art" <[email-masked]>
Date: Fri, 29 Jul 2005 15:06:02 -0400

If the insertion is not mandatory, one cannot rely upon its presence.
If not present, how is a conflict with another private use that has a
structure that is close to ULE prevented/resolved.

Recommend RTR: " Transport Streams that utilise the Programme Map Table
(PMT)
    defined in ISO 13818-1 [ISO-MPEG2] and that use the ULE
    format defined in this document, SHALL insert a descriptor with
    this value in the PMT ES_info descriptor loop."
__________________
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]] 
Sent: Wednesday, July 27, 2005 2:47 PM
To: [email-masked]
Subject: Re: Proposed Changes to ULE text - Format descriptors for SI
signalling

After receiving a few suggestions, I now propose better text for the
description of the format identifier:

Page 3, Section 1 (Introduction):
AFTER:
   "The MPEG-2 specification [ISO-MPEG2] requires conformant TS
    Multiplexes to provide Program Specific Information (PSI) for
    each stream in the TS Multiplex. Other MPEG-2 based transmission
    standards may also define Service Information (SI)."
                                                       ^ INSERT BLANK
LINE AND NEW PARAGRAPH after the above:
   "A format_identifier value has been registered for ULE [ULE1].
    This 32 bit number has a hexadecimal value of 0x554C4531.
    Transport Streams that utilise the Programme Map Table (PMT)
    defined in ISO 13818-1 [ISO-MPEG2] and that use the ULE
    format defined in this document, SHOULD insert a descriptor with
    this value in the PMT ES_info descriptor loop."

Best wishes,

Gorry

Gorry Fairhurst wrote:

> 
> The ULE Spec is now completing IESG review, and will soon be ready for

> publishing as an RFC. With this in mind, the authors of ULE have 
> progressed with registering a code-point for the SI that describes
ULE.
> They propose an update the ULE Spec to include the appropriate text 
> describing this, prior to publication as an RFC.
> 
> As I see it, there are three threads to this process - ISO format_id; 
> DVB data_broadcast_id; and stream_type.
> 
> Please send thoughts on any or all of the points below to the mailing 
> list...
> 
> Best wishes,
> 
> gorry
> 
> -----
> 1) Format ID
> 
> Proposed additional text for ULE RFC to specify what to do with PMTs 
> on page 3:
> 
> Old:
>   "The MPEG-2 specification [ISO-MPEG2] requires conformant TS
>    Multiplexes to provide Program Specific Information (PSI) for
>    each stream in the TS Multiplex. Other MPEG-2 based transmission
>    standards may also define Service Information (SI)."
> 
> New:
>   "The MPEG-2 specification [ISO-MPEG2] requires conformant TS
>    Multiplexes to provide Program Specific Information (PSI) for
>    each stream in the TS Multiplex. Other MPEG-2 based transmission
>    standards may also define Service Information (SI).
> 
>   "A format_identifier value has been registered with the SMPTE RA
>    [ULE1], for ULE. This has the hexadecimal value 0x554C4531
>    ("ULE1"). Transport Streams that utilise the Programme
>    Map Table (PMT) defined in ISO 13818-1 and that use the ULE
>    format defined in this document, SHOULD insert a descriptor with
>    this value in the PMT ES_info descriptor loop."
> 
> Add:
> [ULE1] Registration for format_identifier ULE1, SMPTE Registration 
> Authority, LLC, http://www.smpte-ra.org/ule1.html.
> 
> -----
> 2) Data broadcast descriptor
> 
> Although this was proposed at the last IETF meeting and via the 
> mailing list, this has not currently been progressed. We can not 
> currently see a specific need for this descriptor for ULE streams - 
> the conventional use of the descriptor for MPEG Tables makes this less

> appropriate than (1) as a general-purpose method. A registration for 
> ULE could still be done (before or after publishing the ULE RFC). Is
there a need to do this now?
> 
> -----
> 3) Stream Type
> 
> As I understand, stream_type values are not normatively assigned by 
> ISO, but conventions are documented by DVB and ATSC. We propose to 
> continue to progress with requesting a value for ULE (starting with 
> ATSC). It is not clear to me that the value needs to be specified in 
> the published RFC - what do others think?
> 
> 
>