[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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