Subject: [AVT] MPEG2 preamble - comparison of mechanisms

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 12 Mar 2010 17:44:19 +0100

(As WG co-chair)

More actions on the MPEG2 preamble:

The two drafts are:

http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-04.txt
http://tools.ietf.org/id/draft-xia-avt-mpeg2ts-preamble-02.txt

At the last meeting, there was an ad-hoc which reported that:

"The idea expressed in the Begen draft is to extract the data needed for the preamble from the media stream, cache it on the server, and send it to the receiver on request in the form of one (or occasionally a small number of) RTP packets using a new RTP payload format. That RTP payload format is organised as a set of TLV-encoded blocks, where each block represents a particular piece of preamble data, extracted from the MPEG2-TS. The use of TLV-encoded blocks provides extensibility.

The idea expressed in the Xia draft is to extract the MPEG2-TS frames needed for the preamble from the media stream, cache them on the server, and send them to the receiver on request in the form of MPEG2-TS frames encapsulated in an RTP packet representing an RFC 4588 retransmission of a synthetic RFC 2250 RTP packet encapsulating those MPEG2-TS frames (note that only the frames required for the preamble are sent, not the complete RTP packets that contain them).

After much discussion, it was understood that both proposals send essentially the same data as the preamble. The key difference between them is the way in which that data is encapsulated: the Began draft extracts the preamble data from the MPEG2-TS and wraps it into a TLV-encoded form for transmission; the Xia draft extracts the preamble data from the MPEG2-TS and sends it as a sequence of new MPEG2-TS frames wrapped in an RTP retransmission packet. 

We discussed compatibility of the two approaches with the RTP standards. The Began draft is clearly compatible. The Xia draft is not compatible as it stands, since the preamble is sent as an RTP retransmission packet but contains a synthetic packet that is not a retransmission. This issue with the Xia draft can be solved by formatting the preamble packets as RFC 2250 packets, rather than the current approach that uses an RFC 4588 retransmission of an RFC 2250 packet.

We discussed overheads, in terms of the number of packets sent, and vulnerability to packet loss. The two drafts generally send the same information in the same number of RTP packets in the preamble, and so have essentially the same overhead and resilience to loss. Acquisition delays are also the same, since both send the same information.

The Began draft includes TLV headers which may provide extra flexibility, but will slightly increase the packet size compared to the Xia draft which sends raw MPEG2-TS frames.

The meeting concluded with an understanding that the two proposals have essentially identical overheads and behaviour. The key difference between then, assuming the Xia proposal is updated to use RFC 2250 packets rather than RFC 4588 retransmissions of RFC 2250 packets to conform to the RTP specifications, is that the Begen draft includes additional TLV-headers to provide additional flexibility and extensibility, at the expense of a slightly larger packet. "

So this report essentially says the two drafts are equivalent, and it comes down to a matter of preferences (i.e. does one prefer the blue one to the red one).

ACTION TO WG MEMBERS
---------------------

Is there anything the WG members wish to add to this comparison that may influence the decision?

Please respond to the list (and ideally to this thread) in advance of the face to face meeting, as again due to limited (and valuable) meeting time; we will not have time in Anaheim for people to present these ideas afresh at the microphone.

regards

Keith

---

From: "Allison, Art" <[email-masked]>
Date: Fri, 12 Mar 2010 14:12:17 -0500

In response to is there any other difference?

Perhaps for a corner case:

If an implementation were to attempt synchronization of audio and video
by using the PCR in the MPEG-2 TS packets (as contrasted with an
implementation relying completely on the RTP/RTCP time stamps); then
perhaps the Xia method may have a tiny bit larger risk of being
misimplemented.

MPEG-2 TS implementations have been known to establish an internal clock
from the first PCR received and adjust that timing reference upon
receipt of later PCRs when the value is not quite that expected. The
time between preamble PCR and the first 'real' PCR may present a larger
than expected delta, and the adjustment process to get back in step is
undefined (as I was not able to find that signaling a discontinuity in
PCR was required.)

While MPEG-2 TS implementation variants of either method may need to
take account of differences between the pre-amble PCR and the steady
incrementing PCR once decoding gets underway; it may less apparent that
special handling of the PCR is needed when it is in what appears to be a
well understood packet (but is actually slightly different due to its
being provided 'early' for the special purpose here). 

This need is somewhat more obvious with a special construct.

Art Allison

Senior Director Advanced Engineering, Science and Technology

National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418 
Fax  202 775 4981

www.nab.org

Advocacy  Education  Innovation

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of DRAGE, Keith (Keith)
|Sent: Friday, March 12, 2010 11:44 AM
|To: [email-masked]
|Subject: [AVT] MPEG2 preamble - comparison of mechanisms
|
|(As WG co-chair)
|
|More actions on the MPEG2 preamble:
|
|The two drafts are:
|
|http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-04.txt
|http://tools.ietf.org/id/draft-xia-avt-mpeg2ts-preamble-02.txt
|
|At the last meeting, there was an ad-hoc which reported that:
|
|
|"The idea expressed in the Begen draft is to extract the data 
|needed for the preamble from the media stream, cache it on the 
|server, and send it to the receiver on request in the form of 
|one (or occasionally a small number of) RTP packets using a 
|new RTP payload format. That RTP payload format is organised 
|as a set of TLV-encoded blocks, where each block represents a 
|particular piece of preamble data, extracted from the 
|MPEG2-TS. The use of TLV-encoded blocks provides extensibility.
|
|The idea expressed in the Xia draft is to extract the MPEG2-TS 
|frames needed for the preamble from the media stream, cache 
|them on the server, and send them to the receiver on request 
|in the form of MPEG2-TS frames encapsulated in an RTP packet 
|representing an RFC 4588 retransmission of a synthetic RFC 
|2250 RTP packet encapsulating those MPEG2-TS frames (note that 
|only the frames required for the preamble are sent, not the 
|complete RTP packets that contain them).
|
|After much discussion, it was understood that both proposals 
|send essentially the same data as the preamble. The key 
|difference between them is the way in which that data is 
|encapsulated: the Began draft extracts the preamble data from 
|the MPEG2-TS and wraps it into a TLV-encoded form for 
|transmission; the Xia draft extracts the preamble data from 
|the MPEG2-TS and sends it as a sequence of new MPEG2-TS frames 
|wrapped in an RTP retransmission packet. 
|
|We discussed compatibility of the two approaches with the RTP 
|standards. The Began draft is clearly compatible. The Xia 
|draft is not compatible as it stands, since the preamble is 
|sent as an RTP retransmission packet but contains a synthetic 
|packet that is not a retransmission. This issue with the Xia 
|draft can be solved by formatting the preamble packets as RFC 
|2250 packets, rather than the current approach that uses an 
|RFC 4588 retransmission of an RFC 2250 packet.
|
|We discussed overheads, in terms of the number of packets 
|sent, and vulnerability to packet loss. The two drafts 
|generally send the same information in the same number of RTP 
|packets in the preamble, and so have essentially the same 
|overhead and resilience to loss. Acquisition delays are also 
|the same, since both send the same information.
|
|The Began draft includes TLV headers which may provide extra 
|flexibility, but will slightly increase the packet size 
|compared to the Xia draft which sends raw MPEG2-TS frames.
|
|The meeting concluded with an understanding that the two 
|proposals have essentially identical overheads and behaviour. 
|The key difference between then, assuming the Xia proposal is 
|updated to use RFC 2250 packets rather than RFC 4588 
|retransmissions of RFC 2250 packets to conform to the RTP 
|specifications, is that the Begen draft includes additional 
|TLV-headers to provide additional flexibility and 
|extensibility, at the expense of a slightly larger packet. "
|
|
|So this report essentially says the two drafts are equivalent, 
|and it comes down to a matter of preferences (i.e. does one 
|prefer the blue one to the red one).
|
|ACTION TO WG MEMBERS
|---------------------
|
|Is there anything the WG members wish to add to this 
|comparison that may influence the decision?
|
|Please respond to the list (and ideally to this thread) in 
|advance of the face to face meeting, as again due to limited 
|(and valuable) meeting time; we will not have time in Anaheim 
|for people to present these ideas afresh at the microphone.
|
|regards
|
|Keith
|
| 
|_______________________________________________
|Audio/Video Transport Working Group
[email-masked]
|https://www.ietf.org/mailman/listinfo/avt
|

---

From: Roni Even <[email-masked]>
Date: Fri, 12 Mar 2010 21:52:43 +0200

Hi Art,
I think that in both cases the problem is the same. What you are saying is
the it is identified easier in begen draft since it is a special construct,
this is true also in the xia draft since it is obvious from the announcement
that the rfc 2250 stream is a preamble stream. In both cases it is a
specific reciver implementation enhancement if required
BTW: I am not sure what is the use case when you have  two separate MPEG2-TS
streams using different RTP sessions carrying the audio and video
separately. I would assume that a program will carry both multiplexed. Also
I assume that if audio and video are separated you will need the RTP time
stamp to synchronize between them.

Roni Even
As individual

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Allison, Art
> Sent: Friday, March 12, 2010 9:12 PM
> To: [email-masked]
> Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Allison, Art" <[email-masked]>
Date: Fri, 12 Mar 2010 16:05:37 -0500

I agree a careful, perfect reader should not have a problem. 
Implementation complexity and variability seems to me to be a valid
criteria for comparison - especially when alternatives are so close.   I
saw only a tiny corner. 

Consider the exposure to the PCR processor (which according to good
layering should not have to know a packet came from a different
structure). This processor subroutine gets handed the values from that
field after the packets are no longer in their special wrapper.

I read that that it might not be clear that the parser subroutine might
need to be adjusted somewhat, as this field is not incrementing
'normally' in this case.
Setting the PCR discontinuity may be worth considering to explicitly
signal this state - and that triggers a already defined behavior.  The
receiver implementation could use the fact that it arrived in the
preamble and set that so that no change was needed in the PCR
subroutine. Or maybe just flywheel through and accept a glitch while
catching up as a small cost to enable getting started sooner.

Perhaps someone else will find a more substantive difference  -- but a
humm loudness meter might be needed. 

Art Allison

www.nab.org

