Subject: [AVT] Comments on RTP Payload Format for "MPEG2-TS Preamble" internet draft

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 11 Jan 2010 14:09:31 +0100

Ali, Erich

I have some questions and comments regarding the phrasing in the intro
section of the MPEG2 TS preamble draft:
You currently have:

  [I-D.ietf-avt-rapid-acquisition-for-rtp] refers to the information
   that must first be acquired before starting to process any data sent
   in the multicast session as the Reference Information.  In this
   document, we refer to the subset of the Reference Information that is
   related to the MPEG2-TS as the MPEG2-TS Preamble.

For multicast applications running over RTP,
   [I-D.ietf-avt-rapid-acquisition-for-rtp
<http://tools.ietf.org/html/draft-begen-avt-rtp-mpeg2ts-preamble-04#ref-
I-D.ietf-avt-rapid-acquisition-for-rtp> ] proposes an approach where
   an auxiliary unicast RTP session is established between a
   retransmission server and the joining RTP receiver.  Over this
   unicast RTP session, the retransmission server provides the Reference
   Information the RTP receiver needs to rapidly acquire the multicast
   session.  If the source stream in the RTP multicast session is
   carrying an MPEG2-TS, the Reference Information will comprise the
   MPEG2-TS Preamble as well.  For its proper transmission from the
   retransmission server to the joining RTP receiver, a new RTP payload
   format has to be defined for the MPEG2-TS Preamble.  

This document defines and registers this payload format.

   Since the RTP packet(s) carrying the MPEG2-TS Preamble will not be
   able to fed to the decoder in the form they are received, a post-
   processing is required at the RTP receiver.  This document also
   explains this process in Section 7
<http://tools.ietf.org/html/draft-begen-avt-rtp-mpeg2ts-preamble-04#sect
ion-7> .

TOM: The problem I have is the following: with RAMS, all Reference
information can be transported as retransmission packets; i.e.
retransmitted in the same way this payload information was present and
transported, encapsulated as RTP packet, in the primary multicast, but
with a RTP retransmission payload header. This includes the reference
information related to MPEG2 TS.  You call this "MPEG2 TS pre-amble",
and I believe this naming is independent from the way this information
is transferred to the RTP receiver (correct me if I am wrong).  So, I do
not understand why you write : "For its proper transmission from the
retransmission server to the joining RTP receiver, a new RTP payload
format has to be defined for the MPEG2-TS Preamble."  As explained
above, the "MPEG2TS preamble" information could equally be included in
the RTP burst conmprising of (solely) retransmission packets.  I think
your sentence should be replaced with something like:

"this draft defines a dedicated payload format for transporting MPEG2 TS
preamble information"  

I am not sure whether this RTP payload format also has applications
outside RAMS? If not, then I think more text is needed explaining why
and in which cases there is need for such a MPEG2 TS preamble payload
format, instead of relying on just sending a burst of retransmission
packets. 

Also the sentence "Since the RTP packet(s) carrying the MPEG2-TS
Preamble will not be able to fed to the decoder in the form they are
received, a post-processing is required at the RTP receiver." is not
correct IMO, as RTP retransmission packets carrying the MPEG2 TS
preamble information in the way I explained above, do not need
post-processing, other than RTP layer decapsulation. 

As this draft is strongly linked to the RAMS draft, I have some other
comments related to the MPEG2 TS preamble or app. -specific packets that
can be sent along a burst of retransmision packets in a single
retransmission session making use of RAMS. 

IMO we do not need a new RAMS-R TLV element that requests only the
preamble from the server, as you have written in your last email
summarising the resolution of the received WGLC comments. I think the
meaning of this new TLV should indicate "RTP receiver supports the MPEG2
TS preamble payload format". This is because when an RTP receiver issues
a RAMS-R, this is basically to receive a burst of packets. This is what
the RAMS draft is about. We could define a new 500 response code saying
" burst request not accepted, but here is the MPEG2 TS preamble in the
dedicated RTP payload format" as you suggested as well.

Then a minor comment: section 6.2 says: "A particularly important field
in the RAMS-I message
       carries the RTP sequence number of the first packet transmitted
       in the retransmission session to allow RTP_Rx to detect any
       missing initial packet(s).  Note that the first RTP packet
       transmitted in the retransmission session is not necessarily a
       burst packet.  It could be a payload-specific RTP packet (See
       [I-D.begen-avt-rtp-mpeg2ts-preamble
<http://tools.ietf.org/html/draft-ietf-avt-rapid-acquisition-for-rtp-05#
ref-I-D.begen-avt-rtp-mpeg2ts-preamble> ] for an example)." 

We should be more specific and require that the payload-specific RTP
packets must be payload type multiplexed and have the same SSRC as the
retransmission packets when deployed in RAMS scenario. This is in line
with your specification on the MPEG TS pre-amble payload format. 

Regards
Tom

---

From: Roni Even <[email-masked]>
Date: Mon, 11 Jan 2010 15:48:42 +0200

Tom,

You should look also at
http://tools.ietf.org/html/draft-xia-avt-mpeg2ts-preamble-01 which suggests
to send the preamble as an original RFC2250 payload and does not need post
processing.

The first version of the above draft suggested sending the stream as
retransmission stream but at the breakout session in Hiroshima it was
conclude that since it will require to assign sequence numbers which are not
the original ones it will not be a regular RFC 4588 retransmission packet

The xia draft is another option for sending preamble. The AVT chairs asked
in a previous email to look at both drafts and send comments

Roni Even as Individual. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of VAN
CAENEGEM Tom
Sent: Monday, January 11, 2010 3:10 PM
To: [email-masked]
Subject: [AVT] Comments on RTP Payload Format for "MPEG2-TS Preamble"
internet draft

Ali, Erich 

For multicast applications running over RTP,
   [
<http://tools.ietf.org/html/draft-begen-avt-rtp-mpeg2ts-preamble-04#ref-I-D.
ietf-avt-rapid-acquisition-for-rtp> I-D.ietf-avt-rapid-acquisition-for-rtp]
proposes an approach where
   an auxiliary unicast RTP session is established between a
   retransmission server and the joining RTP receiver.  Over this
   unicast RTP session, the retransmission server provides the Reference
   Information the RTP receiver needs to rapidly acquire the multicast
   session.  If the source stream in the RTP multicast session is
   carrying an MPEG2-TS, the Reference Information will comprise the
   MPEG2-TS Preamble as well.  For its proper transmission from the
   retransmission server to the joining RTP receiver, a new RTP payload
   format has to be defined for the MPEG2-TS Preamble.  

   Since the RTP packet(s) carrying the MPEG2-TS Preamble will not be
   able to fed to the decoder in the form they are received, a post-
   processing is required at the RTP receiver.  This document also
   explains this process in
<http://tools.ietf.org/html/draft-begen-avt-rtp-mpeg2ts-preamble-04#section-
7> Section 7. 

TOM: The problem I have is the following: with RAMS, all Reference
information can be transported as retransmission packets; i.e. retransmitted
in the same way this payload information was present and transported,
encapsulated as RTP packet, in the primary multicast, but with a RTP
retransmission payload header. This includes the reference information
related to MPEG2 TS.  You call this "MPEG2 TS pre-amble", and I believe this
naming is independent from the way this information is transferred to the
RTP receiver (correct me if I am wrong).  So, I do not understand why you
write : "For its proper transmission from the retransmission server to the
joining RTP receiver, a new RTP payload format has to be defined for the
MPEG2-TS Preamble."  As explained above, the "MPEG2TS preamble" information
could equally be included in the RTP burst conmprising of (solely)
retransmission packets.  I think your sentence should be replaced with
something like:

I am not sure whether this RTP payload format also has applications outside
RAMS? If not, then I think more text is needed explaining why and in which
cases there is need for such a MPEG2 TS preamble payload format, instead of
relying on just sending a burst of retransmission packets. 

Also the sentence "Since the RTP packet(s) carrying the MPEG2-TS Preamble
will not be able to fed to the decoder in the form they are received, a
post-processing is required at the RTP receiver." is not correct IMO, as RTP
retransmission packets carrying the MPEG2 TS preamble information in the way
I explained above, do not need post-processing, other than RTP layer
decapsulation. 

As this draft is strongly linked to the RAMS draft, I have some other
comments related to the MPEG2 TS preamble or app. -specific packets that can
be sent along a burst of retransmision packets in a single retransmission
session making use of RAMS. 

IMO we do not need a new RAMS-R TLV element that requests only the preamble
from the server, as you have written in your last email summarising the
resolution of the received WGLC comments. I think the meaning of this new
TLV should indicate "RTP receiver supports the MPEG2 TS preamble payload
format". This is because when an RTP receiver issues a RAMS-R, this is
basically to receive a burst of packets. This is what the RAMS draft is
about. We could define a new 500 response code saying " burst request not
accepted, but here is the MPEG2 TS preamble in the dedicated RTP payload
format" as you suggested as well.

Then a minor comment: section 6.2 says: "A particularly important field in
the RAMS-I message
       carries the RTP sequence number of the first packet transmitted
       in the retransmission session to allow RTP_Rx to detect any
       missing initial packet(s).  Note that the first RTP packet
       transmitted in the retransmission session is not necessarily a
       burst packet.  It could be a payload-specific RTP packet (See
       [
<http://tools.ietf.org/html/draft-ietf-avt-rapid-acquisition-for-rtp-05#ref-
I-D.begen-avt-rtp-mpeg2ts-preamble> I-D.begen-avt-rtp-mpeg2ts-preamble] for
an example)." 

We should be more specific and require that the payload-specific RTP packets
must be payload type multiplexed and have the same SSRC as the
retransmission packets when deployed in RAMS scenario. This is in line with
your specification on the MPEG TS pre-amble payload format. 

Regards 
Tom

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 11 Jan 2010 15:35:54 +0100

Roni,
 
