[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RE: Réf. : RE: Question on Continuity Counter field
Dear all,
I fully agree on Bernhard's comment, CC is the only means of validating any payload belonging to same TS packets for that PID. In case if any intermediate TS packets are lost, RX state moves to out of sync and flushes the buffer.
But masking of CC is used on propriety PIDs and Real Time protocol PIDs, where loss of TS packets are merely eliminated, mostly single ip packet is filled in one TS packet and which is taken care by higher layer protocol.
Best Regards,
William.
On Wed, 18 Feb 2004 Bernhard Collini-Nocker wrote :
>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
> >
> >
> >
> >
> >
>