|-----Original Message-----
|From: Roni Even [mailto:[email-masked]] 
|Sent: Friday, March 12, 2010 2:53 PM
|To: Allison, Art; [email-masked]
|Subject: RE: [AVT] MPEG2 preamble - comparison of mechanisms
|
|Hi Art,
|I think that in both cases the problem is the same. What you 
|are saying is the it is identified easier in begen draft since 
|it is a special construct, this is true also in the xia draft 
|since it is obvious from the announcement that the rfc 2250 
|stream is a preamble stream. In both cases it is a specific 
|reciver implementation enhancement if required
|BTW: I am not sure what is the use case when you have  two 
|separate MPEG2-TS streams using different RTP sessions 
|carrying the audio and video separately. I would assume that a 
|program will carry both multiplexed. Also I assume that if 
|audio and video are separated you will need the RTP time stamp 
|to synchronize between them.
|
|Roni Even
|As individual
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of 
|> Allison, Art
|> Sent: Friday, March 12, 2010 9:12 PM
|> To: [email-masked]
|> Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms
|> 
|> In response to is there any other difference?
|> 
|> Perhaps for a corner case:
|> 
|> If an implementation were to attempt synchronization of audio and 
|> video by using the PCR in the MPEG-2 TS packets (as 
|contrasted with an 
|> implementation relying completely on the RTP/RTCP time stamps); then 
|> perhaps the Xia method may have a tiny bit larger risk of being 
|> misimplemented.
|> 
|> MPEG-2 TS implementations have been known to establish an internal 
|> clock from the first PCR received and adjust that timing reference 
|> upon receipt of later PCRs when the value is not quite that 
|expected. 
|> The time between preamble PCR and the first 'real' PCR may present a 
|> larger than expected delta, and the adjustment process to 
|get back in 
|> step is undefined (as I was not able to find that signaling a 
|> discontinuity in PCR was required.)
|> 
|> While MPEG-2 TS implementation variants of either method may need to 
|> take account of differences between the pre-amble PCR and the steady 
|> incrementing PCR once decoding gets underway; it may less apparent 
|> that special handling of the PCR is needed when it is in 
|what appears 
|> to be a well understood packet (but is actually slightly 
|different due 
|> to its being provided 'early' for the special purpose here).
|> 
|> This need is somewhat more obvious with a special construct.
|> 
|> 
|> Art Allison
|> 
|> Senior Director Advanced Engineering, Science and Technology
|> 
|> 
|> 
|> National Association of Broadcasters
|> 1771 N Street NW
|> Washington, DC 20036
|> Phone  202 429 5418
|> Fax  202 775 4981
|> 
|> www.nab.org
|> 
|> Advocacy  Education  Innovation
|> 
|> 
|> 
|> |-----Original Message-----
|> |From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of 
|> |DRAGE, Keith (Keith)
|> |Sent: Friday, March 12, 2010 11:44 AM
|> |To: [email-masked]
|> |Subject: [AVT] MPEG2 preamble - comparison of mechanisms
|> |
|> |(As WG co-chair)
|> |
|> |More actions on the MPEG2 preamble:
|> |
|> |The two drafts are:
|> |
|> |http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-04.txt
|> |http://tools.ietf.org/id/draft-xia-avt-mpeg2ts-preamble-02.txt
|> |
|> |At the last meeting, there was an ad-hoc which reported that:
|> |
|> |
|> |"The idea expressed in the Begen draft is to extract the 
|data needed 
|> |for the preamble from the media stream, cache it on the server, and 
|> |send it to the receiver on request in the form of one (or 
|> |occasionally a small number of) RTP packets using a new RTP payload 
|> |format. That RTP payload format is organised as a set of 
|TLV-encoded 
|> |blocks, where each block represents a particular piece of preamble 
|> |data, extracted from the MPEG2-TS. The use of TLV-encoded blocks 
|> |provides extensibility.
|> |
|> |The idea expressed in the Xia draft is to extract the 
|MPEG2-TS frames 
|> |needed for the preamble from the media stream, cache them on the 
|> |server, and send them to the receiver on request in the form of 
|> |MPEG2-TS frames encapsulated in an RTP packet representing an RFC 
|> |4588 retransmission of a synthetic RFC 2250 RTP packet 
|encapsulating 
|> |those MPEG2-TS frames (note that only the frames required for the 
|> |preamble are sent, not the complete RTP packets that contain them).
|> |
|> |After much discussion, it was understood that both proposals send 
|> |essentially the same data as the preamble. The key 
|difference between 
|> |them is the way in which that data is
|> |encapsulated: the Began draft extracts the preamble data from the 
|> |MPEG2-TS and wraps it into a TLV-encoded form for transmission; the 
|> |Xia draft extracts the preamble data from the MPEG2-TS and sends it 
|> |as a sequence of new MPEG2-TS frames wrapped in an RTP 
|retransmission 
|> |packet.
|> |
|> |We discussed compatibility of the two approaches with the RTP 
|> |standards. The Began draft is clearly compatible. The Xia draft is 
|> |not compatible as it stands, since the preamble is sent as an RTP 
|> |retransmission packet but contains a synthetic packet that is not a 
|> |retransmission. This issue with the Xia draft can be solved by 
|> |formatting the preamble packets as RFC 2250 packets, rather 
|than the 
|> |current approach that uses an RFC 4588 retransmission of an 
|RFC 2250 
|> |packet.
|> |
|> |We discussed overheads, in terms of the number of packets sent, and 
|> |vulnerability to packet loss. The two drafts generally send 
|the same 
|> |information in the same number of RTP packets in the 
|preamble, and so 
|> |have essentially the same overhead and resilience to loss. 
|> |Acquisition delays are also the same, since both send the same 
|> |information.
|> |
|> |The Began draft includes TLV headers which may provide extra 
|> |flexibility, but will slightly increase the packet size compared to 
|> |the Xia draft which sends raw MPEG2-TS frames.
|> |
|> |The meeting concluded with an understanding that the two proposals 
|> |have essentially identical overheads and behaviour.
|> |The key difference between then, assuming the Xia proposal 
|is updated 
|> |to use RFC 2250 packets rather than RFC 4588 retransmissions of RFC 
|> |2250 packets to conform to the RTP specifications, is that 
|the Begen 
|> |draft includes additional TLV-headers to provide additional 
|> |flexibility and extensibility, at the expense of a slightly larger 
|> |packet. "
|> |
|> |
|> |So this report essentially says the two drafts are 
|equivalent, and it 
|> |comes down to a matter of preferences (i.e. does one prefer 
|the blue 
|> |one to the red one).
|> |
|> |ACTION TO WG MEMBERS
|> |---------------------
|> |
|> |Is there anything the WG members wish to add to this 
|comparison that 
|> |may influence the decision?
|> |
|> |Please respond to the list (and ideally to this thread) in 
|advance of 
|> |the face to face meeting, as again due to limited (and valuable) 
|> |meeting time; we will not have time in Anaheim for people 
|to present 
|> |these ideas afresh at the microphone.
|> |
|> |regards
|> |
|> |Keith
|> |
|> |
|> |_______________________________________________
|> |Audio/Video Transport Working Group
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/avt
|> |
|> _______________________________________________
|> Audio/Video Transport Working Group
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/avt
|
|

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Fri, 12 Mar 2010 14:50:02 -0800

Art has a very good point.

Also, consider the continuity counter, which might not be continuous when TS packets that used to be widely separated are placed contiguously in the stream sent to the TS parser in the receiver.

Explicitly signaling a discontinuity between the preamble and the start of the normal TS packets might be worth considering.

--Sandy MacInnis
Broadcom Corporation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Allison, Art
Sent: Friday, March 12, 2010 1:06 PM
To: [email-masked]
Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms

Art Allison

www.nab.org

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 14 Mar 2010 08:29:14 -0700

I have a few comments for draft-xia-avt-mpeg2ts-preamble-02 draft.

1- Minor comment on figure 10: The burst should not start before the
RAMS-I is sent since the RAMS-I messages describes the burst (See the
RAMS draft).

2- Section 6: The receiver side operations are pretty generic in the
sense that they do not allow to tailor the preamble data based on the
specific requirements of the individual demux/decoders. Yes, these
devices are supposed to be standard compliant (and mostly they are) but
as one would expect, these devices tend to behave differently when it
comes to tricks like RAMS. Unless their needs are specifically
addressed, sending preamble may not provide much additional benefit.
This is one of the main reasons we chose TLV encoding over sending raw
2250 packets.
 
Is this something you intend not to consider in your implementation or
is it something you think the server should do? E.g., the server could
tailor the preamble data based on some hint information in the RAMS-R
message, although this negatively impacts server-side scalability due to
increased processing. An alternative that would keep the server side
more scalable, would be to put an MPEG2-TS parser logic in the RTP plane
on the receiver side. That parser logic can parse the raw data and then
"post-process" it based on the specific needs of the demux/decoder. But,
as you can imagine running a parser logic is quite inefficient.

3- In our approach, the preamble data for the unencrypted streams and
most of the encrypted streams fits easily into a single RTP packet. This
is because most of the preamble data is efficiently encoded with TLV
encoding. E.g., 12-byte PAT data only requires 12 bytes + TLV headers as
opposed to a full 188-byte TS packet as in your approach.

So, if that single RTP packet makes it to the client side, we are done.
For some of the encrypted streams, the CAS data may require 1-2
additional RTP packets. This will of course increase our vulnerability
to packet loss. But, there is not much we can do about it.

I'd like to understand how many RTP packet(s) your approach typically
needs to send. If your preamble data is > 7 TS packets, you will need at
least 2 RTP packets. Can you share some numbers with us for unencrypted
and encrypted streams?

The additional overhead of the preamble data is not the big concern
here. The main issue is the vulnerability to packet loss. Thus,
quantifying the number of packets needed to be sent is important.

Thanks,
-acbegen

> DRAGE, Keith (Keith)
> Sent: Friday, March 12, 2010 11:44 AM
> To: [email-masked]
> Subject: [AVT] MPEG2 preamble - comparison of mechanisms
> 
> (As WG co-chair)
> 
> "The idea expressed in the Begen draft is to extract the data needed
> for the preamble from the media stream, cache it on the server, and
> send it to the receiver on request in the form of one (or occasionally
> a small number of) RTP packets using a new RTP payload format. That
RTP
> payload format is organised as a set of TLV-encoded blocks, where each
> block represents a particular piece of preamble data, extracted from
> the MPEG2-TS. The use of TLV-encoded blocks provides extensibility.
> 
> The idea expressed in the Xia draft is to extract the MPEG2-TS frames
> needed for the preamble from the media stream, cache them on the
> server, and send them to the receiver on request in the form of MPEG2-
> TS frames encapsulated in an RTP packet representing an RFC 4588
> retransmission of a synthetic RFC 2250 RTP packet encapsulating those
> MPEG2-TS frames (note that only the frames required for the preamble
> are sent, not the complete RTP packets that contain them).
> 
> After much discussion, it was understood that both proposals send
> essentially the same data as the preamble. The key difference between
> them is the way in which that data is encapsulated: the Began draft
> extracts the preamble data from the MPEG2-TS and wraps it into a TLV-
> encoded form for transmission; the Xia draft extracts the preamble
data
> from the MPEG2-TS and sends it as a sequence of new MPEG2-TS frames
> wrapped in an RTP retransmission packet.
> 
> We discussed compatibility of the two approaches with the RTP
> standards. The Began draft is clearly compatible. The Xia draft is not
> compatible as it stands, since the preamble is sent as an RTP
> retransmission packet but contains a synthetic packet that is not a
> retransmission. This issue with the Xia draft can be solved by
> formatting the preamble packets as RFC 2250 packets, rather than the
> current approach that uses an RFC 4588 retransmission of an RFC 2250
> packet.
> 
> We discussed overheads, in terms of the number of packets sent, and
> vulnerability to packet loss. The two drafts generally send the same
> information in the same number of RTP packets in the preamble, and so
> have essentially the same overhead and resilience to loss. Acquisition
> delays are also the same, since both send the same information.
> 
> The Began draft includes TLV headers which may provide extra
> flexibility, but will slightly increase the packet size compared to
the
> Xia draft which sends raw MPEG2-TS frames.
> 
> The meeting concluded with an understanding that the two proposals
have
> essentially identical overheads and behaviour. The key difference
> between then, assuming the Xia proposal is updated to use RFC 2250
> packets rather than RFC 4588 retransmissions of RFC 2250 packets to
> conform to the RTP specifications, is that the Begen draft includes
> additional TLV-headers to provide additional flexibility and
> extensibility, at the expense of a slightly larger packet. "
> 
> 
> So this report essentially says the two drafts are equivalent, and it
> comes down to a matter of preferences (i.e. does one prefer the blue
> one to the red one).
> 
> ACTION TO WG MEMBERS
> ---------------------
> 
> Please respond to the list (and ideally to this thread) in advance of
> the face to face meeting, as again due to limited (and valuable)
> meeting time; we will not have time in Anaheim for people to present
> these ideas afresh at the microphone.
> 
> regards
> 
> Keith
> 
>