thanks to the pointer, but I did remotely follow the discussion on these
two specific mechanisms by which a Retransmission server can transmit
so-called MPEG2 TS preamble information extracted from the primary
multicast streams in dedicated packetse. I have no strong preference for
one or the other solution. The main point I wanted to make is that this
information can equally be part of the burst of retransmission packets
itself, which the "RTP payload format for MPEG 2 TS preamble" draft did
not seem to acknowledge or at least could raise some confusion on. IMO
it does not always provide much advantage sending this info in separate
packets (using either method as specified in the two drafts on this
topic) compared to sending the info in the RAMS burst -respecting the
retransmission semantics, i.e. the original RTP payload should not be
tampered with - especially when the media sender (or head-end) is paying
some attention to the way the MPEG2 TS stream in the SSM is composed.
 
Tom

________________________________

From: Roni Even [mailto:[email-masked]] 
Sent: maandag 11 januari 2010 14:49
To: VAN CAENEGEM Tom; [email-masked]
Subject: RE: [AVT] Comments on RTP Payload Format for "MPEG2-TS
Preamble"internet draft

Tom,

You should look also at
http://tools.ietf.org/html/draft-xia-avt-mpeg2ts-preamble-01 which
suggests to send the preamble as an original RFC2250 payload and does
not need post processing.

The first version of the above draft suggested sending the stream as
retransmission stream but at the breakout session in Hiroshima it was
conclude that since it will require to assign sequence numbers which are
not the original ones it will not be a regular RFC 4588 retransmission
packet

The xia draft is another option for sending preamble. The AVT chairs
asked in a previous email to look at both drafts and send comments

Roni Even as Individual. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
VAN CAENEGEM Tom
Sent: Monday, January 11, 2010 3:10 PM
To: [email-masked]
Subject: [AVT] Comments on RTP Payload Format for "MPEG2-TS Preamble"
internet draft

Ali, Erich 

Regards 
Tom

---

From: Roni Even <[email-masked]>
Date: Mon, 11 Jan 2010 17:42:11 +0200

Tom,

Both draft address the issue where the preamble information (or PSI -
Program Specific Information)  is dispersed in the MPEG2-TS stream and is
needed to de-multiplex the requested program.  I think that all agree that
you can receive them as part of the multicast stream but it was not clear
how to send them as retransmission if they are not sent before the IDR frame
in the MPEG2-TS.

The first draft from xia suggested something similar but required the
sequence number to be contiguous before the IDR RAMS packets. I am not sure
how your suggestion can work without changing the sequence numbers of the
RTP streams. Do you mean that the retransmission burst will have a non
contiguous RTP sequence numbers  for the retransmitted stream

Roni Even as Individual

From: VAN CAENEGEM Tom [mailto:[email-masked]] 
Sent: Monday, January 11, 2010 4:36 PM
To: Roni Even; [email-masked]
Subject: RE: [AVT] Comments on RTP Payload Format for "MPEG2-TS
Preamble"internet draft

Roni,

thanks to the pointer, but I did remotely follow the discussion on these two
specific mechanisms by which a Retransmission server can transmit so-called
MPEG2 TS preamble information extracted from the primary multicast streams
in dedicated packetse. I have no strong preference for one or the other
solution. The main point I wanted to make is that this information can
equally be part of the burst of retransmission packets itself, which the
"RTP payload format for MPEG 2 TS preamble" draft did not seem to
acknowledge or at least could raise some confusion on. IMO it does not
always provide much advantage sending this info in separate packets (using
either method as specified in the two drafts on this topic) compared to
sending the info in the RAMS burst -respecting the retransmission semantics,
i.e. the original RTP payload should not be tampered with - especially when
the media sender (or head-end) is paying some attention to the way the MPEG2
TS stream in the SSM is composed.

Tom

  _____  

Tom,

You should look also at

Roni Even as Individual. 

 

Ali, Erich 

Regards 
Tom

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 11 Jan 2010 17:24:40 +0100

Hi Roni,
 
IMO the RS can send all relevant MPEG2 TS systems information as
retransmission packets, as long as this information is sent the same way
it was transmitted in the ssm. I.e. RTP packets are really retransmitted
and hence the RTP payload has not been altered. The retransmission
numbers of the packets in the retransmission session must be contiguous
(RFC 4588), e.g. retransmission packets with SN 1000 to SN 1020 carry
PSI information, extracted by the RS from the SSM  -but also non-PSI
information as in the GENERAL case, the RTP packets carry a mix of TS
packets belonging to PAT/PMT, audio, video, CA.. However the OSN field
indicates where in the SSM these RTP packets were originally positioned,
and these OSN fields have in GENERAL non-contiguous values. The next
packets in the retransmission session (SN 1021 and above) then typically
would have a contiguous SN space also in the OSN fields, as these
packets are sent in same order of appearance and contiguency as found
in the SSM. In this example the packet with SN 1021 carries for instance
the first information related to the RAP (non-PSI) from which the
decoder should start decoding. 
 
The packets in the burst retransmission session IMO can have any
original position in the primary SSM (as indicated in the OSN field),
but they must have contiguous SN in the retransmission session.  
 
The 1st draft of Xia suggested that a RS can pick out TS packets from a
number of RTP packets in the SSM, put them together in a single RTP
payload and send it as retransmission packet, but this violates RFC
4588. 
 
I agree that in the general case the solutions of both methods CAN be
more efficient compared to what I describe above (less "redundant" or
"garbage" info needs to be sent in the retransmission session), but then
again this is debatable as the source of the SSM could compose the SSM
stream taking into account PSI decoding/demuxing delay (if needed at the
cost of extra bitrate).  
Does this clarify?
 
Tom

From: Roni Even [mailto:[email-masked]] 
Sent: maandag 11 januari 2010 16:42
To: VAN CAENEGEM Tom; [email-masked]
Subject: RE: [AVT] Comments on RTP Payload Format for "MPEG2-TS
Preamble"internet draft

Tom,

Both draft address the issue where the preamble information (or PSI -
Program Specific Information)  is dispersed in the MPEG2-TS stream and
is needed to de-multiplex the requested program.  I think that all agree
that you can receive them as part of the multicast stream but it was not
clear how to send them as retransmission if they are not sent before the
IDR frame in the MPEG2-TS.

The first draft from xia suggested something similar but required the
sequence number to be contiguous before the IDR RAMS packets. I am not
sure how your suggestion can work without changing the sequence numbers
of the RTP streams. Do you mean that the retransmission burst will have
a non contiguous RTP sequence numbers  for the retransmitted stream

Roni Even as Individual

Roni,

Tom

Tom,

You should look also at

Roni Even as Individual. 

 

Ali, Erich 

Regards 
Tom

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 11 Jan 2010 09:34:07 -0800

Tom,

> TOM: The problem I have is the following: with RAMS, all Reference information can be
> transported as retransmission packets; i.e. retransmitted in the same way this payload
> information was present and transported, encapsulated as RTP packet, in the primary
> multicast, but with a RTP retransmission payload header. This includes the reference

We cannot transmit a "new" packet as a retransmission packet even if it carries information that was sent earlier in other packets. If the content of the payload changes, it is a new packet.

> information related to MPEG2 TS.  You call this "MPEG2 TS pre-amble", and I believe this
> naming is independent from the way this information is transferred to the RTP receiver
> (correct me if I am wrong).  So, I do not understand why you write : "For its proper
> transmission from the retransmission server to the joining RTP receiver, a new RTP payload
> format has to be defined for the MPEG2-TS Preamble."  As explained above, the "MPEG2TS
> preamble" information could equally be included in the RTP burst conmprising of (solely)
> retransmission packets.  I think your sentence should be replaced with something like:
> 
> "this draft defines a dedicated payload format for transporting MPEG2 TS preamble
> information"

Wfm. Note that we pt-multiplex these packets in the retransmission session that also sends the burst packets.
 
> I am not sure whether this RTP payload format also has applications outside RAMS? If not,
> then I think more text is needed explaining why and in which cases there is need for such
> a MPEG2 TS preamble payload format, instead of relying on just sending a burst of
> retransmission packets.

I can't think of any. In non-multicast applications, it does not have much use IMO. But, if you think it has, please let us know. RAMS is the target scenario for this work.
 
> Also the sentence "Since the RTP packet(s) carrying the MPEG2-TS Preamble will not be able
> to fed to the decoder in the form they are received, a post-processing is required at the
> RTP receiver." is not correct IMO, as RTP retransmission packets carrying the MPEG2 TS
> preamble information in the way I explained above, do not need post-processing, other than
> RTP layer decapsulation.

I guess you missed the point here. We are not using (cannot use) 4588 format as the stuff we put in this packet is a new content. We use TLV encoding and post processing for all the reasons I explained earlier in this list and my presentations. In summary, it gives us the flexibility and extensibility for various kinds of clients, and it helps us start decoding sooner. It is true that we need a light-weight post-processing on the receiver side, but we believe our approach offers a much better trade-off.

> 
> As this draft is strongly linked to the RAMS draft, I have some other comments related to
> the MPEG2 TS preamble or app. -specific packets that can be sent along a burst of
> retransmision packets in a single retransmission session making use of RAMS.
> 
> IMO we do not need a new RAMS-R TLV element that requests only the preamble from the
> server, as you have written in your last email summarising the resolution of the received
> WGLC comments. I think the meaning of this new TLV should indicate "RTP receiver supports
> the MPEG2 TS preamble payload format". This is because when an RTP receiver issues a RAMS-
> R, this is basically to receive a burst of packets. This is what the RAMS draft is about.

You have a valid point, but the preamble info even w/o the burst packets may potentially offer acceleration. This is true for mpeg2-ts and I expect it will also be true for other media formats. So, including this makes sense to me. Also note that other preamble drafts can be defined later for other applications.

> We could define a new 500 response code saying " burst request not accepted, but here is
> the MPEG2 TS preamble in the dedicated RTP payload format" as you suggested as well.

