[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed Changes to ULE text - Format descriptors for SI sign alling



On 29/7/05 11:44 pm, "Goldberg, Adam" <agoldberg@sharplabs.com> wrote:

> Are there transport streams (in IETF-land) WITHOUT PMT?

Indeed there are. 

There are many possible topologies for MPEG-2 Transmission Networks, see
section 3.1 of:
http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-arch-04.txt

In some specific scenarios, there are "transport streams" that go straight
from the ipdvb gateway/encapsulator, are modulated/broadcast and then
received by a Receiver/Router (i.e., for example they are never
"remultiplexed", and have no specific need for a PMT). These can use other
methods to configure PID usage.

Gorry

> If so, I'd like to know.  And if not,
> 
> RTR: " A format_identifier value has been registered for ULE [ULE1]. This 32
> bit number has a hexadecimal value of 0x554C4531.  Transport Streams that
> use the ULE format defined in this document SHALL insert a descriptor with
> this value in the Program Map Table (PMT) ES_info descriptor loop."
> 
> 
> Adam Goldberg
> Director, Television Standards & Policy Development
> Sharp Laboratories of America
> 8605 Westwood Center Drive, Suite 206
> Vienna, VA  22182
> 703-556-4406
> 703-556-4410 fax
> 571-276-0305 cell
>  
> 
> 
>> -----Original Message-----
>> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
>> Behalf Of Allison, Art
>> Sent: Friday, July 29, 2005 3:06 PM
>> To: ipdvb@erg.abdn.ac.uk
>> Subject: 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?
>>> 
>>> 
>>> 
> 
>