---

From: Roni Even <[email-masked]>
Date: Sun, 14 Mar 2010 18:05:12 +0200

Ali,
Inline
Roni Even 
as individual

> Ali C. Begen (abegen)
> Sent: Sunday, March 14, 2010 5:29 PM
> To: DRAGE, Keith (Keith); [email-masked]

I believe Stephan already commented on this is previous email
" my personal feeling is that IETF standardization should not be overly
bothered by possibly non-compliant implementations of MPEG-2 system layers
in certain chipset products."
And this feeling was also mentioned in the breakout session in Hiroshima.

Addressing issues on the client side when it is not compliant to the
reference MPEG2-TS receiver (using some third party or hardware decoder) is
orthogonal to the discussion and can be addressed in both solutions and even
if there is no RAMS or preamble based on the received MPEAG2-TS stream

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 14 Mar 2010 09:14:08 -0700

> in certain chipset products."

The 'non-compliant' term is too strong to use here. I was not referring
to non-compliant devices in my email. There are several points where the
standard is not definitive enough and details are left for
implementation. Since we RAMS is an optimization and the use of preamble
is also an optimization, such implementation details become important.
We cannot ignore them.

> And this feeling was also mentioned in the breakout session in

It was mentioned but I never said I agreed with that feeling.
 
> orthogonal to the discussion and can be addressed in both solutions
and
> even

We address it in our draft. And my question for the authors of the other
draft is whether they are planning to address it or not. If yes, how?

-acbegen

---

From: Roni Even <[email-masked]>
Date: Mon, 15 Mar 2010 09:06:29 +0200

Ali,
I assume you are referring to the last paragraph in section 7 of your draft.
" The TS packets constructed as above MUST be passed to the demux/
   decoder in the following order:  PAT, PMT, PCR, EMM, ECM, {Elementary
   Stream Data}.  The PAT and PMT MUST be the first two packets because
   they contain required information to program the demux.  The EMM and
   ECM MUST occur before Elementary stream data because they contain
   conditional access data that will be needed to descramble and decode
   the elementary stream."

I am not sure that this is mandated in MPEG2-TS specification yet I think
that in your draft you suggest to take the TOLVs that can be sent in a
random order in the packet and build a MPEG2-TS like this.

I think that the xia draft as shown in the examples takes the information as
it appears in the incoming MPEG2-TS stream and send it in the same order. 

If the original MPEG2TS stream is not built in a way that will enable the
demultples/decider to use it than it is not related to this work and is
mentioned in the MPEG2-TS specification see bellow:

" System reference decoder
Part 1 of ISO/IEC 13818 employs a "System Target Decoder" (STD), one for
Transport Streams (refer to 2.4.2) referred to as "Transport System Target
Decoder" (T-STD) and one for Program Streams (refer to 2.5.2) referred to as
"Program System Target Decoder" (P-STD), to provide a formalism for timing
and buffering relationships. Because the STD is parameterized in terms of
ITU-T Rec. H.222.0 | ISO/IEC 13818-1 fields (for example, buffer sizes) each
elementary stream leads to its own parameterization of the STD. Encoders
shall produce bit streams that meet the appropriate STD's constraints.
Physical decoders may assume that a stream plays properly on its STD. The
physical decoder must compensate for ways in which its design differs from
that of the STD."

Roni Even

> Sent: Sunday, March 14, 2010 6:14 PM
> To: Roni Even; DRAGE, Keith (Keith); [email-masked]

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Mon, 15 Mar 2010 09:37:50 -0500

Sandy, Art

Thanks for your thoughts on MPEG timestamp processing in the RAMS
preamble. These are subtle points, but important when we consider the
protocol options. 

We found quite a few of these subtle points during the implementation of
the RAMS protocol, and I encourage interested parties to look at the
client reference code (which is available at
ftp://ftpeng.cisco.com/ftp/vqec/  ). This version of code is an
implementation of the first draft of RAMS and the -00 Begen MPEG2TS
pre-amble draft. If there are reference implementations of the
alternative proposals, we would like to see them.

We did considered these MPEG2TS clock issues during the design of the
prototype RAMS and pre-amble implementation, and were able to refine
them when we tested the code on various client devices. In most cases,
it makes sense to build a stream with an approximation of the correct
PCR. In other cases (like when a decent PCR value can't be calculated
using the available resources/information), signaling a PCR
discontinuity in the input to the decrypt/decode chain would be the
correct behavior. Both of these approaches allow the demux and decoder
to get the right stream sequence faster, as it does not have to allocate
resources to try to analyze/fix a clock discontinuity. As part of the
prototype testing, we realized that some of this behavior is
(unfortunately) decryptor/decoder specific. As you both well know, most
large deployments of digital TV use dedicated System On Chip (SOC)
silicon to handle the MPEG2TS and codec processing. They also tend to
use custom silicon for decrypting the streams. A well-design SOC will
handle PCR discontinuities. Certain (poorly designed) chipsets will have
severe artifacts when presented with an indication of PCR discontinuity.
For those chipsets, it is better to send the data into the
decrypt/demux/decode chain without setting the discontinuity bit. There
is a very diverse set of deployed chipsets, and there is substantial
variation. The chipsets are nominally compliant to the MPEG2TS
specification, but the quality of the displayed video has wide variance.

There are other quirks in the MPEG2 world, which we probably do not want
to drive into the RTP world. We found that it was better to send the
explicit pre-amble burst to the client, followed by the accelerated
flow. If there were odd (device specific) things that had to happen to
the flow, the client code had all of the information it needed. We
briefly considered pushing this functionality to the server by designing
a pre-amble "capabilities exchange protocol", but this was clearly not
the right approach.

If we try to drive this functionality to the server, we end up with
complex interactions between the RTP layer and the MPEG2TS layer.

Once again, I encourage the group to examine
ftp://ftpeng.cisco.com/ftp/vqec/ to see the merits of our approach.

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sandy (Alexander) MacInnis
Sent: Friday, March 12, 2010 5:50 PM
To: Allison, Art; [email-masked]
Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms

Also, consider the continuity counter, which might not be continuous
when TS packets that used to be widely separated are placed contiguously
in the stream sent to the TS parser in the receiver.

Explicitly signaling a discontinuity between the preamble and the start
of the normal TS packets might be worth considering.

--Sandy MacInnis
Broadcom Corporation

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

Art Allison

www.nab.org

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Mon, 15 Mar 2010 09:58:37 -0500

The relative order of the PAT/PMT is dependent on when you join the
stream. The MPEG spec does not specify an order to these flows, only a
range for the relative frequency of their occurrence. Best practices
dictates a certain order, and a certain spacing between the elements.
These best practices are designed by the network operators to give the
best overall performance across the device population in their network. 

How to we map this to an accelerated acquisition scenario?

First, some (probably too detailed) video processing background ----- In
many/most of the target devices, a highly optimized chipset is used. To
get reasonable channel change performance, it has to be driven in a very
precise order. When a given client acquires the flow, it has to go
through a very detail sequence of events to setup each element in a
chain of sequential processing. The exact order is chipset dependent,
but the client device generally has to setup a demux to read the PAT,
then setup the demux to read the PMT, then setup a decryptor based on
the contents of the PMT, then feed the EMM into the decryptor, then feed
the ECM into the decryptor, then setup the audio demux based on the PMT,
then setup the video demux based on the PMT, then feed the stream
through the chain of devices. There are device-specific timing
constraints. The exact sequence of events depends on chipset being used.
If the data is sent in the wrong order, or without enough spacing to
allow the devices to setup, the subsequent steps can't handle the
presented data and the device has to wait for the data to appear in the
stream again. 

Then the summary ----- The device specific ordering/timing is a very
important consideration when we try to accelerate stream processing. I
know MPEG2TS very well, and this is not subject to debate in the
community. We clearly do not want to drive this complexity into the RTP
layer.

Then the  conclusion ---- We do not want to expose the details of each
implementation to the protocol. We want to hand the data to the client
in a way that allows the client to "do the right thing". The "right
thing" is very much client specific, and includes nasty device specific
timing and device specific ordering. If we try to solve these issues on
the server, we are in for some very difficult times.

Once again, I encourage folks to look at the reference implementation,
as it demonstrates the elegance of the proposed solution. 

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Monday, March 15, 2010 3:06 AM
To: Ali C. Begen (abegen); 'DRAGE, Keith (Keith)'; [email-masked]
Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms

Ali,
I assume you are referring to the last paragraph in section 7 of your
draft.

I am not sure that this is mandated in MPEG2-TS specification yet I
think
that in your draft you suggest to take the TOLVs that can be sent in a
random order in the packet and build a MPEG2-TS like this.

I think that the xia draft as shown in the examples takes the
information as
it appears in the incoming MPEG2-TS stream and send it in the same
order. 

If the original MPEG2TS stream is not built in a way that will enable
the
demultples/decider to use it than it is not related to this work and is
mentioned in the MPEG2-TS specification see bellow:

" System reference decoder
Part 1 of ISO/IEC 13818 employs a "System Target Decoder" (STD), one for
Transport Streams (refer to 2.4.2) referred to as "Transport System
Target
Decoder" (T-STD) and one for Program Streams (refer to 2.5.2) referred
to as
"Program System Target Decoder" (P-STD), to provide a formalism for
timing
and buffering relationships. Because the STD is parameterized in terms
of
ITU-T Rec. H.222.0 | ISO/IEC 13818-1 fields (for example, buffer sizes)
each
elementary stream leads to its own parameterization of the STD. Encoders
shall produce bit streams that meet the appropriate STD's constraints.
Physical decoders may assume that a stream plays properly on its STD.
The
physical decoder must compensate for ways in which its design differs
from
that of the STD."

Roni Even

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 15 Mar 2010 08:14:08 -0700

To reflect our intention better, the MUST in the following sentence
should be changed to a "should". This will be addressed in the next
revision.

   The TS packets constructed as above MUST be passed to the demux/
   decoder in the following order:  PAT, PMT, PCR, EMM, ECM, {Elementary
   Stream Data}.

Thanks for catching this, Roni.

-acbegen

> From: Roni Even [mailto:[email-masked]]
> Subject: RE: [AVT] MPEG2 preamble - comparison of mechanisms
> 
> Ali,
> > > bothered by possibly non-compliant implementations of MPEG-2
system
> > > layers

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Mon, 15 Mar 2010 10:30:10 -0500

Yes, this section should not be normative. Good catch.

It is more a recommendation about best practices internal to the end
device. If it is confusing or controversial, it could even be removed. I
think it adds value as a recommendation, though.

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)
Sent: Monday, March 15, 2010 11:14 AM
To: Roni Even; DRAGE, Keith (Keith); [email-masked]
Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms

