[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question on Continuity Counter field

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@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@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


T. Zein
ALCATEL SPACE
DRT/RST