RE: Réf. : Re: Réf. : RE: Question onContinuity Counter field

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

See embedded.. sorry, but in meetings all day today and tomorrow..
I responded to this response and to the note before it in this one
message...as the day is gone.
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: Thursday, February 19, 2004 11:41 AM
To: ip-dvb@erg.abdn.ac.uk
Subject: Réf. : Re: Réf. : RE: Question onContinuity Counter field
Importance: Low




About your first question, yes, it seems that a sender can intentionaly
replicates TS packets (only one replicate is allowed I think). This is to
conceal packet losses
It does not seem however that replication is obligatory.  It is up to the
sender to decide this (is that correct Allison?)....
AA> Correct, it is a sender option.  

So, the question now is (and before rewriting the ID) : do we need
replication in our ULE/MPEG mode?

My first feeling is that we don't (but this is still a feeling).
AA> I don't see the need for replication. 

For this, let me bring the following argumentation :
The only reason I see for a packet bieng lost (at least on transparent
satellite channel) is that an error occured in its PID field (PIDx became
PIDy).
Is that correct?!
AA>I don't know the OFDM error detection/protection coding and its
relationship to MPEG-2 packets. For QAM per SCTE and 8VSB per ATSC, a
defective packet is considered a lost packet.  If <any> physical layer error
processing coding/method is not enough for proper reconstruction of bits
damaged in a packet, then determining which bit is bad may not be possible.
Even if the system can determine which bit is not correct, there is only one
bit for signaling at the Transport Stream layer. Therefore which bit(s)
is(are) bad is not available at the MPEG-2 transport stream layer. 

(another reason would be buffer overflow at the sender but in that case
replication is not applicable..)
AA> Yes, if buffer overflow the TS is broken already and not this RFC's job
to try to fix.

Packet duplications is surely efficient for these losses. However, for a
given bit error ratio, the probability of erros occuring within the 184
bytes payload should be much higher than the probability of errors occuring
in the 13 bits PID field. In other terms, packet loss probability should be
much smaller than packet error probability which leads anyway to SNDU being
droped after CRC check... So, resolving packet loss would not improve
significantly the SNDU loss/drop ratio and finally the PDU delivery
robustness.
AA>Is it possible you are mixing PES layer with MPEG2 transport stream
layer? While a table can be in a packet (and therefore have a CRC in that
packet), they and PES packets cross packet boundaries.
AA> For some transports the entire packet is coded with Reed Solomon for
error detection and recovery, and if this fails the entire packet is usually
tossed.. The hit chance a function of bit count would only apply to <just>
the transport error indicator bit being hit, a very remote chance.

May be someone is aware of studies or simulations having been done on this
issue and quantifying the improvment of replication on the SNDU loss/drop
ratio

regards





Gorry Fairhurst <gorry@erg.abdn.ac.uk>@erg.abdn.ac.uk on 19/02/2004
16:09:32

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
cc :
Objet :     Re: Réf. : RE: Question on Continuity Counter field


Before we look at any new ideas for potentially easing use of ULE over
regenerative satellites, I'd like to clearly understand the points
raised below, specifically the correct sender/receiver behaviour as
required by MPEG-2:

Allison, Art wrote:

>So... what if the source MPEG-2 Transport stream has two packets that are
>identified by the same PID which do not increment the CC (because the
>content did not change)?
>
So is this where the sender (encapsulator)  intentionaly replicates
exactly the last TS-Packet?

AA> Yes.

>This language would seem to require the CC to be incremented, which would
>result in the duplicated data being presented to the parser as if it is
the
>next data in sequence. The resulting stream would no longer meet
>13818-1:2000 and receiver behavior is unpredictable. Note that the packet
>could be a table section, where error concealment is not an option.
>
If you're saying duplication is a valid technique to conceal loss, then
the appropriate response should be to discard any duplicates (with
identical CC). This is not what the current ID text says.
AA> Discarding of duplicates seems like an alternative.  However, if this
ULE were used as part of a distribution chain perhaps thinking if forces a
re-generation and insertion of duplicate packets.  Also the rules are more
complex than discard duplicates as they involve the state of the
discontinuity_indicator.

~If at all possible, ULE should be designed to fully conform to ISO
MPEG-2 TS,  that is a stated goal.

Some new text is now definitely required.

>
>Also see my earlier post for other conditions where this payload counter
>should not be incremented..
>
>Further, requiring the ULE layer to touch this payload value seems like a
>cross between layers and therefore a questionable design...
>
The current text did NOT require acceess to the CC field.  The actual
text, only permitted this: "The Receiver MAY also check"...  There are
alos other ways of verifying framing and integrity in ULE.
AA> I read an encapsulator MUST requirement (and cross over) not a receiver
requirement..

Best wishes,

Gorry

>
>Art
>::{)>
>Art Allison
>Director Advanced Engineering
>NAB
>1771 N St NW
>Washington DC 20036
>202 429 5418
>
>
>-----Original Message-----
>From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
>Sent: Wednesday, February 18, 2004 8:55 AM
>To: ip-dvb@erg.abdn.ac.uk
>Subject: Re: Réf. : RE: Question on Continuity Counter field
>
>
>So....
>
>On transmission ULE  currently says:
>       "The Encapsulation MUST ensure that all TS Packets set the MPEG-2
>        Continuity Counter carried in the TS Packet header.  This value
MUST
>        be incremented by one (using modulo arithmetic) for each TS Packet
>        sent using a TS Logical Channel [ISO-MPEG]."
>
>This simply says the encapsulator must be compliant for what it sends.
>
>At the receiver:
>       "The Receiver MAY also check the MPEG-2 Continuity Counter carried
in
>        the TS Packet header. If the Receiver does perform Continuity
>        Counter checking and the received value 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."
>
>
>The case for ULE reception seems much less clear, and I'd be interested to
>re-assess the correct behaviour.
>
>I wonder what is the implication of simply ignoring the CC field?
>- This has no impact as far as I can see on ULE payload data integrity OR
>framing, since in ULE these are primarily protected by the CRC-32.
>
>Does anyone think we should change the recommendation to "SHOULD NOT"
check
>or "MUST" ignore the CC field?
>
>Gorry
>
>
>On 18/2/04 12:48 pm, "Tarif.Zein-Alabedeen@space.alcatel.fr"
><Tarif.Zein-Alabedeen@space.alcatel.fr> wrote:
>
>
>
>>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
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>






T. Zein

ALCATEL SPACE
DRT/RST  --  Ingénieur Systèmes
Tel : 0534356918  /  Fax : 0534355560
Porte : W.220