-acbegen

system

---

From: "Allison, Art" <[email-masked]>
Date: Mon, 15 Mar 2010 11:55:48 -0400

As I will not be present for the weighing of alternatives; and FWIW
I support selection of
http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-04.txt .

Art Allison, handing Bill a 3dB audio amplifier.

www.nab.org

|-----Original Message-----
|From: Bill Ver Steeg (versteb) [mailto:[email-masked]] 
|Sent: Monday, March 15, 2010 10:38 AM
|To: Sandy (Alexander) MacInnis; Allison, Art; [email-masked]
|Subject: RE: [AVT] MPEG2 preamble - comparison of mechanisms
|
|Sandy, Art
|
|Thanks for your thoughts on MPEG timestamp processing in the 
|RAMS preamble. These are subtle points, but important when we 
|consider the protocol options. 
|
|We found quite a few of these subtle points during the 
|implementation of the RAMS protocol, and I encourage 
|interested parties to look at the client reference code (which 
|is available at ftp://ftpeng.cisco.com/ftp/vqec/  ). This 
|version of code is an implementation of the first draft of 
|RAMS and the -00 Begen MPEG2TS pre-amble draft. If there are 
|reference implementations of the alternative proposals, we 
|would like to see them.
|
|We did considered these MPEG2TS clock issues during the design 
|of the prototype RAMS and pre-amble implementation, and were 
|able to refine them when we tested the code on various client 
|devices. In most cases, it makes sense to build a stream with 
|an approximation of the correct PCR. In other cases (like when 
|a decent PCR value can't be calculated using the available 
|resources/information), signaling a PCR discontinuity in the 
|input to the decrypt/decode chain would be the correct 
|behavior. Both of these approaches allow the demux and decoder 
|to get the right stream sequence faster, as it does not have 
|to allocate resources to try to analyze/fix a clock 
|discontinuity. As part of the prototype testing, we realized 
|that some of this behavior is
|(unfortunately) decryptor/decoder specific. As you both well 
|know, most large deployments of digital TV use dedicated 
|System On Chip (SOC) silicon to handle the MPEG2TS and codec 
|processing. They also tend to use custom silicon for 
|decrypting the streams. A well-design SOC will handle PCR 
|discontinuities. Certain (poorly designed) chipsets will have 
|severe artifacts when presented with an indication of PCR 
|discontinuity.
|For those chipsets, it is better to send the data into the 
|decrypt/demux/decode chain without setting the discontinuity 
|bit. There is a very diverse set of deployed chipsets, and 
|there is substantial variation. The chipsets are nominally 
|compliant to the MPEG2TS specification, but the quality of the 
|displayed video has wide variance.
|
|There are other quirks in the MPEG2 world, which we probably 
|do not want to drive into the RTP world. We found that it was 
|better to send the explicit pre-amble burst to the client, 
|followed by the accelerated flow. If there were odd (device 
|specific) things that had to happen to the flow, the client 
|code had all of the information it needed. We briefly 
|considered pushing this functionality to the server by 
|designing a pre-amble "capabilities exchange protocol", but 
|this was clearly not the right approach.
|
|If we try to drive this functionality to the server, we end up 
|with complex interactions between the RTP layer and the MPEG2TS layer.
|
|Once again, I encourage the group to examine 
|ftp://ftpeng.cisco.com/ftp/vqec/ to see the merits of our approach.
|
|
|Bill VerSteeg
|
|
|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Sandy (Alexander) MacInnis
|Sent: Friday, March 12, 2010 5:50 PM
|To: Allison, Art; [email-masked]
|Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms
|
|Art has a very good point.
|
|Also, consider the continuity counter, which might not be 
|continuous when TS packets that used to be widely separated 
|are placed contiguously in the stream sent to the TS parser in 
|the receiver.
|
|Explicitly signaling a discontinuity between the preamble and 
|the start of the normal TS packets might be worth considering.
|
|--Sandy MacInnis
|Broadcom Corporation
|
|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Allison, Art
|Sent: Friday, March 12, 2010 1:06 PM
|To: [email-masked]
|Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms
|
|I agree a careful, perfect reader should not have a problem. 
|Implementation complexity and variability seems to me to be a valid
|criteria for comparison - especially when alternatives are so 
|close.   I
|saw only a tiny corner. 
|
|Consider the exposure to the PCR processor (which according to 
|good layering should not have to know a packet came from a 
|different structure). This processor subroutine gets handed 
|the values from that field after the packets are no longer in 
|their special wrapper.
|
|I read that that it might not be clear that the parser 
|subroutine might need to be adjusted somewhat, as this field 
|is not incrementing 'normally' in this case.
|Setting the PCR discontinuity may be worth considering to 
|explicitly signal this state - and that triggers a already 
|defined behavior.  The receiver implementation could use the 
|fact that it arrived in the preamble and set that so that no 
|change was needed in the PCR subroutine. Or maybe just 
|flywheel through and accept a glitch while catching up as a 
|small cost to enable getting started sooner.
|
|Perhaps someone else will find a more substantive difference  
|-- but a humm loudness meter might be needed. 
|
|Art Allison
|
|Senior Director Advanced Engineering, Science and Technology
|
| 
|
|National Association of Broadcasters
|1771 N Street NW
|Washington, DC 20036
|Phone  202 429 5418
|Fax  202 775 4981
|
|www.nab.org
|
|Advocacy  Education  Innovation
|
| 
|
||-----Original Message-----
||From: Roni Even [mailto:[email-masked]]
||Sent: Friday, March 12, 2010 2:53 PM
||To: Allison, Art; [email-masked]
||Subject: RE: [AVT] MPEG2 preamble - comparison of mechanisms
||
||Hi Art,
||I think that in both cases the problem is the same. What you 
|are saying 
||is the it is identified easier in begen draft since it is a special 
||construct, this is true also in the xia draft since it is 
|obvious from 
||the announcement that the rfc 2250 stream is a preamble 
|stream. In both 
||cases it is a specific reciver implementation enhancement if required
||BTW: I am not sure what is the use case when you have  two separate 
||MPEG2-TS streams using different RTP sessions carrying the audio and 
||video separately. I would assume that a program will carry both 
||multiplexed. Also I assume that if audio and video are separated you 
||will need the RTP time stamp to synchronize between them.
||
||Roni Even
||As individual
||
||> -----Original Message-----
||> From: [email-masked] [mailto:[email-masked]] On
||Behalf Of
||> Allison, Art
||> Sent: Friday, March 12, 2010 9:12 PM
||> To: [email-masked]
||> Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms
||> 
||> In response to is there any other difference?
||> 
||> Perhaps for a corner case:
||> 
||> If an implementation were to attempt synchronization of audio and 
||> video by using the PCR in the MPEG-2 TS packets (as
||contrasted with an
||> implementation relying completely on the RTP/RTCP time 
|stamps); then 
||> perhaps the Xia method may have a tiny bit larger risk of being 
||> misimplemented.
||> 
||> MPEG-2 TS implementations have been known to establish an internal 
||> clock from the first PCR received and adjust that timing reference 
||> upon receipt of later PCRs when the value is not quite that
||expected. 
||> The time between preamble PCR and the first 'real' PCR may 
|present a 
||> larger than expected delta, and the adjustment process to
||get back in
||> step is undefined (as I was not able to find that signaling a 
||> discontinuity in PCR was required.)
||> 
||> While MPEG-2 TS implementation variants of either method 
|may need to 
||> take account of differences between the pre-amble PCR and 
|the steady 
||> incrementing PCR once decoding gets underway; it may less apparent 
||> that special handling of the PCR is needed when it is in
||what appears
||> to be a well understood packet (but is actually slightly
||different due
||> to its being provided 'early' for the special purpose here).
||> 
||> This need is somewhat more obvious with a special construct.
||> 
||> 
||> Art Allison
||> 
||> Senior Director Advanced Engineering, Science and Technology
||> 
||> 
||> 
||> National Association of Broadcasters
||> 1771 N Street NW
||> Washington, DC 20036
||> Phone  202 429 5418
||> Fax  202 775 4981
||> 
||> www.nab.org
||> 
||> Advocacy  Education  Innovation
||> 
||> 
||> 
||> |-----Original Message-----
||> |From: [email-masked] [mailto:[email-masked]] On
||Behalf Of
||> |DRAGE, Keith (Keith)
||> |Sent: Friday, March 12, 2010 11:44 AM
||> |To: [email-masked]
||> |Subject: [AVT] MPEG2 preamble - comparison of mechanisms
||> |
||> |(As WG co-chair)
||> |
||> |More actions on the MPEG2 preamble:
||> |
||> |The two drafts are:
||> |
||> 
||http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-04.txt
||> |http://tools.ietf.org/id/draft-xia-avt-mpeg2ts-preamble-02.txt
||> |
||> |At the last meeting, there was an ad-hoc which reported that:
||> |
||> |
||> |"The idea expressed in the Begen draft is to extract the
||data needed
||> |for the preamble from the media stream, cache it on the 
|server, and 
||> |send it to the receiver on request in the form of one (or 
||> |occasionally a small number of) RTP packets using a new 
|RTP payload 
||> |format. That RTP payload format is organised as a set of
||TLV-encoded
||> |blocks, where each block represents a particular piece of preamble 
||> |data, extracted from the MPEG2-TS. The use of TLV-encoded blocks 
||> |provides extensibility.
||> |
||> |The idea expressed in the Xia draft is to extract the
||MPEG2-TS frames
||> |needed for the preamble from the media stream, cache them on the 
||> |server, and send them to the receiver on request in the form of 
||> |MPEG2-TS frames encapsulated in an RTP packet representing an RFC
||> |4588 retransmission of a synthetic RFC 2250 RTP packet
||encapsulating
||> |those MPEG2-TS frames (note that only the frames required for the 
||> |preamble are sent, not the complete RTP packets that contain them).
||> |
||> |After much discussion, it was understood that both proposals send 
||> |essentially the same data as the preamble. The key
||difference between
||> |them is the way in which that data is
||> |encapsulated: the Began draft extracts the preamble data from the 
||> |MPEG2-TS and wraps it into a TLV-encoded form for 
|transmission; the 
||> |Xia draft extracts the preamble data from the MPEG2-TS and 
|sends it 
||> |as a sequence of new MPEG2-TS frames wrapped in an RTP
||retransmission
||> |packet.
||> |
||> |We discussed compatibility of the two approaches with the RTP 
||> |standards. The Began draft is clearly compatible. The Xia draft is 
||> |not compatible as it stands, since the preamble is sent as an RTP 
||> |retransmission packet but contains a synthetic packet that 
|is not a 
||> |retransmission. This issue with the Xia draft can be solved by 
||> |formatting the preamble packets as RFC 2250 packets, rather
||than the
||> |current approach that uses an RFC 4588 retransmission of an
||RFC 2250
||> |packet.
||> |
||> |We discussed overheads, in terms of the number of packets 
|sent, and 
||> |vulnerability to packet loss. The two drafts generally send
||the same
||> |information in the same number of RTP packets in the
||preamble, and so
||> |have essentially the same overhead and resilience to loss. 
||> |Acquisition delays are also the same, since both send the same 
||> |information.
||> |
||> |The Began draft includes TLV headers which may provide extra 
||> |flexibility, but will slightly increase the packet size 
|compared to 
||> |the Xia draft which sends raw MPEG2-TS frames.
||> |
||> |The meeting concluded with an understanding that the two proposals 
||> |have essentially identical overheads and behaviour.
||> |The key difference between then, assuming the Xia proposal
||is updated
||> |to use RFC 2250 packets rather than RFC 4588 
|retransmissions of RFC 
||> |2250 packets to conform to the RTP specifications, is that
||the Begen
||> |draft includes additional TLV-headers to provide additional 
||> |flexibility and extensibility, at the expense of a slightly larger 
||> |packet. "
||> |
||> |
||> |So this report essentially says the two drafts are
||equivalent, and it
||> |comes down to a matter of preferences (i.e. does one prefer
||the blue
||> |one to the red one).
||> |
||> |ACTION TO WG MEMBERS
||> |---------------------
||> |
||> |Is there anything the WG members wish to add to this
||comparison that
||> |may influence the decision?
||> |
||> |Please respond to the list (and ideally to this thread) in
||advance of
||> |the face to face meeting, as again due to limited (and valuable) 
||> |meeting time; we will not have time in Anaheim for people
||to present
||> |these ideas afresh at the microphone.
||> |
||> |regards
||> |
||> |Keith
||> |
||> |
||> |_______________________________________________
||> |Audio/Video Transport Working Group
||> [email-masked]
||> |https://www.ietf.org/mailman/listinfo/avt
||> |
||> _______________________________________________
||> Audio/Video Transport Working Group
||> [email-masked]
||> https://www.ietf.org/mailman/listinfo/avt
||
||
|_______________________________________________
|Audio/Video Transport Working Group
[email-masked]
|https://www.ietf.org/mailman/listinfo/avt
|
|
|_______________________________________________
|Audio/Video Transport Working Group
[email-masked]
|https://www.ietf.org/mailman/listinfo/avt
|

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Mon, 15 Mar 2010 10:02:05 -0700

Roni and everyone,

Background: I am not taking any position on the relative merits of the two MPEG2 preamble proposals; at least not yet.

I do need to clarify something Roni wrote:

[Roni] "If the original MPEG2TS stream is not built in a way that will enable the
demultples/decider to use it than it is not related to this work and is
mentioned in the MPEG2-TS specification see bellow:"

"" System reference decoder
that of the STD.""

That section is orthogonal to the topic of the preferred ordering of various systems packets, such as PMT, PAT, PCR, EMM and ECM. The STD portion of the standard is part of the normative specification on bit streams; of course it is not the only normative section. I.e. necessary but not sufficient.

In the writing of the MPEG-2 Systems standard (i.e. where TS is specified), the consensus of the group was not to specify additional details on the systems packets; it was felt that better construction of streams could result in better performance, and vice versa, while interoperability could be obtained without additional specification, so the standard intentionally does not specify them. That does not mean that the order and placement of systems packets doesn't matter. There is a generally natural logical order to how receivers process these, as Bill Ver Steeg explained in a subsequent email.

I also want to add that the standard requires that any discontinuity of time bases, as reflected in PCRs, PTSs and DTSs, as well as CCs, must be marked as a discontinuity. If the PCRs do not follow all the time base rules due to a discontinuity, the discontinuity must be marked. An unmarked discontinuity, in addition to causing the stream to be non-conforming, naturally causes somewhat unpredictable behavior in decoders because it requires the decoders to perform some heuristics to determine what actually happened in the stream, and the heuristics may vary. For example, one PCR with an unexpected value could be a bit stream error, a spurious single encoder error, or an unmarked discontinuity.

--Sandy

---

From: Peilin YANG <[email-masked]>
Date: Tue, 16 Mar 2010 11:38:59 +0800

Hi Ali,

I am sorry. I replied later. 

I think that the main difference of our approach from the TOLV appraoch is that in our implementation MPEG-TS preamble information is transparent to the RTP session of RTP receiver. Application layer(MPEG-TS information, Audio/Video codec, etc) is independent to transport layer information(RTP session).It is very flexible for the RTP Receiver to support any MPEG2-TS Reference Information without any software Update. The information is recei
ved as an MPEG-TS raw data packets using MP2T payload format, and RTP receivers forward it to the demux/decoder. 
In TOLV approach, RTP receivers(transport layer) must understand application layer content(MPEG-TS information, Audio/Video codec, etc), and only understand the current preamble information in your draft. If an unknowable or unknown(e.g. IPMP) PSI information appears, firstly it must be necessary to revise preamble protocol; secondly, RTP Receivers must update there software based on the update. otherwise, it will affect the demux/decoder. 
In our approach, it doesn't.   

Other reply to your comments, please see inline.

Best regards,

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期日, 三月 14日, 2010 下午11:30
主题: Re: [AVT] MPEG2 preamble - comparison of mechanisms
收件人: "DRAGE, Keith (Keith)" <[email-masked]>, [email-masked]

Peilin: Perhaps you make a mistake. The burst starts after RAMS-I in the draft-xia-avt-mpeg2ts-preamble-02. It is the same as the RAMS draft.

2- Section 6: The receiver side operations are pretty generic in the
sense that they do not allow to tailor the preamble data based on the
specific requirements of the individual demux/decoders. Yes, these
devices are supposed to be standard compliant (and mostly they 
are) but as one would expect, these devices tend to behave differently when it
comes to tricks like RAMS. Unless their needs are specifically
addressed, sending preamble may not provide much additional benefit.
This is one of the main reasons we chose TLV encoding over sending raw
2250 packets.

Peilin: I don't understand what's the tailoring of preamble data that you mentioned. Is it that a TS preamble packet is cut to two parts? Or is it that two TS packets of one PSI information(e.g. ECM) is put in two RTP packets? In our approach we don't need to cut a TS preamble paket to two parts. The new RTP packet is constructed from the original TS preamble packets and considers the characteristic of origanl TS stream. In our commercial d
eployment there is no any problem for this. If this is a problem for your approach, I think the TOLV approach has greater limitations in the implementation.  
 
Is this something you intend not to consider in your 
implementation or
is it something you think the server should do? E.g., the server could
tailor the preamble data based on some hint information in the 
RAMS-R
message, although this negatively impacts server-side scalability 
due to
increased processing. An alternative that would keep the server side
more scalable, would be to put an MPEG2-TS parser logic in the RTP 
planeon the receiver side. That parser logic can parse the raw 
data and then
"post-process" it based on the specific needs of the 
demux/decoder. But,
as you can imagine running a parser logic is quite inefficient.
 
3- In our approach, the preamble data for the unencrypted streams and
most of the encrypted streams fits easily into a single RTP 
packet. This
is because most of the preamble data is efficiently encoded with TLV
encoding. E.g., 12-byte PAT data only requires 12 bytes + TLV 
headers as
opposed to a full 188-byte TS packet as in your approach.

So, if that single RTP packet makes it to the client side, we are 
done.For some of the encrypted streams, the CAS data may require 1-2
additional RTP packets. This will of course increase our vulnerability
to packet loss. But, there is not much we can do about it.

I'd like to understand how many RTP packet(s) your approach typically
needs to send. If your preamble data is > 7 TS packets, you will 
need at
least 2 RTP packets. Can you share some numbers with us for 
unencryptedand encrypted streams?

Peilin: I think this issue has been discussed clearly in Hiroshima. Two approach is almost the same to this. In fact,  in most cases one RTP packet is enough to reconstruct preamble information in our implementation.

Thanks,
-acbegen

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 16 Mar 2010 14:04:53 -0500

In either case, the software on the receiver will have to understand the syntax of the SI data. 

If the receiver simply jams the data into the receiver as if it came off the network, it has a very poor chance of working in an accelerated manner. The timing is much different. Code will have to be written to allow the device to digest one piece of the preamble (PAT/PMT/ECM/etc) prior to processing the next piece. If a new piece of SI is introduced in the field, the client code will have to be updated in any event. There are hundreds of implementations of MPEG decoders over the past 15 years, and they invariable require custom handling of the SI fields as they are passed into the various demux/decrypt/decode engines. The key point to be considered is that these actions are device specific, and in the worst case the actual bits presented to the hardware are changed in order to optimize the viewing experience (this is admittedly a corner case, but a real world corner case nonetheless). The correct place to do the fine grained manipulation of the MPEG2TS data is on the client device.

I strongly suggest that you do a sample implementation and port it to multiple devices in order to understand this aspect of the design space. Once we understand that the client will have to have knowledge of the SI structures, the design choice is much clearer.

You do bring up a good point on the need to have an extensible numbering space in the preamble scheme. We will take a look at this in our draft.

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peilin YANG
Sent: Monday, March 15, 2010 11:39 PM
To: Ali C. Begen (abegen)
Cc: DRAGE, Keith (Keith); [email-masked]
Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms

Hi Ali,

Best regards,

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期日, 三月 14日, 2010 下午11:30
主题: Re: [AVT] MPEG2 preamble - comparison of mechanisms
收件人: "DRAGE, Keith (Keith)" <[email-masked]>, [email-masked]

 

Thanks,
-acbegen

---

From: Peilin YANG <[email-masked]>
Date: Wed, 17 Mar 2010 08:37:42 +0800

Hi Bill, 

The preamble information is one of aspects of the accelerated acquisition. The more important information shall be buffer size, the size of I frame, burst rate and B-frame inforamtion. 
Even if RTP receivers address the preamble information very very quickly, it can not accelerate the acquisition if RTP receivers don't meet the demand of buffer size, I frame, B frame.
In our approach the preamble information is addressed firstly. It works very well in our commercial deployment.

Peilin   

----- 原邮件 -----
发件人: "Bill Ver Steeg (versteb)" <[email-masked]>
日期: 星期一, 三月 15日, 2010 下午10:59
主题: Re: [AVT] MPEG2 preamble - comparison of mechanisms
收件人: Roni Even <[email-masked]>, "Ali C. Begen (abegen)" <[email-masked]>, "DRAGE, Keith (Keith)" <[email-masked]>, [email-masked]

> constraints. The exact sequence of events depends on chipset being 
> used.If the data is sent in the wrong order, or without enough 
> spacing to
> thing" is very much client specific, and includes nasty device 
> specifictiming and device specific ordering. If we try to solve 
> these issues on
>   decoder in the following order:  PAT, PMT, PCR, EMM, ECM, 
> {Elementary   Stream Data}.  The PAT and PMT MUST be the first two 
> packets because
>   conditional access data that will be needed to descramble and 
> decode   the elementary stream."
> 
> ITU-T Rec. H.222.0 | ISO/IEC 13818-1 fields (for example, buffer 
> sizes)each
> elementary stream leads to its own parameterization of the STD. 
> Encodersshall produce bit streams that meet the appropriate STD's 
> constraints.Physical decoders may assume that a stream plays 
> properly on its STD.
> The
> system> > layers
> > is also an optimization, such implementation details become 
> important.> We cannot ignore them.
> > 
> > > orthogonal to the discussion and can be addressed in both 
> solutions> and
> > > even
> > draft is whether they are planning to address it or not. If yes, 
> how?> 
> > -acbegen

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Tue, 16 Mar 2010 20:15:59 -0700

Hello Peilin,

Is there some relationship between the preamble and this other information i.e. buffer size (VBV or HRD size?), size of I frame (not sure where or how that's specified in the scenario you envision), burst rate (not sure what you mean here) and the presence and attributes of B pictures? 

Are you suggesting that these are specified in the MPEG-2 TS packets that make up or contain a preamble in some particular system? Where?
And if so, why would specifying them in a preamble make a difference?

Generally, commercial decoders have to be able to handle all streams that conform to the applicable standard, profile and level, regardless of details such as these. Buffers have to be allocated in any case; I frames have to be decoded no matter how big they are as long as they fit in the VBV / HRD; the transport rate needs to be supported up to whatever is specified by the product; and B pictures have to be supported for profiles that allow them, with re-ordering performed by decoders as required by the bit streams.

I don't want to butt into this difficult decision, however I would like to understand the arguments.

--Sandy MacInnis

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peilin YANG
Sent: Tuesday, March 16, 2010 5:38 PM
To: Bill Ver Steeg (versteb)
Cc: DRAGE, Keith (Keith); [email-masked]; Roni Even
Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms

Hi Bill, 

Peilin

---

From: Roni Even <[email-masked]>
Date: Wed, 17 Mar 2010 09:12:14 +0200

Hi Sandy,
I think that what Peilin were trying to say in response to Bill's email is
that the preamble order is just one aspect of raid acquisition, there are
other aspects on the RTP layer that are not related to preamble but are also
important.
Roni Even
As Individual

> From: Sandy (Alexander) MacInnis [mailto:[email-masked]]
> Sent: Wednesday, March 17, 2010 5:16 AM
> To: Peilin YANG; Bill Ver Steeg (versteb)
> Is there some relationship between the preamble and this other
> information i.e. buffer size (VBV or HRD size?), size of I frame (not
> sure where or how that's specified in the scenario you envision), burst
> rate (not sure what you mean here) and the presence and attributes of B
> pictures?
> 
> Are you suggesting that these are specified in the MPEG-2 TS packets
> that make up or contain a preamble in some particular system? Where?
> Generally, commercial decoders have to be able to handle all streams
> that conform to the applicable standard, profile and level, regardless
> of details such as these. Buffers have to be allocated in any case; I
> frames have to be decoded no matter how big they are as long as they
> fit in the VBV / HRD; the transport rate needs to be supported up to
> whatever is specified by the product; and B pictures have to be
> supported for profiles that allow them, with re-ordering performed by
> decoders as required by the bit streams.
> 
> Peilin YANG
> The preamble information is one of aspects of the accelerated
> acquisition. The more important information shall be buffer size, the
> size of I frame, burst rate and B-frame inforamtion.
> Even if RTP receivers address the preamble information very very
> quickly, it can not accelerate the acquisition if RTP receivers don't
> meet the demand of buffer size, I frame, B frame.

---

From: David R Oran <[email-masked]>
Date: Wed, 17 Mar 2010 08:55:17 -0400

> other aspects on the RTP layer that are not related to preamble but are also
Right.

Also, here's an attempt to up-level for a moment concerning the apparent (or possibly real) disagreement we have on whether or not just conforming to the MPEG2TS multiplex formation rules by an RS constructing a preamble is adequate.

In the real world, there are receivers that barf on MPEG2TS sequences that are valid according to the MPEG2TS spec. If anybody doubts that, I suppose we can dig out the smoking guns, but it may be problematic for me to reveal the names of the specific vendors/products/chipsets that exhibit the various failures.

On the other hand, in the real world obviously we don't see serious rendering problems on these devices in the absence of trying to accelerate channel change.

What accounts for this apparent contradiction?

What works in steady state doesn't necessarily work for startup optimization. If a receiver/decoder misses or fails to sync on the first set of system information (and/or CAS information) in the broadcast/multicast mux, at worst the lock-in time is increased by a GOP or so. Once it gets going everything is fine.

But what we're doing with RAMS is stressing all the timing just as the decoder is trying to get going. THATs where all the problem are showing up. 

Have we seen decoders for which you can just jam the SI stuff back-to-back into them, just setting PCR discontinuous bits and things work? I'm actually not sure. I think among the 5+ implementations we've worked with some were OK for clear channel but I believe not a SINGLE one worked when ECMs from the CAS systems were thrown in the mix.

So, my conclusion is that, based on the real world, a scheme that uses a dumb receiver that just pushes into the decoder what it gets from the RS is NOT going to work unless the RS constructs EXACTLY the decoder-specific timing that's needed. That could include adjusting PCRs, or even inserting NULL frames (which as a side effect also increases the size of the preamble burst).

So, if we go for the scheme where the RS has to know what's acceptable to a particular RR, we will therefore need a protocol enhancement to RAMS-R (or possibly require a piggybacked RTCP packet to tell the RS the exact vendor make/model/version of the RR making the request. Otherwise the RS has no idea what to do.

If my analysis here is wrong, or I've been misinterpreting the actual in-field data we have, at the very least it would be prudent to get data to ensure things do in fact work with an RS-centric preamble scheme.

Note that this doesn't directly address the encoding question of whether the data gets sent as MPEG2TS or TOLV; only that whichever format is sent don't expect to get away with not ripping it all apart in the receiver and figuring out how to feed the decoder so it doesn't fall over.

Thanks, DaveO.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 17 Mar 2010 06:06:53 -0700

> I think that the main difference of our approach from the TOLV appraoch
> is that in our implementation MPEG-TS preamble information is
> transparent to the RTP session of RTP receiver. Application layer(MPEG-
> TS information, Audio/Video codec, etc) is independent to transport
> layer information(RTP session).It is very flexible for the RTP Receiver
> to support any MPEG2-TS Reference Information without any software
> Update. The information is recei
> ved as an MPEG-TS raw data packets using MP2T payload format, and RTP
> receivers forward it to the demux/decoder.

I believe this difference is already clear enough. The argument is how well dumping the preamble to the demux just works in practice. We should not produce a solution based on an algorithm that works on a particular system. 

> In TOLV approach, RTP receivers(transport layer) must understand
> application layer content(MPEG-TS information, Audio/Video codec, etc),
> and only understand the current preamble information in your draft. If

No, the RTP layer only needs to understand what to do with the incoming tlv elements and output TS packets such that the resulting stream provides the fastest RAMS acceleration for the specific demux running on this client. 

> an unknowable or unknown(e.g. IPMP) PSI information appears, firstly it
> must be necessary to revise preamble protocol; secondly, RTP Receivers

There is no need to revise the payload format. Registering a new type value with IANA will do it.

> must update there software based on the update. otherwise, it will
> affect the demux/decoder.

About updating the software, as I tried to explain several times before, we are not concerned about this as I am pretty sure we won't need any other element besides the ones we already defined. We don't see any benefit of using IPMP in the preamble context, but those who need it can simply register a new value with IANA.

> Peilin: Perhaps you make a mistake. The burst starts after RAMS-I in
> the draft-xia-avt-mpeg2ts-preamble-02. It is the same as the RAMS
> draft.

OK, there is another RAMS-I sent before the burst, but it should not be optional. Please remove the () around the first RAMS-I.
 
> Peilin: I don't understand what's the tailoring of preamble data that
> you mentioned. Is it that a TS preamble packet is cut to two parts? Or

No, I meant "customizing."

> is it that two TS packets of one PSI information(e.g. ECM) is put in
> two RTP packets? In our approach we don't need to cut a TS preamble
> paket to two parts. The new RTP packet is constructed from the original
> TS preamble packets and considers the characteristic of origanl TS
> stream. In our commercial d
> eployment there is no any problem for this. If this is a problem for
> your approach, I think the TOLV approach has greater limitations in the
> implementation.
> 

Sorry if "tailored" was not clear in the original email. Could you answer the questions above if it is clear now? Also see Bill's email from the other day. He explained in detail why such customization is critical.
 
> Peilin: I think this issue has been discussed clearly in Hiroshima. Two
> approach is almost the same to this. In fact,  in most cases one RTP
> packet is enough to reconstruct preamble information in our
> implementation.

In Hiroshima, this was not concluded actually and I am doubtful that both approaches require a comparable overhead. On your side, questions regarding the encrypted streams were left unanswered. That's why I am seeking clarification.

Cheers, acbegen.

---

From: Roni Even <[email-masked]>
Date: Wed, 17 Mar 2010 17:43:16 +0200

Hi Dave,
I can agree with your last sentence and I think that what was mentioned in
Hiroshima was that this is not a concern for the standard but an
implementation issue. 
The standard should define a solution for the conforming decoder. 
We can mention the issue of bad implementation concerns that you listed  in
the finished document regardless of which transport is used. 

Roni Even
As Individual

> From: David R Oran [mailto:[email-masked]]
> Sent: Wednesday, March 17, 2010 2:55 PM
> To: Roni Even
> Cc: 'Sandy (Alexander) MacInnis'; 'Peilin YANG'; 'Bill Ver Steeg
> (versteb)'; 'DRAGE, Keith (Keith)'; [email-masked]
> Also, here's an attempt to up-level for a moment concerning the
> apparent (or possibly real) disagreement we have on whether or not just
> conforming to the MPEG2TS multiplex formation rules by an RS
> constructing a preamble is adequate.
> 
> In the real world, there are receivers that barf on MPEG2TS sequences
> that are valid according to the MPEG2TS spec. If anybody doubts that, I
> suppose we can dig out the smoking guns, but it may be problematic for
> me to reveal the names of the specific vendors/products/chipsets that
> exhibit the various failures.
> 
> On the other hand, in the real world obviously we don't see serious
> rendering problems on these devices in the absence of trying to
> accelerate channel change.
> 
> What works in steady state doesn't necessarily work for startup
> optimization. If a receiver/decoder misses or fails to sync on the
> first set of system information (and/or CAS information) in the
> broadcast/multicast mux, at worst the lock-in time is increased by a
> GOP or so. Once it gets going everything is fine.
> 
> But what we're doing with RAMS is stressing all the timing just as the
> decoder is trying to get going. THATs where all the problem are showing
> up.
> 
> Have we seen decoders for which you can just jam the SI stuff back-to-
> back into them, just setting PCR discontinuous bits and things work?
> I'm actually not sure. I think among the 5+ implementations we've
> worked with some were OK for clear channel but I believe not a SINGLE
> one worked when ECMs from the CAS systems were thrown in the mix.
> 
> So, my conclusion is that, based on the real world, a scheme that uses
> a dumb receiver that just pushes into the decoder what it gets from the
> RS is NOT going to work unless the RS constructs EXACTLY the decoder-
> specific timing that's needed. That could include adjusting PCRs, or
> even inserting NULL frames (which as a side effect also increases the
> size of the preamble burst).
> 
> So, if we go for the scheme where the RS has to know what's acceptable
> to a particular RR, we will therefore need a protocol enhancement to
> RAMS-R (or possibly require a piggybacked RTCP packet to tell the RS
> the exact vendor make/model/version of the RR making the request.
> Otherwise the RS has no idea what to do.
> 
> If my analysis here is wrong, or I've been misinterpreting the actual
> in-field data we have, at the very least it would be prudent to get
> data to ensure things do in fact work with an RS-centric preamble
> scheme.
> 
> Note that this doesn't directly address the encoding question of
> whether the data gets sent as MPEG2TS or TOLV; only that whichever
> format is sent don't expect to get away with not ripping it all apart
> in the receiver and figuring out how to feed the decoder so it doesn't
> fall over.
> 
> Thanks, DaveO.
> 
> 
> > Roni Even
> > As Individual
> >
> >> I don't want to butt into this difficult decision, however I would
> like
> >> to understand the arguments.
> >>
> >> --Sandy MacInnis
> >>
> >> In our approach the preamble information is addressed firstly. It
> works
> >> very well in our commercial deployment.
> >>
> >> Peilin
> >

---

From: David R Oran <[email-masked]>
Date: Wed, 17 Mar 2010 12:08:09 -0400

> Hiroshima was that this is not a concern for the standard but an
I only partly agree with this.

What I agree with: you can write receiver code to make things work with either scheme.
What I disagree with: that packaging as MPEG2TS brings inherent advantages from an RS or RR standpoint if the RR is going to have to rip things apart and retime/reorder/rework them anyway. 

In fact, if we don't allocate a new payload format or somehow explicitly mark that the received RTP packets constitutes a preamble, (even if we use RFC2250 packetization rules) you now make it very hard for a receiver to even know it needs to rip things apart as opposed to stuffing them transparently into the decoder.

DaveO.

---

From: Roni Even <[email-masked]>
Date: Wed, 17 Mar 2010 18:19:59 +0200

Hi Ali,
Inline
Roni Even
As Individual

> Sent: Wednesday, March 17, 2010 3:07 PM
> To: Peilin YANG
> I believe this difference is already clear enough. The argument is how
> well dumping the preamble to the demux just works in practice. We
> should not produce a solution based on an algorithm that works on a
> particular system.

Roni Even: We are not talking about particular system but about conforming
systems. This is what we develop protocols for.

> No, the RTP layer only needs to understand what to do with the incoming
> tlv elements and output TS packets such that the resulting stream
> provides the fastest RAMS acceleration for the specific demux running
> on this client.

Roni Even: So you need a solution per specific demux?

> About updating the software, as I tried to explain several times
> before, we are not concerned about this as I am pretty sure we won't
> need any other element besides the ones we already defined. We don't
> see any benefit of using IPMP in the preamble context, but those who
> need it can simply register a new value with IANA.

Roni Even: The initial subset of PSI information specified in your draft is
based on your optimization, yet if some RS implementers wants to do another
optimization, your suggestion is for him to define new TOLVs yet he will not
know if they are supported on the receiver and he may lose what he precedes
as his edge. In the Xia draft this is simpler since all information is
already defined and can be processed by the receiver.

> OK, there is another RAMS-I sent before the burst, but it should not be
> optional. Please remove the () around the first RAMS-I.
> 
> > are) but as one would expect, these devices tend to behave
> differently
> > when it
> Sorry if "tailored" was not clear in the original email. Could you
> answer the questions above if it is clear now? Also see Bill's email
> from the other day. He explained in detail why such customization is
> critical.
> 
> In Hiroshima, this was not concluded actually and I am doubtful that
> both approaches require a comparable overhead. On your side, questions
> regarding the encrypted streams were left unanswered. That's why I am
> seeking clarification.
> 
> Cheers, acbegen.
> 
> >
> > Thanks,
> > -acbegen
> >
>

---

From: David R Oran <[email-masked]>
Date: Wed, 17 Mar 2010 12:36:36 -0400

> As Individual
[snip]
> systems. This is what we develop protocols for.
Only half seriously, but I hold up RFC3261 as a clear counter-example, at least if you start with the assumption that we only cared about systems that "conformed" to RFC2540.

There is significant stuff in RFC3261 specifically to deal with compatibility with things that "conformed" to 2540 but actually would not interoperate with each other under all circumstances in the real world or when combined with implementations of RFC3261.

Wondering out loud: I wonder if anybody in the MPEG world actually wrote conformance tests to prove that the "conforming" MPEG2TS decoders in fact would not drop stuff until they lined up everything with the ordering and timing they liked assuming they started receiving at an arbitrary place in the mux. We may be in a similar situation here if the vast majority of MPEG2TS implementations in the field would in fact flunk such a conformance test.

I can state with high confidence that if the receivers don't rip things apart and redo the timing and ordering RAMS WILL NOT WORK in many cases we see in the real world using equipment deployed in the millions.

We can call this an "implementation problem" and punt, but I don't think that's the right thing to do in this case.

DaveO.

P.S. I reiterate that I understand perfectly this is only one factor in choosing the wire encoding.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 17 Mar 2010 09:43:48 -0700

> systems. This is what we develop protocols for.

Looks like we are drawing circles here. As explained by many others on
the list already, all these decoders, etc. may be conforming within the
bounds specified in the standard, but they may differ grossly in many
other things, one of which is the decoder initialization. So, let's not
use conforming vs. non-conforming anymore. 

...
> Roni Even: So you need a solution per specific demux?

The preamble post processing *must* be customized for the demux/decoder
running on that box if you wanna get the *best* out of RAMS and make
sure it always works. 
 
...
> already defined and can be processed by the receiver.

Two things. I personally do not think the RS-based approach is a good
idea due to scalability concerns. If the WG wants to discuss it, let's
open a new thread for it. But, we have yet to see a single person
cheering for that idea. 

Secondly, all the type values a server would need (in our opinion) are
already registered in our draft. If a new one is indeed needed, then it
has to be registered.

BTW, my original questions to the authors are still unanswered. 

-acbegen

---

From: Frank Xia <[email-masked]>
Date: Wed, 17 Mar 2010 12:17:24 -0500

Hi Ali

Please also check my response.

BR
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C.
Begen (abegen)
Sent: Wednesday, March 17, 2010 11:44 AM
To: Roni Even; Peilin YANG
Cc: DRAGE, Keith (Keith); [email-masked]
Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms

Looks like we are drawing circles here. As explained by many others on
the list already, all these decoders, etc. may be conforming within the
bounds specified in the standard, but they may differ grossly in many
other things, one of which is the decoder initialization. So, let's not
use conforming vs. non-conforming anymore. 
Frank=>IMHO, Once standardized, the protocol should be honored. I did
not attend the discussion for a while, however, just you said we are
drawing circles here. 

...

Frank=>Let focus on the problem which is how to convey preamble information
from RS to RR.  Customized or optimized implementation is out of the scope.
At the same time, customized solution does not mean your solution is better,
and
solution does not prevent any customizing.  
 
...

Two things. I personally do not think the RS-based approach is a good
idea due to scalability concerns. If the WG wants to discuss it, let's
open a new thread for it. But, we have yet to see a single person
cheering for that idea. 
Frank=>IMHO, RR involvement really has scalability issue. I encourage
you just to do technical clarification and leave space for the WG to think
about it.

BTW, my original questions to the authors are still unanswered. 
Frank=>I don't know remember what are your original questions, and
you can bring them again if you don't mind.  Please also answer my
questions: 
  1)does a RS need to upgrade to support your solution?
  2)does your solution need to update when a special standard-compliant
    RR need special preamble information which is missed in your draft? 
    (My colleague Peilin gave this scenario)
This is inherent disadvantage for RR-involved solution.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 17 Mar 2010 10:55:43 -0700

> solution does not prevent any customizing.

OK, let's start with a very basic question.

I argue that putting the TS packets carrying the useful preamble
information (pat, pmt, etc.) and feeding them to decoder directly
without any sort of client-specific pre or post-processing does not
bring us much since this approach does not work for all clients (i.e.,
decoders). It may work for some but even for those, it does not
necessarily deliver the best performance.

Do you agree or disagree? 

If you disagree, this is surely the first item we need to discuss next
week.

If you agree with his, then the 2nd question is whether you think we
should do post-processing (at the client as our draft proposes) or
pre-processing at the server side based on some client-specific
information carried in the RAMS-R.

>From where I stand, your draft seems to be only concerned about the
packaging. AFAICT your draft does not remove the possibility of
customizing the preamble, but it does not really make customization
easy, either. Naturally, your draft does not favor post-processing at
the client and your negative stand against client-side post-processing
is very clear. However, your stand against server-side pre-processing is
not clear in your draft or your emails (BTW, this is one of the
questions I asked earlier). 

I believe these are the very basic questions the WG needs to consider.
 
> you just to do technical clarification and leave space for the WG to

Huh? Are you saying server-side pre-processing scales better? 

My argument for client-side processing is simple. Extract the preamble
from the SSM streams, cache them in a generic manner and simply send it
to any requesting client. So, if a server is serving for 100 different
classes of clients, it won't care which specific client was requesting
the preamble.  
 
> you can bring them again if you don't mind.  Please also answer my

See the email I sent on Sunday morning around 8:30am US eastern time. It
was a reply to Keith's email.

>   1)does a RS need to upgrade to support your solution?

