Question on Continuity Counter field

[Gorry Fairhurst]

I'm trying to ensure the next rev of the ID will read correctly, 
specifically here is the current text I propose. I hope this is much 
more strongly aligned with ISO MPEG-2, based on all the list discussion:

1) New text for 5.1 Encapsulation:
"The Encapsulation MUST ensure that all TS Packets set the MPEG-2 
Continuity Counter carried in the TS Packet header, according to 
[ISO-MPEG]. This value MUST be incremented by one (modulo 16) for each 
successive fragment/complete SNDU sent using a TS Logical Channel.
"

2) New text for Receiver processing:
"The Receiver MUST check the MPEG-2 Continuity Counter carried in the TS 
Packet header [ISO-MPEG]. If two (or more) successive TS Packets within 
the same TS Logical Channel carry the same Continuity Counter value, the 
duplicate TS Packets MUST be silently discarded. If the received value 
is NOT identical to that in the previous TS Packet, and it 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.

[XXX Author note: the default action MUST be above to support conformant 
MPEG-2 streams. Should we allow a configuration variable to disable 
this? – A clear case for usage would need to be established XXX]

Note that the MPEG2-2 Transmission network is permitted to carry
Duplicate TS Packets [ISO-MPEG], which are normally detected by the
MPEG-2 Continuity Counter. A Receiver that does not perform the above 
Continuity Counter check, will accept duplicate copies of TS Packets to 
the reassembly procedure. In such cases, the SNDU CRC-32 integrity check 
will normally result in discard of these SNDUs, resulting in unexpected 
PDU loss.
"
3) To proceed in addressing the Author note, will require further 
discussion on this list.

Gorry


William StanisLaus wrote:

>Hi,
>   Please refer..ISO/IEC 13818-1
>2.4.3.3 Semantic definition of fields in Transport Stream packet layer, Page 44 for countinuty_counter and Page 46 for discontinuity_indicator
>
>Well its again an implementation decision to consider or mask countinuty check based on the PID.
>
>Best Regards,
>William StanisLaus | Design Engineer - FS, Nera Dept 
>email: williams at future.futsoft.com | Telephone: +91 44 24330550 Extn: 282 
>Mobile: +91 98411 57902 
>www.futsoft.com
>
>
>On Wed, 18 Feb 2004 Allison, Art wrote :
>  
>
>>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 at space.alcatel.fr
>>[mailto:Tarif.Zein-Alabedeen at space.alcatel.fr]
>>Sent: Friday, February 13, 2004 9:05 AM
>>To: ip-dvb at 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
>>
>>
>>T. Zein
>>ALCATEL SPACE
>>DRT/RST
>>
>>    
>>
>
>  
>