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

["Bernhard Collini-Nocker" <bnocker@cosy.sbg.ac.at>]

Dear all,

I do not agree with the conclusion that considering or masking CC check for a given PID is implementation dependent. According to ISO/IEC 13818-1 the CC is a 4 bit field incrementing with each Transport Stream packet with the same PID. It wraps around to 0 after its maxmimum value. Only in case when the adaptation_filed_control bits indicate "reserved" or "no payload" the CC shall not be incremented. For the receiver the CC is the only means (despite of a CRC/checksum of the reassembled payload) to check for TS packets belonging to the same "payload" on the same PID. When the CC of a subsequent packet is not incremented by one (or wrapped) then the receiver must assume that it has lost one or more TS packets and must wait for the next PUSI to resynchronize. It must flush its buffer if an end of a payload has not been reached yet. Disabling CC check on the receiver probably makes only sense if each payload fits into one TS packet, hence, all TS packets carry a PUSI and discontinuity does not introduce problems.

Finally PID sharing among different transmitters must follow the same rules. If there is no onboard functionality that resolves discontinuties in buffering complete payloads (sections or elementary stream packets or even ULE protocol data units) and playout with incremental CCs per payload receivers would screw up completely.

Kind regards,
Bernhard

Dr. Bernhard Collini-Nocker
Institute for Computer Sciences
Salzburg University
J. Haringerstr. 2
A-5020 Salzburg
Tel: +43 662 8044 6316
Fax: +43 662 8044 611



> -----Original Message-----
> From: owner-ip-dvb@erg.abdn.ac.uk 
> [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
> Behalf Of Tarif.Zein-Alabedeen@space.alcatel.fr
> Sent: Mittwoch, 18. Februar 2004 13:49
> To: ip-dvb@erg.abdn.ac.uk
> Subject: Réf. : RE: Question on Continuity Counter field
> Importance: Low
>
>
>
>
> 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
>
>
>
>
>