It needs to extract the preamble from the incoming RTP packets (this is
a common step for any approach). Then, our RS needs to encode the tlv
elements and create the preamble RTP packets.

>     RR need special preamble information which is missed in your
draft?

Right, the code that will go into that special client will have to be
augmented/modified based on its particular needs.

> This is inherent disadvantage for RR-involved solution.

The post-processing code we need to have on a client is also included
when the generic RAMS code is being embedded on that client. So, this
does not represent any additional cost or complexity for actual
deployment. The only additional work one needs to do is to develop the
post-processing module for that class of clients. But, this cost is more
than justified in our view for the improvements it delivers.

We shared our reference implementation as an open source. So, anybody
looking at that code should be able to confirm my arguments above.

-acbegen

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Wed, 17 Mar 2010 11:15:51 -0700

Please see my comments below.

--Sandy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David R Oran
Sent: Wednesday, March 17, 2010 9:37 AM
To: Roni Even
Cc: 'DRAGE, Keith (Keith)'; [email-masked]
Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms

[snip]

[Sandy] The MPEG-2 TS standard doesn't specify exactly what conforming receivers should do in each case of when the various system information elements arrive. So a receiver can't be non-conforming if it does not acquire a new stream as quickly as someone would like. Rather, channel change time is a competitive attribute between different implementations. Exactly how any given receiver achieves good channel change / acquisition time may be a trade secret, and the specific limitations of any given receiver may also be a trade secret. 