Agree this makes sense.

> Then a minor comment: section 6.2 says: "A particularly important field in the RAMS-I
> message
>        [I-D.begen-avt-rtp-mpeg2ts-preamble <http://tools.ietf.org/html/draft-ietf-avt-
> rapid-acquisition-for-rtp-05#ref-I-D.begen-avt-rtp-mpeg2ts-preamble> ] for an example)."
> 
> 
> We should be more specific and require that the payload-specific RTP packets must be
> payload type multiplexed and have the same SSRC as the retransmission packets when
> deployed in RAMS scenario. This is in line with your specification on the MPEG TS pre-
> amble payload format.

Yes, we should say this explicitly. Good catch.

Cheers, acbegen.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 11 Jan 2010 09:49:32 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of VAN CAENEGEM Tom
> Sent: Monday, January 11, 2010 8:25 AM
> Subject: Re: [AVT] Comments on RTP Payload Format for "MPEG2-TSPreamble"internet draft
> 
> Hi Roni,
> 
> IMO the RS can send all relevant MPEG2 TS systems information as retransmission packets,
> as long as this information is sent the same way it was transmitted in the ssm. I.e. RTP
> packets are really retransmitted and hence the RTP payload has not been altered. The
> retransmission numbers of the packets in the retransmission session must be contiguous
> (RFC 4588), e.g. retransmission packets with SN 1000 to SN 1020 carry PSI information,
> extracted by the RS from the SSM  -but also non-PSI information as in the GENERAL case,
> the RTP packets carry a mix of TS packets belonging to PAT/PMT, audio, video, CA.. However
> the OSN field indicates where in the SSM these RTP packets were originally positioned, and
> these OSN fields have in GENERAL non-contiguous values. The next packets in the
> retransmission session (SN 1021 and above) then typically would have a contiguous SN space
> also in the OSN fields, as these packets are sent in same order of appearance and
> contiguency as found  in the SSM. In this example the packet with SN 1021 carries for
> instance the first information related to the RAP (non-PSI) from which the decoder should
> start decoding.
> 
> The packets in the burst retransmission session IMO can have any original position in the
> primary SSM (as indicated in the OSN field), but they must have contiguous SN in the
> retransmission session.
> 
> The 1st draft of Xia suggested that a RS can pick out TS packets from a number of RTP
> packets in the SSM, put them together in a single RTP payload and send it as
> retransmission packet, but this violates RFC 4588.
> 
> I agree that in the general case the solutions of both methods CAN be more efficient
> compared to what I describe above (less "redundant" or "garbage" info needs to be sent in
> the retransmission session), but then again this is debatable as the source of the SSM
> could compose the SSM stream taking into account PSI decoding/demuxing delay (if needed at
> the cost of extra bitrate).

If we could make sure that this was always the case, we would be all happy and go home. But, the mpeg2-ts by itself does not pay attention to this stuff. It was defined years ago for broadcast purposes, etc. where our current problems did not exist.

When the preamble information is highly dispersed, retransmitting all the RTP packets that include any single bit of that information is highly inefficient and increases the failure probability by a large margin. When the TS packets that include any single bit of the preamble info are used to create new RTP packets and are sent as new 2250 packets, I agree it gets more efficient and does not require post-processing. But, I am still not sure how the CC and other relevant fields are fixed to make sure that these preamble packets and the subsequent TS packets received in the burst forms a valid TS stream.

We took a different approach. We extract the information we indeed need and put them in TLV packets. Yes, TLV introduces some overhead but since we are not transmitting the stuffing bytes that are pretty common in 188-byte TS packets, the total data we will send will likely to be smaller (we usually need a single RTP packet for the whole preamble information). 

At the client, we post-process the data since it is in TLV format. But by doing so, we can have a decoder-agnostic RS that does not care what kind of decoders are available in the downstream. RS sends the preamble, and each client does its own post-processing to address the specific needs of its decoder and create a decoder-compliant TS stream. Most decoders allow us to program them before we feed the TS packets into the demux, too. This provides *additional* acceleration. That is the beauty of our approach.

Roni asked the WG to evaluate both of these options and decide on one of them. We would appreciate response from everybody including you.

I hope this clarifies why we do what we do.

Cheers, acbegen.

> Subject: RE: [AVT] Comments on RTP Payload Format for "MPEG2-TS Preamble"internet draft
> 
> 
> 
> Tom,
> 
> Both draft address the issue where the preamble information (or PSI – Program Specific
> Information)  is dispersed in the MPEG2-TS stream and is needed to de-multiplex the
> requested program.  I think that all agree that you can receive them as part of the
> multicast stream but it was not clear how to send them as retransmission if they are not
> sent before the IDR frame in the MPEG2-TS.
> 
> The first draft from xia suggested something similar but required the sequence number to
> be contiguous before the IDR RAMS packets. I am not sure how your suggestion can work
> without changing the sequence numbers of the RTP streams. Do you mean that the
> retransmission burst will have a non contiguous RTP sequence numbers  for the
> retransmitted stream
> 
> 
> 
> Roni Even as Individual
> 
> 
> 
> Subject: RE: [AVT] Comments on RTP Payload Format for "MPEG2-TS Preamble"internet draft
> 
> 
> 
> Roni,
> 
> 
> 
> thanks to the pointer, but I did remotely follow the discussion on these two specific
> mechanisms by which a Retransmission server can transmit so-called MPEG2 TS preamble
> information extracted from the primary multicast streams in dedicated packetse. I have no
> strong preference for one or the other solution. The main point I wanted to make is that
> this information can equally be part of the burst of retransmission packets itself, which
> the "RTP payload format for MPEG 2 TS preamble" draft did not seem to acknowledge or at
> least could raise some confusion on. IMO it does not always provide much advantage sending
> this info in separate packets (using either method as specified in the two drafts on this
> topic) compared to sending the info in the RAMS burst -respecting the retransmission
> semantics, i.e. the original RTP payload should not be tampered with - especially when the
> media sender (or head-end) is paying some attention to the way the MPEG2 TS stream in the
> SSM is composed.
> 
> 
> 
> Tom
> 
> 
> 
> Subject: RE: [AVT] Comments on RTP Payload Format for "MPEG2-TS Preamble"internet draft
> 
> Tom,
> 
> You should look also at http://tools.ietf.org/html/draft-xia-avt-mpeg2ts-preamble-01 which
> suggests to send the preamble as an original RFC2250 payload and does not need post
> processing.
> 
> The first version of the above draft suggested sending the stream as retransmission stream
> but at the breakout session in Hiroshima it was conclude that since it will require to
> assign sequence numbers which are not the original ones it will not be a regular RFC 4588
> retransmission packet
> 
> The xia draft is another option for sending preamble. The AVT chairs asked in a previous
> email to look at both drafts and send comments
> 
> 
> 
> Roni Even as Individual.
> 
> 
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of VAN CAENEGEM Tom
> Subject: [AVT] Comments on RTP Payload Format for "MPEG2-TS Preamble" internet draft
> 
> 
> 
> 
> 
> Ali, Erich
> 
> I have some questions and comments regarding the phrasing in the intro section of the
> MPEG2 TS preamble draft:
> You currently have:
> 
>    [I-D.ietf-avt-rapid-acquisition-for-rtp <http://tools.ietf.org/html/draft-begen-avt-
> rtp-mpeg2ts-preamble-04#ref-I-D.ietf-avt-rapid-acquisition-for-rtp> ] proposes an approach
> where
>    explains this process in Section 7 <http://tools.ietf.org/html/draft-begen-avt-rtp-
> mpeg2ts-preamble-04#section-7> .
> 
> 
>

---

From: Peilin Yang <[email-masked]>
Date: Tue, 12 Jan 2010 11:50:24 +0800

Hi Tom,
 
Thank you very much for concerning the preamble drafts.
 
I agree your opinion that "as RTP retransmission packets carrying the MPEG2
TS preamble information in the way I explained above, do not need
post-processing. ", because non post-processing solution is the best choice
to RTP receivers.
 
In the draft-xia-avt-mpeg2ts-preamble-01 it changed RTP retransmission
packets to an original RFC2250 payload. I think it doesn't cause new
questions because primary multicast stream is based on the original RFC2250
payboad. RTP receivers inherently support it.
 
About the source of the SSM taking into account PSI decoding/demuxing delay,
I also think some SSM streams support it. I got some MPEG2-TS steams from
several different operators, some of them like as you said that the PAT/PMT
is contiguous to IDR frame; some of them don't like as you said that the
PAT/PMT is far away and span dozens of RTP packets, and even several
hundreds RTP packets. So in the draft-xia-avt-mpeg2ts-preamble, we pick out
PSI TS packets and put them together and sent it.
 
Peilin

  _____  

发件人: [email-masked] [mailto:[email-masked]] 代表 VAN CAENEGEM
Tom
发送时间: 2010年1月12日 0:25
收件人: Roni Even; [email-masked]
主题: Re: [AVT] Comments on RTP Payload Format for "MPEG2-TS
Preamble"internet draft

Hi Roni,
 
IMO the RS can send all relevant MPEG2 TS systems information as
retransmission packets, as long as this information is sent the same way it
was transmitted in the ssm. I.e. RTP packets are really retransmitted and
hence the RTP payload has not been altered. The retransmission numbers of
the packets in the retransmission session must be contiguous (RFC 4588),
e.g. retransmission packets with SN 1000 to SN 1020 carry PSI information,
extracted by the RS from the SSM  -but also non-PSI information as in the
GENERAL case, the RTP packets carry a mix of TS packets belonging to
PAT/PMT, audio, video, CA.. However the OSN field indicates where in the SSM
these RTP packets were originally positioned, and these OSN fields have in
GENERAL non-contiguous values. The next packets in the retransmission
session (SN 1021 and above) then typically would have a contiguous SN space
also in the OSN fields, as these packets are sent in same order of
appearance and contiguency as found  in the SSM. In this example the packet
with SN 1021 carries for instance the first information related to the RAP
(non-PSI) from which the decoder should start decoding. 
 
The packets in the burst retransmission session IMO can have any original
position in the primary SSM (as indicated in the OSN field), but they must
have contiguous SN in the retransmission session.  
 
The 1st draft of Xia suggested that a RS can pick out TS packets from a
number of RTP packets in the SSM, put them together in a single RTP payload
and send it as retransmission packet, but this violates RFC 4588. 
 
I agree that in the general case the solutions of both methods CAN be more
efficient compared to what I describe above (less "redundant" or "garbage"
info needs to be sent in the retransmission session), but then again this is
debatable as the source of the SSM could compose the SSM stream taking into
account PSI decoding/demuxing delay (if needed at the cost of extra
bitrate).  
Does this clarify?
 
Tom

  _____  

Tom,

Both draft address the issue where the preamble information (or PSI –

Roni Even as Individual

Roni,

Tom

  _____  

Tom,

You should look also at

Roni Even as Individual. 

 

Ali, Erich 

Regards 
Tom

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Tue, 12 Jan 2010 11:04:20 +0100

Ali, 

Thanks for your response. See below for further discussion. 
Tom

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: maandag 11 januari 2010 18:34
To: VAN CAENEGEM Tom; [email-masked]
Subject: RE: [AVT] Comments on RTP Payload Format for "MPEG2-TS
Preamble"internet draft

Tom,

> with a RTP retransmission payload header. This includes the reference

We cannot transmit a "new" packet as a retransmission packet even if it
carries information that was sent earlier in other packets. If the
content of the payload changes, it is a new packet.

TOM: agreed, but that is not what I meant

> is transferred to the RTP receiver (correct me if I am wrong).  So, I 
> do not understand why you write : "For its proper transmission from 
> the retransmission server to the joining RTP receiver, a new RTP 
> payload format has to be defined for the MPEG2-TS Preamble."  As 
> explained above, the "MPEG2TS preamble" information could equally be
included in the RTP burst conmprising of (solely) retransmission
packets.  I think your sentence should be replaced with something like:
> 
> "this draft defines a dedicated payload format for transporting MPEG2 
> TS preamble information"

Wfm. Note that we pt-multiplex these packets in the retransmission
session that also sends the burst packets.

TOM .. Wfm = works for me? The point I wanted to make is that MPEG2 TS
(preamble) reference information can (MAY if you like) be sent in the
burst of retransmission packets. This can even be done in two ways, w/o
altering the RTP packet payloads: 
1) the RS selects a starting point in the cached SSM packets containing
all pre-amble information, and from there onwards retransmits all ssm
packets. This could work (i.e. still result in a "channel change" faster
compared to normal SSM join process) if SSM MPEG2 TS are properly
composed and/or burst speeds are sufficiently high.
2) the RS selects the minimum set of RTP packets from the recent history
for inclusion in the retransmission burst, making sure that the minimum
required MPEG2 TS reference info is included, along with the RAP data.
(see my example in the response I sent to Roni)

Again, I agree these are not the most efficient solutions in the general
case, but they are in conflict with your statement ""For its proper
transmission from the retransmission server to the joining RTP receiver,
a new RTP payload format has to be defined for the MPEG2-TS Preamble." 
 
packets.

I can't think of any. In non-multicast applications, it does not have
much use IMO. But, if you think it has, please let us know. RAMS is the
target scenario for this work.

TOM: Agree that it makes only sense for RAMS. But do you think it makes
sense for SSM without RAMS?

I guess you missed the point here. We are not using (cannot use) 4588
format as the stuff we put in this packet is a new content. We use TLV
encoding and post processing for all the reasons I explained earlier in
this list and my presentations. In summary, it gives us the flexibility
and extensibility for various kinds of clients, and it helps us start
decoding sooner. It is true that we need a light-weight post-processing
on the receiver side, but we believe our approach offers a much better
trade-off.

TOM: ..and I think you missed my point. Your statement I quoted above is
only valid if MPEG2 TS preamble info is embedded as TLVs transmitted
with a dedicated RTP payload type. So your sentence should become
something like: "If the MPEG2-TS Preamble information is transmitted in
packets using the RTP payload type as defined in this draft, these
packets will not be able to fed to the decoder in the form they are
received, and a post-processing is required at the RTP receiver." 

> comments related to the MPEG2 TS preamble or app. -specific packets 
> that can be sent along a burst of retransmision packets in a single
> meaning of this new TLV should indicate "RTP receiver supports the 
> MPEG2 TS preamble payload format". This is because when an RTP
receiver issues a RAMS- R, this is basically to receive a burst of
packets. This is what the RAMS draft is about.

You have a valid point, but the preamble info even w/o the burst packets
may potentially offer acceleration. This is true for mpeg2-ts and I
expect it will also be true for other media formats. So, including this
makes sense to me. Also note that other preamble drafts can be defined
later for other applications.

Tom: I think we agreed that RAMS draft should be about a payload
agnostic way of SSM acceleration. For that matter, it should be even
considered to define this "MPEG2 TS preamble support" TLV -to be
inserted in the RAMS-R message- in the "MPEG2 TS preamble draft" and not
in the RAMS draft. And even when defining this TLV in the  "MPEG2 TS
preamble draft" , I cannot really think of a reason why a receiver only
wants MPEG2 TS preamble reference information and refuses to accept the
other reference information. The receiver restrictions in terms of
bandwidth or buffering capacity can be signaled by means of other TLVs,
and then it is up to the RS to decide what to do: send only the MPEG2 TS
preamble (with associated response code) or send all reference
information.

> We could define a new 500 response code saying " burst request not 
> accepted, but here is the MPEG2 TS preamble in the dedicated RTP
payload format" as you suggested as well.

Agree this makes sense.

> Then a minor comment: section 6.2 says: "A particularly important 
> field in the RAMS-I message
> <http://tools.ietf.org/html/draft-ietf-avt-

> with your specification on the MPEG TS pre- amble payload format.

Cheers, acbegen.

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Tue, 12 Jan 2010 11:54:55 +0100

Ali, see below
Tom 

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: maandag 11 januari 2010 18:50
To: VAN CAENEGEM Tom; Roni Even; [email-masked]
Subject: RE: [AVT] Comments on RTP Payload Format for
"MPEG2-TSPreamble"internet draft

> retransmission packets, as long as this information is sent the same 
> way it was transmitted in the ssm. I.e. RTP packets are really 
> retransmitted and hence the RTP payload has not been altered. The 
> retransmission numbers of the packets in the retransmission session 
> must be contiguous (RFC 4588), e.g. retransmission packets with SN 
> 1000 to SN 1020 carry PSI information, extracted by the RS from the 
> SSM  -but also non-PSI information as in the GENERAL case, the RTP 
> packets carry a mix of TS packets belonging to PAT/PMT, audio, video, 
> CA.. However the OSN field indicates where in the SSM these RTP 
> packets were originally positioned, and these OSN fields have in 
> session (SN 1021 and above) then typically would have a contiguous SN 
> space also in the OSN fields, as these packets are sent in same order
of appearance and contiguency as found  in the SSM. In this example the
packet with SN 1021 carries for instance the first information related
to the RAP (non-PSI) from which the decoder should start decoding.
> The 1st draft of Xia suggested that a RS can pick out TS packets from 
> a number of RTP packets in the SSM, put them together in a single RTP 
4588.
> "garbage" info needs to be sent in the retransmission session), but 
> then again this is debatable as the source of the SSM could compose 
> the SSM stream taking into account PSI decoding/demuxing delay (if
needed at the cost of extra bitrate).

