Question on Continuity Counter field
gorry at erg.abdn.ac.uk
Mon Mar 1 11:12:25 GMT 2004
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
3) To proceed in addressing the Author note, will require further
discussion on this list.
William StanisLaus wrote:
> Please refer..ISO/IEC 13818-1
>126.96.36.199 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.
>William StanisLaus | Design Engineer - FS, Nera Dept
>email: williams at future.futsoft.com | Telephone: +91 44 24330550 Extn: 282
>Mobile: +91 98411 57902
>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.
>>Director Advanced Engineering
>>1771 N St NW
>>Washington DC 20036
>>202 429 5418
>>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
>>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
More information about the Ip-dvb