[Sandy] Streams may be created to facilitate quick channel change time & rapid acquisition, or not. A stream where the information is placed in an order or timing that's bad for channel change (acquisition) may also conform to the MPEG-2 TS standard while resulting in poor channel change / acquisition time.

[Sandy] So it's not unreasonable to expect both receivers and streams to vary widely in terms of acquisition time even if they all conform to the applicable standards. I'm glad this committee is working to address this situation via RAMS. Whatever we come up with should be quite robust and broadly applicable.

DaveO.

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 17 Mar 2010 14:50:42 -0400

> So, let's not use conforming vs. non-conforming anymore. 

I decided not to follow this thread anymore, but this really caught my eyes,
seriously. We are herein working on standards, for which the purpose is for
interoperability through conformance. What can be more important than
conformance to talk about in standardization?

BR, YK

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ali C. Begen (abegen)
> Sent: Wednesday, March 17, 2010 12:44 PM
> > Roni Even: We are not talking about particular system but about 
> > conforming systems. This is what we develop protocols for.
> 
> Looks like we are drawing circles here. As explained by many 
> others on the list already, all these decoders, etc. may be 
> conforming within the bounds specified in the standard, but 
> they may differ grossly in many other things, one of which is 
> the decoder initialization. So, let's not use conforming vs. 
> non-conforming anymore. 
> 
> ...
> The preamble post processing *must* be customized for the 
> demux/decoder running on that box if you wanna get the *best* 
> out of RAMS and make sure it always works. 
>  
> ...
> > Roni Even: The initial subset of PSI information specified in your 
> > draft is based on your optimization, yet if some RS 
> implementers wants 
> > to do another optimization, your suggestion is for him to 
> define new 
> > TOLVs yet he will not know if they are supported on the 
> receiver and 
> > he may lose what he precedes as his edge. In the Xia draft this is 
> > simpler since all information is already defined and can be 
> processed 
> > by the receiver.
> 
> Two things. I personally do not think the RS-based approach 
> is a good idea due to scalability concerns. If the WG wants 
> to discuss it, let's open a new thread for it. But, we have 
> yet to see a single person cheering for that idea. 
> 
> Secondly, all the type values a server would need (in our 
> opinion) are already registered in our draft. If a new one is 
> indeed needed, then it has to be registered.
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 17 Mar 2010 12:03:45 -0700