If we could make sure that this was always the case, we would be all
happy and go home. But, the mpeg2-ts by itself does not pay attention to
this stuff. It was defined years ago for broadcast purposes, etc. where
our current problems did not exist.

When the preamble information is highly dispersed, retransmitting all
the RTP packets that include any single bit of that information is
highly inefficient and increases the failure probability by a large
margin. When the TS packets that include any single bit of the preamble
info are used to create new RTP packets and are sent as new 2250
packets, I agree it gets more efficient and does not require
post-processing. But, I am still not sure how the CC and other relevant
fields are fixed to make sure that these preamble packets and the
subsequent TS packets received in the burst forms a valid TS stream.

Tom: it was not my objective to provide a preference for one of the two
solutions that may provide a more efficient means of providing MPEG2 TS
reference information, but here are my thoughts... In the proposal of
Xia it may not be excluded that these MPEG2 TS fields are adjusted in
the RTP packets carrying this MPEG2 TS premable info, such that the
aggregated RTP packet payload of the pre-amble info (transmitted as
MPEG2 TS payload type) and the retransmission packets, together do form
a compliant TS stream. The Xia proposal hence puts some more processing
load at the server side, but not sure that is significant. If this
processing is not done, then it can probably not be guaranteed that the
decoder correctly behaves ( unless there is again some postprocessing
done at the receiver side?). Does the TS spec say anything about what
the decoder should do when e.g. CC is not contiguous?

We took a different approach. We extract the information we indeed need
and put them in TLV packets. Yes, TLV introduces some overhead but since
we are not transmitting the stuffing bytes that are pretty common in
188-byte TS packets, the total data we will send will likely to be
smaller (we usually need a single RTP packet for the whole preamble
information). 

At the client, we post-process the data since it is in TLV format. But
by doing so, we can have a decoder-agnostic RS that does not care what
kind of decoders are available in the downstream. RS sends the preamble,
and each client does its own post-processing to address the specific
needs of its decoder and create a decoder-compliant TS stream. Most
decoders allow us to program them before we feed the TS packets into the
demux, too. This provides *additional* acceleration. That is the beauty
of our approach.

Roni asked the WG to evaluate both of these options and decide on one of
them. We would appreciate response from everybody including you.

