[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed Changes to ULE text - Format descriptors for SI signalling
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: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]
Sent: Wednesday, July 27, 2005 2:47 PM
To: ipdvb@erg.abdn.ac.uk
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?
>
>
>