Re: Adding ULE into a network already using MPE...

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

I don't see it this way.

On 4/8/05 5:45 pm, "Goldberg, Adam" <agoldberg@sharplabs.com> wrote:

> Sure, you can decide to not use the mechanisms already existent in an MPEG
> Transport Stream (B, C), but in doing so you merely cause redesign or
> purchase of special-purpose "MPEG" processing devices.

Why do you feel auto-detection of the encapsulation ( C ) implies a redesign
of the MPEG equipment? This is a driver issue only, and orthogonal to
supplying SI/PSI signalling. It does not stop a stream sending signalling as
well, or imply it. It provides a way to know that you have got the right
encaps.

> Make it a Transport Stream.  This has very little real overhead, requiring
> only a PAT and PMT.  The PMT is very lightweight but yet can easily signal
> which elementary streams (er, "PIDs") are encoded with what protocols.
> 
> This has many advantages:  You don't need to reinvent anything (inband
> signaling) -- merely an identifying descriptor; you don't have to require
> multiplexers and other non-IETF MPEG processing devices do anything special
> (that is to say, you don't require existing MPEG processing devices to also
> process nonstandard IETF things); IETF streams would coexist peacefully with
> non-IETF streams in a Transport Stream; it's very extensible to other
> encapsulation formats yet-to-be-defined.

I think someone should gather this thread and write one or two paragraphs to
summarise this to include in section 4 of the address resolution document
(draft-ietf-ipdvb-ar-00.txt), especially the implications of the PSI/SI on
the remultiplexing environment.

Gorry
 
> 
> 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 Gorry Fairhurst
>> Sent: Thursday, August 04, 2005 3:56 AM
>> To: ipdvb@erg.abdn.ac.uk
>> Subject: Re: Adding ULE into a network already using MPE...
>> 
>> There ways to do this I can think of three, and I think John you are
>> asking
>> about C?
>> 
>> 
>> A) You could parse the SI/PSI signalling (if any) and extract the
>> information from there.
>> 
>> B) You could configure it (out of band) or using IP
>> configuration/resolution, etc.
>> 
>> C) I once worked through an "auto-detect mode", where you knew the PID but
>> didn't know the type of encapsulation.
>> 
>> ----
>> 
>> The basic rule is only one type of encapsulation is allowed for a single
>> PID. So how can you find out which is used?
>> 
>> I note there is a reasonably strong CRC there in the ULE framing, and you
>> can easily extract framing alignment to the TS from the PUSI setting in
>> the
>> TS header:
>> 
>> (i) Supposing your receiver starts as unconfigured.
>> 
>> (ii) The receiver looks for a PUSI setting and extracts the PP value.
>> 
>> (iii) It then tries reassembly of the first section as a ULE packet. If it
>> succeeds with a valid CRC-32 and Length, it is probably safe to assume
>> this
>> is ULE.
>> 
>> (iv) If the CRC fails, it tries a DSM-CC section reassembly (being aware
>> the
>> integrity check is interpreted in more than one way in MPE). The MPE start
>> code is also another "hint" that this may not be ULE, but this value
>> *could*
>> appear as the start of a ULE field - (Note one needs to be aware that MPE
>> and ATSC use different start values).
>> 
>> (v) You could (probably should!!!) verify the next few SNDUs to increase
>> your confidence, as in any alignment algorithm.  It would also be wise to
>> re-initialise the detection if you suffer an alignment failure. This could
>> be a result of a change of mutliplexing policy.
>> 
>> Note: This is orthogonal to the generation of SI/PSI tables used to
>> control
>> the TS multiplexing layer itself. If you use a transport stream
>> multiplexor
>> as a part of your L2 MPEG transmission network, this may need the SI/PSI
>> to
>> allow the PID to reach the Receiver.
>> 
>> Thoughts?
>> 
>> Gorry
>> 
>> On 3/8/05 8:39 pm, "John Border" <border@hns.com> wrote:
>>> 
>>>     I was thinking along those lines.  The sender associates the
>>> encapsulation method with a particular PID and "knows" (via AR) which
>>> PID to use to send to a particular receiver.  Receivers which only
>>> understand MPE only use MPE PIDs.  Receivers which understand ULE and
>>> MPE determine which method is being used by which PID is being
>>> received.  (I think the ULE capable receivers will still need to support
>>> MPE for multicast traffic that is shared with "older" terminals.)
>>> 
>>>     I was wondering if there is a way for the receiver to look at the
>>> header and determine if it is ULE or MPE on the fly.  I haven't taken a
>>> close look at it yet.  But, I suspect that it is not reliably
> possible...
>>> 
>>> John
>>> 
>>> 
>>> Marie-Jose Montpetit wrote:
>>> 
>>>> I think this is one thing that could be solved by some of the
>>>> configuration work that was started where you could associate a PID to
>>>> an encapsulation. You may not want to ignore the new encapsulation.
>>>> 
>>>> Marie-Jose
>>>> 
>>>> 
>>>> 
>>>>> -------- Original Message --------
>>>>> Subject: RE: Adding ULE into a network already using MPE...
>>>>> From: "Allison, Art" <AAllison@nab.org>
>>>>> Date: Wed, August 03, 2005 2:05 pm
>>>>> To: <ipdvb@erg.abdn.ac.uk>
>>>>> 
>>>>> Use of the MRD will enable a device on a MPEG-2 network that does not
>>>>> understand that MRD's signaling/meaning to ignore the new
>> encapsulation.
>>>>> 
>>>>> 
>>>>> Of course if the existing network just used private data with out
>>>>> signaling what it was, a problem may exist.
>>>>> __________________
>>>>> 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, August 03, 2005 11:32 AM
>>>>> To: ipdvb@erg.abdn.ac.uk
>>>>> Subject: Adding ULE into a network already using MPE...
>>>>> 
>>>>> 
>>>>>    Has anyone looked at the operational problems associated with
>> adding
>>>>> ULE use to a network which has some deployed terminals which only
>>>>> understand MPE?
>>>>> 
>>>>> 
>>>>> John
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
> 
>