[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Réf. : Re: Réf. : RE: Question on Continuity Counter field
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?)....
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).
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?!
(another reason would be buffer overflow at the sender but in that case
replication is not applicable..)
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.
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?
>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.
~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.
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