RE: Réf. : RE: Question on Continuity Counter field

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

So... what if the source MPEG-2 Transport stream has two packets that are
identified by the same PID which do not increment the CC (because the
content did not change)? 

This language would seem to require the CC to be incremented, which would
result in the duplicated data being presented to the parser as if it is the
next data in sequence. The resulting stream would no longer meet
13818-1:2000 and receiver behavior is unpredictable. Note that the packet
could be a table section, where error concealment is not an option. 

Also see my earlier post for other conditions where this payload counter
should not be incremented..

Further, requiring the ULE layer to touch this payload value seems like a
cross between layers and therefore a questionable design...  

Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418


-----Original Message-----
From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
Sent: Wednesday, February 18, 2004 8:55 AM
To: ip-dvb@erg.abdn.ac.uk
Subject: Re: Réf. : RE: Question on Continuity Counter field


So....

On transmission ULE  currently says:
       "The Encapsulation MUST ensure that all TS Packets set the MPEG-2
        Continuity Counter carried in the TS Packet header.  This value MUST
        be incremented by one (using modulo arithmetic) for each TS Packet
        sent using a TS Logical Channel [ISO-MPEG]."

This simply says the encapsulator must be compliant for what it sends.

At the receiver:
       "The Receiver MAY also check the MPEG-2 Continuity Counter carried in
        the TS Packet header. If the Receiver does perform Continuity
        Counter checking and the received value does not increment by one
        for successive TS Packets (modulo 16), the Receiver has detected a
        continuity error. Any partially received SNDU MUST be discarded. A
        continuity counter error event SHOULD be recorded. The Receiver then
        enters the Idle State."


The case for ULE reception seems much less clear, and I'd be interested to
re-assess the correct behaviour.

I wonder what is the implication of simply ignoring the CC field?
- This has no impact as far as I can see on ULE payload data integrity OR
framing, since in ULE these are primarily protected by the CRC-32.

Does anyone think we should change the recommendation to "SHOULD NOT" check
or "MUST" ignore the CC field?

Gorry


On 18/2/04 12:48 pm, "Tarif.Zein-Alabedeen@space.alcatel.fr"
<Tarif.Zein-Alabedeen@space.alcatel.fr> wrote:

> 
> 
> Thank you Art and william for your answers...
> 
> William says that consider or mask CC check for a given PID is
> implementation dependent..
> is someone aware of the general rule for current IP/MPE/MPEG
> implementations?
> 
> Considering our ULE encapsulation, I think it would be wise to provision
an
> option allowing to disactivate CC check for specified PIDs in the
receiver.
> This may be helpful if, at some point in the future, we need ULE/MPEG to
> operate correctly in a mesh or multi star scenarios (PID shared among
> several transmiters).
> what is your opinion about that?
> 
> best regards
> Traif ZEIN
> 
> 
> 
> 
> 
> 
> 
> 
> "Allison, Art" <AAllison@nab.org>@erg.abdn.ac.uk on 17/02/2004 20:45:38
> 
> Veuillez répondre à ip-dvb@erg.abdn.ac.uk
> 
> Envoyé par :      owner-ip-dvb@erg.abdn.ac.uk
> 
> 
> Pour : "'ip-dvb@erg.abdn.ac.uk'" <ip-dvb@erg.abdn.ac.uk>
> cc :
> Objet :     RE: Question on Continuity Counter field
> 
> 
> IMHO, if a MPEG-2 TS parser was presented with out of order packets
> identified by the same PID, a receiver failure is to be expected as the
> stream would be non-conformant.
> 
> However, the continuity_counter can be the same in sequential packets
> (which
> are then required to be the same except for the PCR).  Also, this count
may
> be discontinuous when that is indicated by the discontinuity_indicator.
So
> it is not always a monotonically incrementing field.  Given the rules for
> this 4-bit continuity_counter, it is not apparent that it is possible to
> use
> it to reorder packets at the MPEG-2 level.
> 
> Therefore, IMHO, any lower level communication protocol must not reorder
> MPEG-2 transport stream packets that are identified by the same PID. If it
> has a potential to do so, then either constraints or an explicit method
for
> restoring the order must be defined.
> 
> Art
> ::{)>
> Art Allison
> Director Advanced Engineering
> NAB
> 1771 N St NW
> Washington DC 20036
> 202 429 5418
> 
> 
> -----Original Message-----
> From: Tarif.Zein-Alabedeen@space.alcatel.fr
> [mailto:Tarif.Zein-Alabedeen@space.alcatel.fr]
> Sent: Friday, February 13, 2004 9:05 AM
> To: ip-dvb@erg.abdn.ac.uk
> Subject: Question on Continuity Counter field
> Importance: Low
> 
> 
> 
> 
> Hi,
> I have a question about the continuity counter field in the TS packet
> header. May be someone in this group has the right answer :
> what heppens if an MPEG receiver receives an out of order TS packet?
> that is, for the same PID, the CC field value of a received packet not
> equal to CC field value of precedent TS packet + 1
> 
> Is there one standard behavior or is it implmenetation dependent?
> can CC check as the receiver be disabled?
> 
> (oups, this makes 3 questions already)
> 
> thank's and best regards
> 
> 
> 
> 
>