Tom: see my answer above. The "cleanest/safest" approach is the one
defined in your draft, but the Xia proposal may work equally well. Both
solutions provide in the general case more efficiency compared to having
a RS making sure that all MPEG2TS reference information is inside the
retransmission burst, w/o breaking RFC 4588. We should IMO not define
three solutions to do the same thing. 

Cheers, acbegen.

> Program Specific
> Information)  is dispersed in the MPEG2-TS stream and is needed to 
> de-multiplex the requested program.  I think that all agree that you 
> can receive them as part of the multicast stream but it was not clear 
> how to send them as retransmission if they are not sent before the IDR
frame in the MPEG2-TS.

> sure how your suggestion can work without changing the sequence 
> numbers of the RTP streams. Do you mean that the retransmission burst 
> will have a non contiguous RTP sequence numbers  for the retransmitted

> stream
> thanks to the pointer, but I did remotely follow the discussion on 
> these two specific mechanisms by which a Retransmission server can 
> transmit so-called MPEG2 TS preamble information extracted from the 
> primary multicast streams in dedicated packetse. I have no strong 
> preference for one or the other solution. The main point I wanted to 
> make is that this information can equally be part of the burst of 
> retransmission packets itself, which the "RTP payload format for MPEG 
> 2 TS preamble" draft did not seem to acknowledge or at least could 
> raise some confusion on. IMO it does not always provide much advantage

> sending this info in separate packets (using either method as 
> specified in the two drafts on this
> tampered with - especially when the media sender (or head-end) is 
> paying some attention to the way the MPEG2 TS stream in the SSM is
composed.
> conclude that since it will require to assign sequence numbers which 
> are not the original ones it will not be a regular RFC 4588 
> retransmission packet
> 

> <http://tools.ietf.org/html/draft-begen-avt-
> rtp-mpeg2ts-preamble-04#ref-I-D.ietf-avt-rapid-acquisition-for-rtp> ] 
> <http://tools.ietf.org/html/draft-begen-avt-rtp-

packets.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 12 Jan 2010 22:44:39 -0800

Hi Tom,

...
> TOM .. Wfm = works for me? The point I wanted to make is that MPEG2 TS

Yes.

> composed and/or burst speeds are sufficiently high.

Correct. Actually if this was indeed the case, we would not need the preamble stuff. But this is hardly the case.

> (see my example in the response I sent to Roni)

Sure, this also works. 
 
> a new RTP payload format has to be defined for the MPEG2-TS Preamble."

Yes, the sentence we had is not a good one. It did not reflect what we meant. I already made the change for the next revision. Thanks for catching this.
 
> sense for SSM without RAMS?

Not sure.
 
> received, and a post-processing is required at the RTP receiver."

Sounds good to me.
 
> in the RAMS draft. And even when defining this TLV in the  "MPEG2 TS

We are not defining a tlv element to request only the mpeg2-ts preamble in the RAMS draft. We are defining the TLV to request the preamble information carried in the SSM. It is generic preamble. So, I don’t see any harm in doing this.

> preamble (with associated response code) or send all reference

Valid point but I still think defining a tlv to request the preamble only makes sense.

Cheers,
-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 12 Jan 2010 22:44:40 -0800

Hi Tom,

> Sent: Tuesday, January 12, 2010 2:55 AM
> To: Ali C. Begen (abegen); Roni Even; [email-masked]
> Subject: RE: [AVT] Comments on RTP Payload Format for "MPEG2-TSPreamble"internet draft
> 
> Ali, see below
> Tom
> 

In my personal experience, some decoders won't care, but some others will flush the data and start from scratch (in which case we would be doing more harm than benefit by sending the preamble).
 
> three solutions to do the same thing.

We should not.

Note that in the last approach you defined above (i.e., choosing a burst starting point so that the burst indeed contains all the preamble) may force the server to choose a sub-optimal starting point (e.g., longer bursts and catch-up times). Furthermore, if the preamble is highly dispersed, the time that will take for the decoder to initialize will still be large. For these particular reasons, I am strongly supporting to do this by using tlv elements.

-acbegen

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Tue, 12 Jan 2010 23:28:00 -0800

Please see my comment in-line. I have deleted most of the original text for clarity and brevity.

--Sandy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C. Begen (abegen)
Sent: Tuesday, January 12, 2010 10:45 PM
To: VAN CAENEGEM Tom; Roni Even; [email-masked]
Subject: Re: [AVT] Comments on RTP Payload Format for "MPEG2-TSPreamble"internet draft

Hi Tom,

> the decoder should do when e.g. CC is not contiguous?

[Ali] In my personal experience, some decoders won't care, but some others will flush the data and start from scratch (in which case we would be doing more harm than benefit by sending the preamble).
 
[Sandy] I will address Tom's question immediately above. 
The MPEG-2 Systems (i.e. TS) standard specifies that the CC (continuity counter) must be continuously incrementing, with two specific exceptions where the increment does not occur (i.e. duplicate packet or the adaptation_field_control of the packet equals '00' or '10'), and one exception wherein the continuity counter may be discontinuous when the discontinuity_indicator is set to '1'. The latter is specified in section 2.4.3.4 in the standard. 

Section 2.4.3.4 says among other things:

"The discontinuity indicator is used to indicate two types of discontinuities, system time-base discontinuities and continuity_counter discontinuities.",

"A continuity_counter discontinuity is indicated by the use of the discontinuity_indicator in any Transport Stream packet.
When the discontinuity state is true in any Transport Stream packet of a PID not designated as a PCR_PID, the
continuity_counter in that packet may be discontinuous with respect to the previous Transport Stream packet of the same
PID. When the discontinuity state is true in a Transport Stream packet of a PID that is designated as a PCR_PID, the
continuity_counter may only be discontinuous in the packet in which a system time-base discontinuity occurs.",

"When the discontinuity state is true in a Transport Stream packet of a PID that is designated as a PCR_PID, the
continuity_counter may only be discontinuous in the packet in which a system time-base discontinuity occurs."

and

"A continuity counter discontinuity point shall occur at most one time from the initiation of the discontinuity state
until the conclusion of the discontinuity state."

The MPEG-TS standard doesn't dictate what decoders should do. However the intention is that decoders will detect CC errors or unmarked discontinuities as stream errors, and take corrective action. Decoder designers may choose whatever corrective action they want, which could include continuing as if nothing happened, treating it like a major stream error, or something else.

Conforming MPEG-TS streams are not allowed to have discontinuous CC values except where they are specifically allowed, i.e. as above.
Note that if the PCR PID has a marked discontinuity, that means there is a time base discontinuity. So if you try to convey a new time base to a decoder using discontinuous CC values (especially if there is a discontinuity after the special packets) there is a real risk of not achieving that goal, since the decoder may not believe the time base implied by the special packets. 

It may be possible to utilize the discontinuity indicator in such a way that the resulting stream conforms to the standard. However, even then, if the result is unusual compared to what decoder designers were expecting, there could possibly be some unintended results.

If we want to create conforming MPEG-TS streams as a result of the preamble burst, it's safest if some entity corrects the CC values before the decoder sees the new set of packets. Actually, making a conforming stream may be more complex than that, depending on what exactly is in the inserted packets from the burst, there's more to it than the CC. If we want to assume that streams that do not conform in this regard are OK, that may be a viable option, and whether it is or not depends on the designs of the decoders (and the software that controls them) to be supported.

I don't currently have a preference between the two proposals.

--Sandy MacInnis, Broadcom

P.S. I was the MPEG Systems committee chairman responsible for the MPEG TS standard. However I don't remember every detail and discussion off-hand, as it has been a long time. We finished the original MPEG-2 Systems standard in 1994.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 12 Jan 2010 23:36:46 -0800

Well, thanks for clearing this up for us. One comment only.

> If we want to create conforming MPEG-TS streams as a result of the preamble burst, it's
> safest if some entity corrects the CC values before the decoder sees the new set of

This is something we do in our post processing.

Cheers, acbegen.

> From: Sandy (Alexander) MacInnis [mailto:[email-masked]]
> Sent: Tuesday, January 12, 2010 11:28 PM
> To: Ali C. Begen (abegen); VAN CAENEGEM Tom; Roni Even; [email-masked]
> [Ali] In my personal experience, some decoders won't care, but some others will flush the
> data and start from scratch (in which case we would be doing more harm than benefit by
> sending the preamble).
> 
> The MPEG-2 Systems (i.e. TS) standard specifies that the CC (continuity counter) must be
> continuously incrementing, with two specific exceptions where the increment does not occur
> (i.e. duplicate packet or the adaptation_field_control of the packet equals '00' or '10'),
> and one exception wherein the continuity counter may be discontinuous when the
> discontinuity_indicator is set to '1'. The latter is specified in section 2.4.3.4 in the
> standard.
> 
> "The discontinuity indicator is used to indicate two types of discontinuities, system
> time-base discontinuities and continuity_counter discontinuities.",
> 
> The MPEG-TS standard doesn't dictate what decoders should do. However the intention is
> that decoders will detect CC errors or unmarked discontinuities as stream errors, and take
> corrective action. Decoder designers may choose whatever corrective action they want,
> which could include continuing as if nothing happened, treating it like a major stream
> error, or something else.
> 
> Conforming MPEG-TS streams are not allowed to have discontinuous CC values except where
> they are specifically allowed, i.e. as above.
> Note that if the PCR PID has a marked discontinuity, that means there is a time base
> discontinuity. So if you try to convey a new time base to a decoder using discontinuous CC
> values (especially if there is a discontinuity after the special packets) there is a real
> risk of not achieving that goal, since the decoder may not believe the time base implied
> by the special packets.
> 
> It may be possible to utilize the discontinuity indicator in such a way that the resulting
> stream conforms to the standard. However, even then, if the result is unusual compared to
> what decoder designers were expecting, there could possibly be some unintended results.
> 
> If we want to create conforming MPEG-TS streams as a result of the preamble burst, it's
> safest if some entity corrects the CC values before the decoder sees the new set of
> packets. Actually, making a conforming stream may be more complex than that, depending on
> what exactly is in the inserted packets from the burst, there's more to it than the CC. If
> we want to assume that streams that do not conform in this regard are OK, that may be a
> viable option, and whether it is or not depends on the designs of the decoders (and the
> software that controls them) to be supported.
> 
> P.S. I was the MPEG Systems committee chairman responsible for the MPEG TS standard.
> However I don't remember every detail and discussion off-hand, as it has been a long time.
> We finished the original MPEG-2 Systems standard in 1994.

---

From: Peilin Yang <[email-masked]>
Date: Thu, 14 Jan 2010 14:54:57 +0800

Hi Tom, 

Thank you very much for your comments to Xia's draft.

I extracted parts of  your comments as follows. 
"Tom: it was not my objective to provide a preference for one of the two
solutions that may provide a more efficient means of providing MPEG2 TS
reference information, but here are my thoughts... In the proposal of Xia it
may not be excluded that these MPEG2 TS fields are adjusted in the RTP
packets carrying this MPEG2 TS premable info, such that the aggregated RTP
packet payload of the pre-amble info (transmitted as MPEG2 TS payload type)
and the retransmission packets, together do form a compliant TS stream. The
Xia proposal hence puts some more processing load at the server side, but
not sure that is significant. If this processing is not done, then it can
probably not be guaranteed that the decoder correctly behaves ( unless there
is again some postprocessing done at the receiver side?). Does the TS spec
say anything about what the decoder should do when e.g. CC is not
contiguous?"

Peilin: Yes, you are right. Xia's draft need to adjust MPEG2 TS preamble
information in the new RTP packets to form a compliant TS stream. Yet this
processing doesn't affect the CC continuity of PSIs because commonly every
PID has its own independent continuity counter. That is to say, PAT has its
own CC from 0x0 to 0xF independently, PMT also has its own CC from 0x0 to
0xF independently. 
Tom, you also mentioned that "The Xia proposal hence puts some more
processing load at the server side". I don't understand which more
processing load have done at the serer side. In Xia's draft it need to
investigate TSs' header to find PSIs' packets and adjust them in the RTP
packets, and choose the lastest PSIs' packets before transmitting them. 

Peilin 

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 VAN CAENEGEM
Tom
发送时间: 2010年1月12日 18:55
收件人: Ali C. Begen (abegen); Roni Even; [email-masked]
主题: Re: [AVT] Comments on RTP Payload Format for"MPEG2-TSPreamble"internet
draft

Ali, see below
Tom 

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]]
Sent: maandag 11 januari 2010 18:50
To: VAN CAENEGEM Tom; Roni Even; [email-masked]
Subject: RE: [AVT] Comments on RTP Payload Format for