It is clear that you were not following the thread closely. Some people
who are quite experienced in mpeg2ts already explained this clearly in
the list. Nobody here is trying to do something non-conforming or
developing a solution for non-conforming products.

-acbegen

> From: Ye-Kui Wang [mailto:[email-masked]]
> Sent: Wednesday, March 17, 2010 11:51 AM
> To: Ali C. Begen (abegen); 'Roni Even'; 'Peilin YANG'
> seriously. We are herein working on standards, for which the purpose
is
> for

---

From: Roni Even <[email-masked]>
Date: Wed, 17 Mar 2010 23:45:59 +0200

Hi Dave,
The Xia proposal send the preamble as an RFC 2250 stream and mark is as
preamble using a new SDP attribute, see the draft.
Roni Even 
As Individual

> Sent: Wednesday, March 17, 2010 6:08 PM
> To: Roni Even
> Cc: 'DRAGE, Keith (Keith)'; 'Sandy (Alexander) MacInnis'; 'Bill Ver
> Steeg (versteb)'; [email-masked]
> What I disagree with: that packaging as MPEG2TS brings inherent
> advantages from an RS or RR standpoint if the RR is going to have to
> rip things apart and retime/reorder/rework them anyway.
> 
> In fact, if we don't allocate a new payload format or somehow
> explicitly mark that the received RTP packets constitutes a preamble,
> (even if we use RFC2250 packetization rules) you now make it very hard
> for a receiver to even know it needs to rip things apart as opposed to
> stuffing them transparently into the decoder.
> 
> DaveO.
> 
> 
> >>> that the preamble order is just one aspect of raid acquisition,
> there
> >> are
> >>>> of details such as these. Buffers have to be allocated in any
> case;
> >> I

