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

["Allison, Art" <AAllison@nab.org>]

 See embedded/edit. 

-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] 
Sent: Sunday, July 31, 2005 4:26 PM
To: ipdvb@erg.abdn.ac.uk
Subject: Re: Proposed Changes to ULE text - Format descriptors for SI
sign alling

Gorry said:
<snip>
The IETF defines (in RFC2119) that SHOULD, means "that there may exist
valid reasons in particular circumstances to ignore a particular item,
but the full implications must be understood and carefully weighed
before choosing a different course".

In this case, it means "implement this" or the implication may be that
the stream is dropped by a TS multiplexor that does not recognise it.

Gorry
<snip>

Art observes:
First, I would not expect lack of an MRD in the  program element loop of
the PMT section to result in dropping the stream with a given PID value.
Lack of an entry (the program element loop) that identifies the PID in
the PMT would be expected to result in the stream being dropped by a
general purpose multiplexer. This situation is sometimes called a
'orphan' PID.  

Second, implementers oft decide not to provide support for optional
logic as it adds development and testing time. So one must expect some
receivers conforming to the RFC will not have ability to discriminate
based on the MRD value, but all tolerate its presence.

I see other implications than the one Gorry cited for general purpose
MPEG-2 distribution systems.

These implications arise from the fact that PID values for payload
streams are free to be changed by MPEG-S TS equipment, provided the PSI
reflects the change.

I1: So, if the PID value of the ULE stream is changed by a multiplexer
<somewhere> in the distribution path, a receiver which was set up to
receive a stream with a certain PID value would have no way to verify
that the stream was a ULE stream. A receiver selecting and decoding this
PID could produce an output formatted per ULE rules that was not really
IP traffic. It could lead to bad data or result in intermittent loss of
data by down stream consumers (and the receiver that disembeds the IP
from the TS packets can legitimately signal the ULE stream on that PID
was fine here.)

I2: Without the MRD, a receiver cannot search the TS and locate the
stream(s) that are ULE sent using arbitrary PID values over standard
MPEG-2 compliant networks.

So I ask: 
Q1: What are the "valid reasons in particular circumstances to ignore a
particular item" in this particular case?

Q2: Is it to use a PID value that is set and communicated 'out of band'
to the receiver, and to force all equipment to not change that PID
value?  

If so, that could work for that case; but that is a private network, not
a general purpose one, and private networks can relax the requirement if
needed (these are voluntary RFCs after all). 

Q3: However, given the lack of robustness/reliability that results from
lack of the MRD, is the bit rate savings for not sending the MRD judged
worth the inability to identify ULE streams sent over 'normal' general
purpose MPEG-2 networks?

I posited need for a SHALL, with wording that excluded use MPEG-2
transport packets with a PMT (but which might not meet other MPEG-2 TS
requirements) and Adam reworded my posit to strictly apply to all use
(which I can support as well).

Art
__________________
Art Allison
Director, Advanced Engineering
NAB Science & Technology
1771 N St NW, Washington DC 20036
202 429 5418