4588.

Cheers, acbegen.

frame in the MPEG2-TS.

composed.

packets.

> with your specification on the MPEG TS pre- amble payload format.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Peilin Yang <[email-masked]>
Date: Thu, 14 Jan 2010 15:20:07 +0800

Dear Sandy,

Thank you very much for giving clear explantion for CC continuity.
We cognized the question of the CC when implementing the solution so that we
chose the raw MPEG2-TS packets to construct the RTP packets.

Best regards,

Peilin 

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Sandy
(Alexander) MacInnis
发送时间: 2010年1月13日 15:28
收件人: Ali C. Begen (abegen); VAN CAENEGEM Tom; Roni Even; [email-masked]
主题: Re: [AVT] Comments on RTP Payload Format for
"MPEG2-TSPreamble"internet draft

Please see my comment in-line. I have deleted most of the original text for
clarity and brevity.

--Sandy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C.
Begen (abegen)
Sent: Tuesday, January 12, 2010 10:45 PM
To: VAN CAENEGEM Tom; Roni Even; [email-masked]
Subject: Re: [AVT] Comments on RTP Payload Format for
"MPEG2-TSPreamble"internet draft

Hi Tom,

> Tom: it was not my objective to provide a preference for one of the 
> two solutions that may provide a more efficient means of providing 
> MPEG2 TS reference information, but here are my thoughts... In the 
> proposal of Xia it may not be excluded that these MPEG2 TS fields are 
> adjusted in the RTP packets carrying this MPEG2 TS premable info, such 
> that the aggregated RTP packet payload of the pre-amble info 
> (transmitted as
> MPEG2 TS payload type) and the retransmission packets, together do 
> form a compliant TS stream. The Xia proposal hence puts some more 
> processing load at the server side, but not sure that is significant. 
> If this processing is not done, then it can probably not be guaranteed 
> that the decoder correctly behaves ( unless there is again some 
> postprocessing done at the receiver side?). Does the TS spec say 
> anything about what the decoder should do when e.g. CC is not contiguous?

[Ali] In my personal experience, some decoders won't care, but some others
will flush the data and start from scratch (in which case we would be doing
more harm than benefit by sending the preamble).
 
[Sandy] I will address Tom's question immediately above. 
The MPEG-2 Systems (i.e. TS) standard specifies that the CC (continuity
counter) must be continuously incrementing, with two specific exceptions
where the increment does not occur (i.e. duplicate packet or the
adaptation_field_control of the packet equals '00' or '10'), and one
exception wherein the continuity counter may be discontinuous when the
discontinuity_indicator is set to '1'. The latter is specified in section 2.
4.3.4 in the standard. 

"The discontinuity indicator is used to indicate two types of
discontinuities, system time-base discontinuities and continuity_counter
discontinuities.",

"A continuity_counter discontinuity is indicated by the use of the
discontinuity_indicator in any Transport Stream packet.
When the discontinuity state is true in any Transport Stream packet of a PID
not designated as a PCR_PID, the continuity_counter in that packet may be
discontinuous with respect to the previous Transport Stream packet of the
same PID. When the discontinuity state is true in a Transport Stream packet
of a PID that is designated as a PCR_PID, the continuity_counter may only be
discontinuous in the packet in which a system time-base discontinuity
occurs.",

"When the discontinuity state is true in a Transport Stream packet of a PID
that is designated as a PCR_PID, the continuity_counter may only be
discontinuous in the packet in which a system time-base discontinuity
occurs."

and

"A continuity counter discontinuity point shall occur at most one time from
the initiation of the discontinuity state until the conclusion of the
discontinuity state."

The MPEG-TS standard doesn't dictate what decoders should do. However the
intention is that decoders will detect CC errors or unmarked discontinuities
as stream errors, and take corrective action. Decoder designers may choose
whatever corrective action they want, which could include continuing as if
nothing happened, treating it like a major stream error, or something else.

Conforming MPEG-TS streams are not allowed to have discontinuous CC values
except where they are specifically allowed, i.e. as above.
Note that if the PCR PID has a marked discontinuity, that means there is a
time base discontinuity. So if you try to convey a new time base to a
decoder using discontinuous CC values (especially if there is a
discontinuity after the special packets) there is a real risk of not
achieving that goal, since the decoder may not believe the time base implied
by the special packets. 

It may be possible to utilize the discontinuity indicator in such a way that
the resulting stream conforms to the standard. However, even then, if the
result is unusual compared to what decoder designers were expecting, there
could possibly be some unintended results.

If we want to create conforming MPEG-TS streams as a result of the preamble
burst, it's safest if some entity corrects the CC values before the decoder
sees the new set of packets. Actually, making a conforming stream may be
more complex than that, depending on what exactly is in the inserted packets
from the burst, there's more to it than the CC. If we want to assume that
streams that do not conform in this regard are OK, that may be a viable
option, and whether it is or not depends on the designs of the decoders (and
the software that controls them) to be supported.

P.S. I was the MPEG Systems committee chairman responsible for the MPEG TS
standard. However I don't remember every detail and discussion off-hand, as
it has been a long time. We finished the original MPEG-2 Systems standard in
1994.

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Thu, 14 Jan 2010 10:44:18 +0100

Hi Peilin,

If the RS does not need to modify anything inside the MPEG2 TS packets before transmitting them in the retransmission session, then I agree that no dedicated MPEG2 TS processing needs to be done by the RS in your proposal. I thought that making sure that CC is contiguous would be one of the responsabilities, but that seems not the case as the CC is indeed per PID.
Regards,
Tom

-----Original Message-----
From: Peilin Yang [mailto:[email-masked]] 
Sent: donderdag 14 januari 2010 7:55
To: VAN CAENEGEM Tom
Cc: 'Roni Even'; [email-masked]
Subject: About CC continuity - Re: [AVT] Comments on RTP Payload Format for"MPEG2-TSPreamble"internet draft

Hi Tom, 

I extracted parts of  your comments as follows. 
"Tom: it was not my objective to provide a preference for one of the two solutions that may provide a more efficient means of providing MPEG2 TS reference information, but here are my thoughts... In the proposal of Xia it may not be excluded that these MPEG2 TS fields are adjusted in the RTP packets carrying this MPEG2 TS premable info, such that the aggregated RTP packet payload of the pre-amble info (transmitted as MPEG2 TS payload type) and the retransmission packets, together do form a compliant TS stream. The Xia proposal hence puts some more processing load at the server side, but not sure that is significant. If this processing is not done, then it can probably not be guaranteed that the decoder correctly behaves ( unless there is again some postprocessing done at the receiver side?). Does the TS spec say anything about what the decoder should do when e.g. CC is not contiguous?"

Peilin: Yes, you are right. Xia's draft need to adjust MPEG2 TS preamble information in the new RTP packets to form a compliant TS stream. Yet this processing doesn't affect the CC continuity of PSIs because commonly every PID has its own independent continuity counter. That is to say, PAT has its own CC from 0x0 to 0xF independently, PMT also has its own CC from 0x0 to 0xF independently. 
Tom, you also mentioned that "The Xia proposal hence puts some more processing load at the server side". I don't understand which more processing load have done at the serer side. In Xia's draft it need to investigate TSs' header to find PSIs' packets and adjust them in the RTP packets, and choose the lastest PSIs' packets before transmitting them. 

