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

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

Please note that the Continuity Counter need not increment in the special
case where the TS packet contents are duplicated, see same ref as below (and
my previous post). (So I take this small exception to Bernhard's post
below). But I agree with the thrust of his post.

Stated simply, if TS packets get out of order then one does not have a valid
MPEG-2 stream any longer and a receiver cannot be expected to work. The
question is about how to handle this failure mode seems a futile and
non-productive exercise. Don't enable it.

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


-----Original Message-----
From: Bernhard Collini-Nocker [mailto:bnocker@cosy.sbg.ac.at]
Sent: Wednesday, February 18, 2004 9:32 AM
To: ip-dvb@erg.abdn.ac.uk
Subject: RE: Réf. : RE: Question on Continuity Counter field


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