---

From: David R Oran <[email-masked]>
Date: Wed, 17 Mar 2010 18:44:28 -0400

> preamble using a new SDP attribute, see the draft.
As long as those are the only RFC2250 payloads you'd ever see on this session, I guess the receiver can figure out that what's preamble and what isn't.
Thanks, DaveO.

---

From: Qin Wu <[email-masked]>
Date: Thu, 18 Mar 2010 10:35:35 +0800

> information carried in the RAMS-R.

[Qin]: Sorry to interrupt in. Bcos I am a little difficult to understand this point.
Are you saying the client should do post-processing before sending the RAMS-R?
Are you saying the RS should do the pre-processing after receiving RAMS-R? 
Not sure this is a valid point. 
If you talk about RAMS-I can be pre-processed by the server and be 
processed by the client, I am also confused. Bcos I don't believe protocol operation
for the RTCP messages can be taken as pre or post process, what am I missing?

---

From: Peilin YANG <[email-masked]>
Date: Thu, 18 Mar 2010 12:05:22 +0800

Hi Sandy,

Your question is right.There is no close relationship between the preamble and this other information. As Roni said that the preamble order is just one aspect of rapid acquisition.

Thanks a lot.

Best regards,

Peilin

----- 原邮件 -----
发件人: Roni Even <[email-masked]>
日期: 星期三, 三月 17日, 2010 下午3:12
主题: RE: [AVT] MPEG2 preamble - comparison of mechanisms
收件人: "'Sandy (Alexander) MacInnis'" <[email-masked]>, 'Peilin YANG' <[email-masked]>, "'Bill Ver Steeg (versteb)'" <[email-masked]>
抄送: "'DRAGE, Keith (Keith)'" <[email-masked]>, [email-masked]

> there are
> > information i.e. buffer size (VBV or HRD size?), size of I frame 
> (not> sure where or how that's specified in the scenario you 
> envision), burst
> > And if so, why would specifying them in a preamble make a 
> difference?> 
> > that conform to the applicable standard, profile and level, 
> regardless> of details such as these. Buffers have to be allocated 
> in any case; I
> > I don't want to butt into this difficult decision, however I 
> would like
> Behalf Of
> > quickly, it can not accelerate the acquisition if RTP receivers 
> don't> meet the demand of buffer size, I frame, B frame.
> > In our approach the preamble information is addressed firstly. 
> It works

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 17 Mar 2010 22:58:00 -0700

The difference I was trying to show is that where (on the server side or
on the receiver side) we should do the preamble customization. If we do
it on the receiver side, I call it "post-processing." If the server does
it, I call it "pre-processing." The server can do the needed
customization only if it knows the type/model/etc. of the decoder
running on the receiver side. And a natural way to convey that
information is to use a new tlv element in RAMS-R.

The preamble has not much to do with RAMS-I.

-acbegen

> From: Qin Wu [mailto:[email-masked]]
> Sent: Wednesday, March 17, 2010 7:36 PM
> To: Ali C. Begen (abegen); Frank Xia; Roni Even; Peilin YANG

---

From: Qin Wu <[email-masked]>
Date: Thu, 18 Mar 2010 14:31:59 +0800

Hi,
Thank for your clarification. In my understanding, post-processing happens after the client receives the preamble data packet.
pre-processing occurs before the RS send preamble data packet. 
Therefore  in your Ali's draft, if the client attempts to do post processing, it should indicate this behavior in the 
RAMS-R before the preamble packet arrive at client. but also as you said,it is not neccessary for the RS to indicate something about preamble in the RAMS-I in your solution.
So I think it seems reasonable for the server to choose appropriate packet format(RFC2250 format or TOLV Element ) when the server receives RAMS-R, which is also
emphasized by Stephan in the Mailing list.
Bcos the new tlv element in the RAMS-R also can be used to convey packet encapsulation method. That's my 2cents.

Regards!
-Qin
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Frank Xia" <[email-masked]>; "Roni Even" <[email-masked]>; "Peilin YANG" <[email-masked]>
Cc: "DRAGE, Keith (Keith)" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 18, 2010 1:58 PM
Subject: RE: [AVT] MPEG2 preamble - comparison of mechanisms

-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Thu, 18 Mar 2010 09:20:02 +0000

Roni,

It'd have to use a different payload type, signalled by a new media  
type for the preamble information, surely?

Colin

On 17 Mar 2010, at 21:45, Roni Even wrote:
>> What I agree with: you can write receiver code to make things work  
>> with
>> either scheme.
>>>>> other aspects on the RTP layer that are not related to preamble  
>>>>> but
>>>> are also
>>>>> important.
>>>> Right.
>>>>
>>>> (not
>>>>>> rate (not sure what you mean here) and the presence and  
>>>>>> attributes
>>>> of B
>>>>>> pictures?
>>>>>>
>>>> difference?
>>>> regardless
>>>>>> supported for profiles that allow them, with re-ordering  
>>>>>> performed
>>>> by
>>>>>> would
>>>>>> Behalf
>>>> Of
>>>> don't

-- 
Colin Perkins
http://csperkins.org/