Peilin 

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 VAN CAENEGEM Tom
发送时间: 2010年1月12日 18:55
收件人: Ali C. Begen (abegen); Roni Even; [email-masked]
主题: Re: [AVT] Comments on RTP Payload Format for"MPEG2-TSPreamble"internet draft

Ali, see below
Tom 

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]]
Sent: maandag 11 januari 2010 18:50
To: VAN CAENEGEM Tom; Roni Even; [email-masked]
Subject: RE: [AVT] Comments on RTP Payload Format for "MPEG2-TSPreamble"internet draft

> space also in the OSN fields, as these packets are sent in same order
of appearance and contiguency as found  in the SSM. In this example the packet with SN 1021 carries for instance the first information related to the RAP (non-PSI) from which the decoder should start decoding.
4588.

Tom: it was not my objective to provide a preference for one of the two solutions that may provide a more efficient means of providing MPEG2 TS reference information, but here are my thoughts... In the proposal of Xia it may not be excluded that these MPEG2 TS fields are adjusted in the RTP packets carrying this MPEG2 TS premable info, such that the aggregated RTP packet payload of the pre-amble info (transmitted as
MPEG2 TS payload type) and the retransmission packets, together do form a compliant TS stream. The Xia proposal hence puts some more processing load at the server side, but not sure that is significant. If this processing is not done, then it can probably not be guaranteed that the decoder correctly behaves ( unless there is again some postprocessing done at the receiver side?). Does the TS spec say anything about what the decoder should do when e.g. CC is not contiguous?

Tom: see my answer above. The "cleanest/safest" approach is the one defined in your draft, but the Xia proposal may work equally well. Both solutions provide in the general case more efficiency compared to having a RS making sure that all MPEG2TS reference information is inside the retransmission burst, w/o breaking RFC 4588. We should IMO not define three solutions to do the same thing. 

Cheers, acbegen.

frame in the MPEG2-TS.

composed.

packets.
> MPEG2 TS preamble payload format". This is because when an RTP
receiver issues a RAMS- R, this is basically to receive a burst of packets. This is what the RAMS draft is about.

---

From: Peilin YANG <[email-masked]>
Date: Thu, 14 Jan 2010 22:06:42 +0800

Hi Tom,

I got several MPEG2-TS streams from different operators. In these streams, CC is incrementing with the same PID. 
The following text is extracted from ITU-T Rec. H.222.0 | ISO/IEC 13818-1. It gives the description of continuity_counter as Sandy introduced - The continuity_counter is a 4-bit field incrementing with each Transport Stream packet with the same PID.

"2.4.3.3 Semantic definition of fields in Transport Stream packet layer
......
continuity_counter ?C The continuity_counter is a 4-bit field incrementing with each Transport Stream packet with the same PID. The continuity_counter wraps around to 0 after its maximum value. The continuity_counter shall not be incremented when the adaptation_field_control of the packet equals '00' or '10'.
In Transport Streams, duplicate packets may be sent as two, and only two, consecutive Transport Stream packets of the same PID. The duplicate packets shall have the same continuity_counter value as the original packet and the adaptation_field_control field shall be equal to '01' or '11'. In duplicate packets each byte of the original packet shall be duplicated, with the exception that in the program clock reference fields, if present, a val

id value shall be encoded.
The continuity_counter in a particular Transport Stream packet is continuous when it differs by a positive value of one from the continuity_counter value in the previous Transport Stream packet of the same PID, or when either of the non-incrementing conditions (adaptation_field_control set to '00' or '10', or duplicate packets as described above) are met. The continuity counter may be discontinuous when the discontinuity_indicator is set to

 '1' (refer to 2.4.3.4). In the case of a null packet the value of the continuity_counter is undefined. "

I have no idea if there are few cases which don't conform the CC regulation of  ITU-T Rec. H.222.0 | ISO/IEC 13818-1.  if present, I think it is only very little because it obeys the regulation of continuity_counter .

Peilin 

----- 原邮件 -----
发件人: VAN CAENEGEM Tom <[email-masked]>
日期: 星期四, 一月 14日, 2010 下午5:45
主题: RE: About CC continuity - Re: [AVT] Comments on RTP Payload Format for"MPEG2-TSPreamble"internet draft
收件人: Peilin Yang <[email-masked]>
抄送: Roni Even <[email-masked]>, [email-masked]

> Hi Peilin,
> 
> If the RS does not need to modify anything inside the MPEG2 TS 
> packets before transmitting them in the retransmission session, 
> then I agree that no dedicated MPEG2 TS processing needs to be 
> done by the RS in your proposal. I thought that making sure that 
> CC is contiguous would be one of the responsabilities, but that 
> seems not the case as the CC is indeed per PID.
> Regards,
> Tom
> 
> 
> Subject: About CC continuity - Re: [AVT] Comments on RTP Payload 
> Format for"MPEG2-TSPreamble"internet draft
> 
> Hi Tom, 
> 
> "Tom: it was not my objective to provide a preference for one of 
> the two solutions that may provide a more efficient means of 
> providing MPEG2 TS reference information, but here are my 
> thoughts... In the proposal of Xia it may not be excluded that 
> these MPEG2 TS fields are adjusted in the RTP packets carrying 
> this MPEG2 TS premable info, such that the aggregated RTP packet 
> payload of the pre-amble info (transmitted as MPEG2 TS payload 
> type) and the retransmission packets, together do form a compliant 
> TS stream. The Xia proposal hence puts some more processing load 
> at the server side, but not sure that is significant. If this 
> processing is not done, then it can probably not be guaranteed 
> anything about what the decoder should do when e.g. CC is not 
> contiguous?"
> Peilin: Yes, you are right. Xia's draft need to adjust MPEG2 TS 
> preamble information in the new RTP packets to form a compliant TS 
> stream. Yet this processing doesn't affect the CC continuity of 
> PSIs because commonly every PID has its own independent continuity 
> counter. That is to say, PAT has its own CC from 0x0 to 0xF 
> independently, PMT also has its own CC from 0x0 to 0xF 
> independently. 
> Tom, you also mentioned that "The Xia proposal hence puts some 
> more processing load at the server side". I don't understand which 
> more processing load have done at the serer side. In Xia's draft 
> it need to investigate TSs' header to find PSIs' packets and 
> adjust them in the RTP packets, and choose the lastest PSIs' 
> packets before transmitting them. 
> 
> Peilin 
> 
> -----邮件原件-----
> > space also in the OSN fields, as these packets are sent in same 
> orderof appearance and contiguency as found  in the SSM. In this 
> example the packet with SN 1021 carries for instance the first 
> information related to the RAP (non-PSI) from which the decoder 
> should start decoding.
> > 
> If we could make sure that this was always the case, we would be 
> all happy and go home. But, the mpeg2-ts by itself does not pay 
> attention to this stuff. It was defined years ago for broadcast 
> purposes, etc. where our current problems did not exist.
> 
> When the preamble information is highly dispersed, retransmitting 
> all the RTP packets that include any single bit of that 
> information is highly inefficient and increases the failure 
> probability by a large margin. When the TS packets that include 
> any single bit of the preamble info are used to create new RTP 
> packets and are sent as new 2250 packets, I agree it gets more 
> efficient and does not require post-processing. But, I am still 
> not sure how the CC and other relevant fields are fixed to make 
> sure that these preamble packets and the subsequent TS packets 
> received in the burst forms a valid TS stream.
> 
> Tom: it was not my objective to provide a preference for one of 
> the two solutions that may provide a more efficient means of 
> providing MPEG2 TS reference information, but here are my 
> thoughts... In the proposal of Xia it may not be excluded that 
> these MPEG2 TS fields are adjusted in the RTP packets carrying 
> this MPEG2 TS premable info, such that the aggregated RTP packet 
> payload of the pre-amble info (transmitted as
> processing load at the server side, but not sure that is 
> significant. If this processing is not done, then it can probably 
> not be guaranteed that the decoder correctly behaves ( unless 
> there is again some postprocessing done at the receiver side?). 
> Does the TS spec say anything about what the decoder should do 
> when e.g. CC is not contiguous?
> 
> We took a different approach. We extract the information we indeed 
> need and put them in TLV packets. Yes, TLV introduces some 
> overhead but since we are not transmitting the stuffing bytes that 
> are pretty common in 188-byte TS packets, the total data we will 
> send will likely to be smaller (we usually need a single RTP 
> packet for the whole preamble information). 
> 
> At the client, we post-process the data since it is in TLV format. 
> But by doing so, we can have a decoder-agnostic RS that does not 
> care what kind of decoders are available in the downstream. RS 
> sends the preamble, and each client does its own post-processing 
> to address the specific needs of its decoder and create a decoder-
> compliant TS stream. Most decoders allow us to program them before 
> we feed the TS packets into the demux, too. This provides 
> *additional* acceleration. That is the beauty of our approach.
> 
> Roni asked the WG to evaluate both of these options and decide on 
> one of them. We would appreciate response from everybody including 
> you.
> Tom: see my answer above. The "cleanest/safest" approach is the 
> one defined in your draft, but the Xia proposal may work equally 
> well. Both solutions provide in the general case more efficiency 
> compared to having a RS making sure that all MPEG2TS reference 
> information is inside the retransmission burst, w/o breaking RFC 
> 4588. We should IMO not define three solutions to do the same 
> thing. 
> 
> > retransmission packets itself, which the "RTP payload format for 
> MPEG> 2 TS preamble" draft did not seem to acknowledge or at least 
> could 
> > suggests to send the preamble as an original RFC2250 payload and 
> doesnot need post processing.
> > 
> >    document, we refer to the subset of the Reference Information 
> thatis
> >    Information the RTP receiver needs to rapidly acquire the 
> multicast>    session.  If the source stream in the RTP multicast 
> session is
> explained above, the "MPEG2TS preamble" information could equally 
> be included in the RTP burst conmprising of (solely) 
> >        carries the RTP sequence number of the first packet 
> transmitted>        in the retransmission session to allow RTP_Rx 
> to detect any
> > rapid-acquisition-for-rtp-05#ref-I-D.begen-avt-rtp-mpeg2ts-
> preamble> ]
> for an example)."
> > 
> > 
> >

---

From: Peilin Yang <[email-masked]>
Date: Thu, 14 Jan 2010 14:45:56 +0800

Hi Tom, 

Peilin

-----邮件原件-----

Ali, see below
Tom 

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]]
Sent: maandag 11 januari 2010 18:50
To: VAN CAENEGEM Tom; Roni Even; [email-masked]
Subject: RE: [AVT] Comments on RTP Payload Format for

4588.

Cheers, acbegen.

frame in the MPEG2-TS.

composed.

packets.

---

From: Peilin Yang <[email-masked]>
Date: Fri, 15 Jan 2010 15:57:07 +0800

Dear Sandy,
 
Frankly I haven't met this issue of discontinuity. :) But now I also think
it is possible to happen and shall deal with. 
 
Thank you very much for presenting this issue.
 
In the ITU-T Rec. H.222.0 | ISO/IEC 13818-1, it introduces that "A
continuity counter discontinuity point shall occur at most one time from the
initiation of the discontinuity state until the conclusion of the
discontinuity state. Furthermore, for all PIDs that are not designated as
PCR_PIDs, when the discontinuity_indicator is set to '1' in a packet of a
specific PID, the discontinuity_indicator may be set to '1' in the next
Transport Stream packet of that same PID, but shall not be set to '1' in
three consecutive Transport Stream packet of that same PID."
 
I think we may solve it by transmiting PSI packets with its
discontinuity_indicator being set to one. For an example of PMT, if RS finds
that there are two PMT packets which discontinuity_indicators are set to
'1'. These two PMT packets shall be transmitted as the preamble information.

I don't know if I describe it clearly.
 
Peilin

发件人: Sandy (Alexander) MacInnis [mailto:[email-masked]] 
发送时间: 2010年1月15日 1:54
收件人: Peilin Yang; 'VAN CAENEGEM Tom'
抄送: [email-masked]; 'Roni Even'
主题: RE: [AVT] About CC continuity - Re: Comments on RTP Payload Format
for"MPEG2-TSPreamble"internet draft

Peilin,
 
Can you be sure that all of the TS packets being sent in the preamble have
CC values that are continuous with those of the subsequent packets of the
same PID that arrive at the receiver after the preamble?
 
Maybe I'm missing something, but it seems to me that even if the packets
within the pre-amble have valid CC values, my question is about subsequent
packets of the same PIDs. If there is a CC discontinuity between the
preamble and the remainder of the stream, if it is all spliced together and
sent to a decoder that isn't designed to handle this operation, it would
appear that there is a risk that the decoder could determine that the stream
is defective and tae corrective action, which may not be the desired
response in this case.
 
If this is a real issue, it might be possible to deal with it by setting the
discontinuity bit, but it might not be quite that simple.
 
--Sandy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peilin
Yang
Sent: Wednesday, January 13, 2010 10:46 PM
To: 'VAN CAENEGEM Tom'
Cc: [email-masked]; 'Roni Even'
Subject: [AVT] About CC continuity - Re: Comments on RTP Payload Format
for"MPEG2-TSPreamble"internet draft

Hi Tom, 

Peilin 

-----邮件原件----- 
发件人: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] 代表 VAN CAENEGEM Tom 
发送时间: 2010年1月12日 18:55 
收件人: Ali C. Begen (abegen); Roni Even; [email-masked] 
主题: Re: [AVT] Comments on RTP Payload Format for"MPEG2-TSPreamble"internet
draft 

Ali, see below 
Tom 

-----Original Message----- 
From: Ali C. Begen (abegen) [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: maandag 11 januari 2010 18:50 
To: VAN CAENEGEM Tom; Roni Even; [email-masked] 
Subject: RE: [AVT] Comments on RTP Payload Format for
"MPEG2-TSPreamble"internet draft 

> From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of 
4588. 

Cheers, acbegen. 

> From: Roni Even [mailto:[email-masked] <mailto:[email-masked]>
] 
frame in the MPEG2-TS. 

> stream 
> 
> 
> 
> Roni Even as Individual 
> 
> 
> 
> From: VAN CAENEGEM Tom [mailto:[email-masked]
<mailto:[email-masked]> ] 

composed. 
> From: Roni Even [mailto:[email-masked] <mailto:[email-masked]>
] 
> http://tools.ietf.org/html/draft-xia-avt-mpeg2ts-preamble-01
<http://tools.ietf.org/html/draft-xia-avt-mpeg2ts-preamble-01>  which 
> From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of 

> <http://tools.ietf.org/html/draft-begen-avt
<http://tools.ietf.org/html/draft-begen-avt> - 
> <http://tools.ietf.org/html/draft-begen-avt-rtp
<http://tools.ietf.org/html/draft-begen-avt-rtp> - 

packets. 
> <http://tools.ietf.org/html/draft-ietf-avt
<http://tools.ietf.org/html/draft-ietf-avt> - 

_______________________________________________ 
Audio/Video Transport Working Group 
[email-masked] 
https://www.ietf.org/mailman/listinfo/avt
<https://www.ietf.org/mailman/listinfo/avt>

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Thu, 14 Jan 2010 09:53:35 -0800

Peilin,

Can you be sure that all of the TS packets being sent in the preamble have CC values that are continuous with those of the subsequent packets of the same PID that arrive at the receiver after the preamble?

Maybe I'm missing something, but it seems to me that even if the packets within the pre-amble have valid CC values, my question is about subsequent packets of the same PIDs. If there is a CC discontinuity between the preamble and the remainder of the stream, if it is all spliced together and sent to a decoder that isn't designed to handle this operation, it would appear that there is a risk that the decoder could determine that the stream is defective and tae corrective action, which may not be the desired response in this case.

If this is a real issue, it might be possible to deal with it by setting the discontinuity bit, but it might not be quite that simple.

--Sandy

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peilin Yang
Sent: Wednesday, January 13, 2010 10:46 PM
To: 'VAN CAENEGEM Tom'
Cc: [email-masked]; 'Roni Even'
Subject: [AVT] About CC continuity - Re: Comments on RTP Payload Format for"MPEG2-TSPreamble"internet draft

Hi Tom,

Peilin

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 VAN CAENEGEM Tom
发送时间: 2010年1月12日 18:55
收件人: Ali C. Begen (abegen); Roni Even; [email-masked]
主题: Re: [AVT] Comments on RTP Payload Format for"MPEG2-TSPreamble"internet draft

Ali, see below
Tom

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]]
Sent: maandag 11 januari 2010 18:50
To: VAN CAENEGEM Tom; Roni Even; [email-masked]
Subject: RE: [AVT] Comments on RTP Payload Format for "MPEG2-TSPreamble"internet draft

4588.

Cheers, acbegen.

frame in the MPEG2-TS.

composed.

packets.

---

From: Peilin Yang <[email-masked]>
Date: Fri, 15 Jan 2010 15:53:16 +0800

Dear Sandy,

 

 
Peilin

  _____  

Peilin,

 
 
--Sandy

  _____  

Hi Tom, 

Peilin 

-----邮件原件----- 
发件人: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]] 代表 VAN CAENEGEM Tom 
发送时间: 2010年1月12日 18:55 
收件人: Ali C. Begen (abegen); Roni Even; [email-masked] 
主题: Re: [AVT] Comments on RTP Payload Format for"MPEG2-TSPreamble"internet
draft 

Ali, see below 
Tom 

-----Original Message----- 
From: Ali C. Begen (abegen) [ <mailto:[email-masked]> mailto:abegen@cisco.
com] 

> From: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of 
4588. 

Cheers, acbegen. 

> From: Roni Even [ <mailto:[email-masked]>
mailto:[email-masked]] 
frame in the MPEG2-TS. 

> stream 
> 
> 
> 
> Roni Even as Individual 
> 
> 
> 
> From: VAN CAENEGEM Tom [ <mailto:[email-masked]>
mailto:[email-masked]] 

composed. 
> From: Roni Even [ <mailto:[email-masked]>
mailto:[email-masked]] 
>  <http://tools.ietf.org/html/draft-xia-avt-mpeg2ts-preamble-01>
> From: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of 

> < <http://tools.ietf.org/html/draft-begen-avt>
http://tools.ietf.org/html/draft-begen-avt- 
> < <http://tools.ietf.org/html/draft-begen-avt-rtp>
http://tools.ietf.org/html/draft-begen-avt-rtp- 

packets. 
> < <http://tools.ietf.org/html/draft-ietf-avt>
http://tools.ietf.org/html/draft-ietf-avt-

---

From: Roni Even <[email-masked]>
Date: Fri, 15 Jan 2010 18:19:58 +0200

Hi,

There is a limit on message size in the mailing list. I accepted the latest
messages but please cut the non relevant parts before responding on this
thread

Thanks

Roni Even

AVT co-chair

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sandy
(Alexander) MacInnis
Sent: Thursday, January 14, 2010 7:54 PM
To: Peilin Yang; 'VAN CAENEGEM Tom'
Cc: [email-masked]; 'Roni Even'
Subject: Re: [AVT] About CC continuity - Re: Comments on RTP Payload Format
for"MPEG2-TSPreamble"internet draft

Peilin,

--Sandy

  _____  

Hi Tom, 

Peilin 

-----邮件原件----- 

Ali, see below 
Tom 

-----Original Message----- 

4588. 

Cheers, acbegen.