Subject: [AVT] MPEG2 preamble - comparison of mechanisms

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Wed, 17 Mar 2010 23:41:33 +0100

Hi,
 
I would like to understand better the difference in processing required
at the RS side and at the RTP receiver side in the two solutions.
Because  I understand from the mailing list discussions there is a
difference in scalability as a result of the different ways the preamble
is transported between RS and receiver in the respective drafts:
 
Xia draft: RS needs to detect where the pre-amble information is in the
SSM (which TS packets in which RTP packets in the recently cached data
contain MPEG2 TS preamble data),  brings together these TS packets in
separate RTP packets ( RFC2250) and transmits these to the receiver. The
RTP receiver needs to understand these are the preamble MPEG2 TS
packets.
 
Begen draft: RS needs to detect where the pre-amble information is in
the SSM, needs to extract this specific data, put these in the TOLV
elements, and packages them together in RTP packets. The RTP receiver
-as indicated in the section 7 of the draft, extracts the pre-amble data
and generates again a sequence of MPEG2 TS packets.
 
It is not 100% clear to me 
-what is the implied difference for receiver side processing among the
two solutions (Which one requires more processing power?)
-which solution can be better "customised"? (Not sure this a
differentiator to be concerned with?)
-which solution has more impact at the server side (And hence is not as
scalable compared to the other approach)
 
Another question: taking into account the min/max frequency of the
appearance of MPEG 2 TS preamble info inside a compliant MPEG2TS stream,
how much time is actually saved compared to sending a RAMS burst -only?
I know this is not impacted in a different way by the two solutions
(unless I have missed something here), but I think it is worthwhile to
provide a figure like this to justify better the need of sending MPEG2
TS preamble info in dedicated packets prior to the burst.
 
.. and how much extra waiting time is then actually introduced when the
pre-amble info is sent inside the RAMS burst as retransmission packets?
When sending MPEG2 TS preamble info as retransmission packets, isn't
that one processing step less at the RS side as well, compared to the
solutions in the two pre-amble drafts?
 
Tom

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 18 Mar 2010 00:27:02 -0700

Hi Tom,

I will attempt to answer your questions as much as I can.

> I would like to understand better the difference in processing
required at the RS side and at the RTP
> receiver side in the two solutions. Because  I understand from the
mailing list discussions there is a
> difference in scalability as a result of the different ways the
preamble is transported between RS and
> receiver in the respective drafts:

If the server extracts the preamble information for each TV channel, the
amount of the work the server will be doing will be in the order of
O(N), where N is the number of TV channels this server provides RAMS
acceleration for. It does not matter whether this server serves as an RS
for one client or one million clients or whether all of the clients are
using the same decoder or different ones. The server uses the same
preamble for any of the clients.

If the server extracts the preamble information for N TV channels and
also customizes it for M different decoders, the complexity will be in
the order of O(NxM). M will be 1 at minimum meaning that only one type
of decoder is being used by the client population. M will be the number
of clients served by this RS at maximum meaning that every client uses a
different decoder type.
 
> Xia draft: RS needs to detect where the pre-amble information is in
the SSM (which TS packets in which
> RTP packets in the recently cached data contain MPEG2 TS preamble
data),  brings together these TS
> packets in separate RTP packets ( RFC2250) and transmits these to the
receiver. The RTP receiver needs
> to understand these are the preamble MPEG2 TS packets.

Correct.
 
> Begen draft: RS needs to detect where the pre-amble information is in
the SSM, needs to extract this
> specific data, put these in the TOLV elements, and packages them
together in RTP packets. The RTP
> receiver -as indicated in the section 7 of the draft, extracts the
pre-amble data and generates again
> a sequence of MPEG2 TS packets.

Correct.
 
> -what is the implied difference for receiver side processing among the
two solutions (Which one
> requires more processing power?)

Xia draft receives the preamble (RTP) packets, extracts the TS packets
out of them and feeds the TS packets directly to the decoder. 

Begen draft receives the preamble packets, extracts the TOLV elements
and generates new TS packets customized for the particular decoder
running on the client. And then these TS packets are fed to the decoder.

Should you be concerned about this post-processing stage? Just look at
our implementation and decide yourself.

We argue customization is the most critical component in this whole
preamble business. Begen draft is all for customization. Xia draft, as
it stands now and based on the authors' input, does not offer any
customization.

> -which solution has more impact at the server side (And hence is not
as scalable compared to the other
> approach)

Both approaches need to extract the preamble from the SSM streams. If
this is the only thing they are tasked for, the impact on the server is
more or less identical for both approaches.

The difference is Xia draft keeps the TS packets, whereas Begen draft
encodes the preamble into TOLV elements. As I explained above, this
overhead is of order O(N) not O(NxM). So, it is not a concern at least
for me.
 
> Another question: taking into account the min/max frequency of the
appearance of MPEG 2 TS preamble
> info inside a compliant MPEG2TS stream, how much time is actually
saved compared to sending a RAMS
> burst -only?  I know this is not impacted in a different way by the
two solutions (unless I have
> missed something here), but I think it is worthwhile to provide a
figure like this to justify better
> the need of sending MPEG2 TS preamble info in dedicated packets prior
to the burst.

The best-case scenario is when everything is aligned in the transport
stream in the order the decoder can fully absorb the needed information.
In this case, preamble won't bring any additional benefit. But, the
chances are pretty slim, if not zero, for this to happen (particularly
for encrypted streams).

The worst-case scenario is when the needed information is aligned in an
order in which the decoder cannot really absorb it. The chances are also
slim for this scenario but the cost could be close to a second or maybe
more. 

On the average, the potential reduction offered by the preamble (if
customized properly for the client) will be in the order of 100s of
milliseconds.

I have to mention that this is based on what I have seen so far. Numbers
will be different for different streams or at different locations in the
same stream. I'd be interested to hear from others, too.
 
> .. and how much extra waiting time is then actually introduced when
the pre-amble info is sent inside

I can speak for our proposal. As I mentioned earlier, for most streams
we send only one RTP packet for the preamble. For encrypted streams,
sometimes this could be 2-3 RTP packets (depending on the size of ECM).
Yet, compared to the size of the unicast burst, even 3 packets is not a
big overhead.

> the RAMS burst as retransmission packets? When sending MPEG2 TS
preamble info as retransmission
> packets, isn't that one processing step less at the RS side as well,
compared to the solutions in the
> two pre-amble drafts?

How so? In the 3rd solution you propose, the server still needs to
figure out which RTP packets are carrying the TS packets that have a
piece of the preamble information. And all those TS packets could be
spread over a large number of RTP packets. If you try to retransmit all
of those packets as a part of the burst, then the overhead will likely
to be a concern.

HTH,
-acbegen

---

From: David R Oran <[email-masked]>
Date: Thu, 18 Mar 2010 08:57:44 -0400

On Mar 18, 2010, at 3:27 AM, Ali C. Begen (abegen) wrote:

> the order of O(NxM).
This assumes a fairly stupid implementation, and represents the worst case. I would assume at least the per-decoder customization could be done lazily, and hence you only pay the cost when the RAMS-R comes in.

> M will be 1 at minimum meaning that only one type
Highly unlikely...

> out of them and feeds the TS packets directly to the decoder. 
Well, that's what the draft says, but it doesn't have to say that, and if it is selected by the WG we should be well-advised to update it, unless we want to ignore the simple fact that there is in-field unequivocal data that this won't work.

> our implementation and decide yourself.
Compared with all the rest of what you have to do to make RAMS work, I can say with confidence that for TOLV preamble processing is not the bottleneck. Complexity creeps in if the preamble does not fit in a single RTP packet. Our code is highly optimized for the single-packet case, because:
- the receiver does not have to buffer and combine the stuff it gets to consider how to retime and reorder at the same time it's doing receive processing. It would need to figure out when it has got "enough", which may or may to be straightforward - I haven't thought enough about it to know if this is a tricky problem or not.
- at least the way our code is structured, the single packet of TOLV preamble considerably simplifies the "commit" operation - the moment at which you actually commit to doing the RAMS operation at the receiver. This is important because if you commit a RAMS that later fails, the user experience is likely to be worse than it would have been had you not started to get the decoder going.

As an aside, we have yet to see a case where the preamble as TOLV is longer than a single MTU-sized RTP packet. It can happen in theory through. The most likely reasons would be:
- use of some of the big optional SI elements some European operators use with DVB encoders
- excessive key sizes and metadata in ECMs
- inband EMMs that have not been already obtained by the receiver through other means (e.g. the EMMs are likely to be the same across all the channels, or in a separate stream the receiver listens to on startup).

The former can of course be safely ignored as RAMS preamble, but the latter two could cause the burst to fail if they are not properly received and processed.

> it stands now and based on the authors' input, does not offer any
I would not make a big deal out of this, as it doesn't take rocket science to figure out how to do the post processing with an RFC2250 encoding of the preamble. Roni helpfully explained away one worry I had (that you didn't know whether you had a preamble or something else when you got the RFC2250 packets on the RAMS session). This leaves the implementation question i thought of above, which is how you know in the multi-packet case when you have enough of the preamble to do the retiming/reordering operations.

> more or less identical for both approaches.
Yes. I think this is accurate.

> overhead is of order O(N) not O(NxM). So, it is not a concern at least
Right, and for Xia the computation is also O(N) if one makes the (IMO only reasonable) design choice to do the necessary retiming/reordering at the RR and abandons the approach of trying to to it at the RS.

> chances are pretty slim, if not zero, for this to happen (particularly
Right. While it would be interesting to see just how much bigger this is, I think Ali has this right for encrypted streams because the ECM is likely to be *seconds* back in the stream.

> slim for this scenario but the cost could be close to a second or maybe
Well, this has happened on reals streams in the reals world, and if we don't deal with it you will have a deterministic "this stream cannot do RAMS on this RR imlementation" situation.

> Yet, compared to the size of the unicast burst, even 3 packets is not a
Actually, while the code deals with this (and I'd have to check) I don't think we've yet seen a case where it didn't fit in a single TOLV-encoded packet, except in our test streams i the lab specifically crafted to test the multi-packet receive code. I could double-check on this if people think its important to know for making a decision between the schemes.

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 18 Mar 2010 06:19:05 -0700

> -----Original Message-----
> From: Dave Oran (oran)
> Sent: Thursday, March 18, 2010 5:58 AM
> To: Ali C. Begen (abegen)
> Cc: VAN CAENEGEM Tom; [email-masked]
> Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms
> 
> 
> This assumes a fairly stupid implementation, and represents the worst
case. I would assume at least
> the per-decoder customization could be done lazily, and hence you only
pay the cost when the RAMS-R
> comes in.

Sure, the cost does not have to paid until one requested for a specific
preamble. But, still this is O() analysis.
 
> > of clients served by this RS at maximum meaning that every client
uses a

Also agree.
 
...
> Well, that's what the draft says, but it doesn't have to say that, and
if it is selected by the WG we
> should be well-advised to update it, unless we want to ignore the
simple fact that there is in-field
> unequivocal data that this won't work.

It does not have to say that, and Xia draft could "post process" these
TS packets to customize the preamble, too. But, so far, the answers to
my earlier questions made me believe that this was not intended.
 
... 
> I would not make a big deal out of this, as it doesn't take rocket
science to figure out how to do the
> post processing with an RFC2250 encoding of the preamble. Roni
helpfully explained away one worry I
> had (that you didn't know whether you had a preamble or something else
when you got the RFC2250
> packets on the RAMS session). This leaves the implementation question
i thought of above, which is how
> you know in the multi-packet case when you have enough of the preamble
to do the retiming/reordering
> operations.

I will let Xia authors answer this one.
 
> Right, and for Xia the computation is also O(N) if one makes the (IMO
only reasonable) design choice
> to do the necessary retiming/reordering at the RR and abandons the
approach of trying to to it at the
> RS.

Yup.
 
> Right. While it would be interesting to see just how much bigger this
is, I think Ali has this right
> for encrypted streams because the ECM is likely to be *seconds* back
in the stream.

By the way, even if everything is well aligned, the preamble info may be
spread over a few RTP packets since a common RTP packet size can carry
only 7 TS packets.
 
> Well, this has happened on reals streams in the reals world, and if we
don't deal with it you will
> have a deterministic "this stream cannot do RAMS on this RR
imlementation" situation.

Yup.
 
...

-acbegen

---

From: Frank Xia <[email-masked]>
Date: Thu, 18 Mar 2010 10:06:49 -0500

Hi Tom

Let me explain .

BR

Frank

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of VAN
CAENEGEM Tom
Sent: Wednesday, March 17, 2010 5:42 PM
To: [email-masked]
Subject: [AVT] MPEG2 preamble - comparison of mechanisms

Hi,

I would like to understand better the difference in processing required at
the RS side and at the RTP receiver side in the two solutions. Because  I
understand from the mailing list discussions there is a difference in
scalability as a result of the different ways the preamble is transported
between RS and receiver in the respective drafts:

Frank=>We claim client-agnostic mechanism is easy to deployed, while the
other document is told

that a client is easy to be customized.  Scalability is only one of
arguments, and both sides claim

to have advantage in scalability.

Xia draft: RS needs to detect where the pre-amble information is in the SSM
(which TS packets in which RTP packets in the recently cached data contain
MPEG2 TS preamble data),  brings together these TS packets in separate RTP
packets ( RFC2250) and transmits these to the receiver. The RTP receiver
needs to understand these are the preamble MPEG2 TS packets.

Frank=>Any standard conformant receiver understands the preamble MPEG2 TS.
Our goal is to keep the receiver  unchanged.  

Begen draft: RS needs to detect where the pre-amble information is in the
SSM, needs to extract this specific data, put these in the TOLV elements,
and packages them together in RTP packets. The RTP receiver -as indicated in
the section 7 of the draft, extracts the pre-amble data and generates again
a sequence of MPEG2 TS packets.

-what is the implied difference for receiver side processing among the two
solutions (Which one requires more processing power?)

Frank=>I believe ours is better because there is no any additional
processing needed.

-which solution can be better "customised"? (Not sure this a differentiator
to be concerned with?)

Frank=>IMO, there is no difference.  The same information are carried to the
receiver which can do whatever it want to.

Frank=>IMO, there is no perceivable difference.  We use standard TS to carry
preamble, while the 

other document uses  TLV.   From server perspective, the only difference is
to choose different transportation method to

carry the preamble.

Another question: taking into account the min/max frequency of the
appearance of MPEG 2 TS preamble info inside a compliant MPEG2TS stream, how
much time is actually saved compared to sending a RAMS burst -only?  I know
this is not impacted in a different way by the two solutions (unless I have
missed something here), but I think it is worthwhile to provide a figure
like this to justify better the need of sending MPEG2 TS preamble info in
dedicated packets prior to the burst.

Frank=>Considering preamble is necessary when parsing RAMS burst

while it is possible dispersed in wide range, it makes sense to have 

dedicated preamble packets prior to the burst.

.. and how much extra waiting time is then actually introduced when the
pre-amble info is sent inside the RAMS burst as retransmission packets? When
sending MPEG2 TS preamble info as retransmission packets, isn't that one
processing step less at the RS side as well, compared to the solutions in
the two pre-amble drafts?

Frank=>If the preamble information resides at the end of RAMS, there is
little performance improvement.

IMHO, your idea is similar to ours, and only difference is we pack preamble
info in the beginning of retransmission

while you leave them dispersed in the burst.

Tom

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 18 Mar 2010 10:59:26 -0500

I would say that the fundamental difference is that the Xia draft assumes that a compact MPEG2TS burst that "primes the pump" for demuxing/decrypting/decoding can be generated on the server. In this scheme, the clients would simply jam the bitstream into the normal demux/decrypt/decode path as if it were received from the network. The Begen draft assumes that each client will have to take the "prime the pump" data and send it into the demux/decrypt/decode path with explicit knowledge of the actual device in use. If there is a single bitstream that will work, it makes sense to generate that bitstream on the server and we should do the detailed engineering to make it happen. If there is not a single bitstream that will work, we should send the data to the clients and they should build the bitstream. 

In this note, I contend that the latter is correct.

As a thought exercise, let's assume that there ACTUALLY IS a very short sequence of data that one could feed into every demux/decryptor/decoder in a given network. It seems pretty clear to me that the network operator would be sending this short burst of data every 100ms or so, and this whole discussion would be mute. 

Moving past that simple thought experiment, it is helpful to look at the real world deployment experience to see what is actually on the network. When you look at actual digital video deployments, you will find that each element of the SI is sent periodically, with a certain amount of time between SI elements. Entitlements are also interleaved, with a certain amount of time between the SI elements and the entitlement messages. This is on purpose, and is done because end devices need time to set up each element in the demux/decrypt/decode chain. If you were to send all of the data at once to a naïve device, it would actually take longer to start displaying video because it would take multiple passes through the data. 

So, how do existing systems do channel change? This is part science and part art. Low end devices simply take the data and send it into the demux/decrypt/decode chain as it comes in. On these devices, you get the performance that you get and move along. Other devices parse the data on the network and try to optimize. They find the various elements and save them off, then jam them into the hardware intelligently. Each devices timing is different. Certain devices actually need to have data between the various components, not just time. You end up having to stuff NULL MPEG packets into such devices to get them to process the SI/ECMs. 

When you start peeling this onion, you find that these timing constrains are just the first layer. There are also device-specific considerations when you look at clocks and continuity counters. When you manipulate the data to satisfy these device setup requirements, you find that each device handles PCR/PTS/DTS clock shifts and MPEG continuity counter changes differently. You also need to consider when to insert the EMM data, particularly in simulcrypt/multi-CAS systems. Art and Sandy brought up some detailed examples, which I will not repeat here. 

In summary, the assumption that a short MPEG2TS bitstream can be used to "prime the pump" is simply not correct. The MPEG2 specification does not specify such a bitstream, so this is not a surprise. Given this fact, trying to build a generic acceleration stream on the server is simply the wrong approach.

If this analysis is wrong, show me an implementation that uses such a bitstream. Show it working on a multi-vendor, simulcrypt enabled system. I will gladly endorse such a proposal, as it will clearly be superior to the Begin proposal.

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C. Begen (abegen)
Sent: Thursday, March 18, 2010 9:19 AM
To: Dave Oran (oran)
Cc: VAN CAENEGEM Tom; [email-masked]
Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms

 

Also agree.
 
...

... 
when you got the RFC2250

Yup.
 
in the stream.

Yup.
 
...

-acbegen

---

From: Peilin YANG <[email-masked]>
Date: Fri, 19 Mar 2010 08:22:41 +0800

Hi Tom, 

Your questions and comments are very good. I compared the processing steps of two solutions as follows based on your comments. You can find easily the difference of two solution.

           Begen draft                                    |           Xia draft               
The steps of RS                                           |The steps of RS
Step1: RS detects the preamble information                |  RS detects the preamble information(The same as Bege draft)
Step2: RS extracts this specific data                     |  None
Step3: RS puts these in the TOLV elements                 |  None
Step4: RS packages them together in RTP packets           |  RS brings these TS packets together in RTP packets (RFC2250)
Step5: RS transmits these to the receiver                 |  RS transmits these to the receiver(The same as Bege draft)
                                                          |
The steps of RR                                           |The steps of RR
Step6: RR extracts the preamble data from TOLV elements   |  None
Step7: RR generates again a sequence of MPEG2 TS packets  |  None
Step8: RR place theses to the demux/decoder               |  RR places these to the demux/decoder(The same as Bege draft)

Peilin

----- 原邮件 -----
发件人: VAN CAENEGEM Tom <[email-masked]>
日期: 星期四, 三月 18日, 2010 上午7:07
主题: [AVT]  MPEG2 preamble - comparison of mechanisms
收件人: [email-masked]

Hi,
 
I would like to understand better the difference in processing required at the RS side and at the RTP receiver side in the two solutions. Because  I understand from the mailing list discussions there is a difference in scalability as a result of the different ways the preamble is transported between RS and receiver in the respective drafts:
 
Xia draft: RS needs to detect where the pre-amble information is in the SSM (which TS packets in which RTP packets in the recently cached data contain MPEG2 TS preamble data),  brings together these TS packets in separate RTP packets ( RFC2250) and transmits these to the receiver. The RTP receiver needs to understand these are the preamble MPEG2 TS packets.
 
Begen draft: RS needs to detect where the pre-amble information is in the SSM, needs to extract this specific data, put these in the TOLV elements, and packages them together in RTP packets. The RTP receiver -as indicated in the section 7 of the draft, extracts the pre-amble data and generates again a sequence of MPEG2 TS packets.

It is not 100% clear to me 
-what is the implied difference for receiver side processing among the two solutions (Which one requires more processing power?)
-which solution can be better "customised"? (Not sure this a differentiator to be concerned with?)
-which solution has more impact at the server side (And hence is not as scalable compared to the other approach)
 
Another question: taking into account the min/max frequency of the appearance of MPEG 2 TS preamble info inside a compliant MPEG2TS stream, how much time is actually saved compared to sending a RAMS burst -only?  I know this is not impacted in a different way by the two solutions (unless I have missed something here), but I think it is worthwhile to provide a figure like this to justify better the need of sending MPEG2 TS preamble info in d
edicated packets prior to the burst.
 
.. and how much extra waiting time is then actually introduced when the pre-amble info is sent inside the RAMS burst as retransmission packets? When sending MPEG2 TS preamble info as retransmission packets, isn't that one processing step less at the RS side as well, compared to the solutions in the two pre-amble drafts?
 
Tom

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Thu, 18 Mar 2010 18:29:27 -0700

Hello Peilin and Frank,

I have a question for understanding the Xia draft.

Does it include a mechanism for specifying the relative timing at which the individual preamble TS packets should be fed to the receiver's (or decoder') TS demultiplexer?

If yes, what is that mechanism?

If not, how does it ensure that the preamble packets arrive at the demultiplexer with timing that will produce the desired results?

Sorry if this info is in the draft, I looked quickly and did not see it yet.

While I don't have anything against sending TS packets for a RAMS preamble, Bill Ver Steeg and others have raised some valid points about the importance of controlling the timing with which they are fed to the decoder's TS demultiplexer in order to obtain the desired results.

Or, do you believe that this just isn't required for the IETF preamble solution?

Perhaps this group should be debating the requirements now, and then choose the solution(s)?

--Sandy MacInnis

---

From: Roni Even <[email-masked]>
Date: Fri, 19 Mar 2010 04:48:11 +0200

Hi Sandy,
I think that the issue of timing when feeding data to the decoder
demultiplexer is not only a preamble issue. At least this is what Ali, Dave
and Bill are saying. In this case it is a separate issue that need
mentioning but if there is a requirement to address it then it is targeted
to the general receiver and not only to the preamble part.

I think you mentioned that the receiver optimization is a secret sauce, in
which case there is no reason to define mechanism but only to mention 

BTW: a mechanism may be, do nothing and synchronize later like you said.

Roni Even
As individual

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sandy (Alexander) MacInnis
> Sent: Friday, March 19, 2010 3:29 AM
> To: Peilin YANG; Frank Xia
> Cc: [email-masked]
> Does it include a mechanism for specifying the relative timing at which
> the individual preamble TS packets should be fed to the receiver's (or
> decoder') TS demultiplexer?
> 
> If not, how does it ensure that the preamble packets arrive at the
> demultiplexer with timing that will produce the desired results?
> 
> While I don't have anything against sending TS packets for a RAMS
> preamble, Bill Ver Steeg and others have raised some valid points about
> the importance of controlling the timing with which they are fed to the
> decoder's TS demultiplexer in order to obtain the desired results.
>

---

From: Peilin YANG <[email-masked]>
Date: Fri, 19 Mar 2010 12:09:57 +0800

Hi Sandy,

The mechnisim is very simple.

Firstly, RS transmits the preamble TS packets to a RTP receiver before unicast burst. Then when the RTP receiver receive the preamble TS packets, it immediately remove the RTP header and feed them to the TS demultiplexer.
I don't know if I explain it clearly.

Best regards,

Peilin

----- 原邮件 -----
发件人: "Sandy (Alexander) MacInnis" <[email-masked]>
日期: 星期五, 三月 19日, 2010 上午9:27
主题: RE: [AVT] MPEG2 preamble - comparison of mechanisms
收件人: Peilin YANG <[email-masked]>, Frank Xia <[email-masked]>
抄送: "[email-masked]" <[email-masked]>

Hello Peilin and Frank,

--Sandy MacInnis

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Thu, 18 Mar 2010 22:04:13 -0700

The answer seems to be "no", as in, it does not include a mechanism for specifying relative timing at which individual preamble TS packets should be fed to the receiver's TS demultiplexer.

The mechanism of immediately removing the RTP header and feeding the TS packets to the TS demultiplexer is the opposite of specifying the relative timing.

--Sandy

-----Original Message-----
From: Peilin YANG [mailto:[email-masked]] 
Sent: Thursday, March 18, 2010 9:10 PM
To: Sandy (Alexander) MacInnis
Cc: Frank Xia; [email-masked]
Subject: RE: [AVT] MPEG2 preamble - comparison of mechanisms

Hi Sandy,

Best regards,

Peilin

----- 原邮件 -----
发件人: "Sandy (Alexander) MacInnis" <[email-masked]>
日期: 星期五, 三月 19日, 2010 上午9:27
主题: RE: [AVT] MPEG2 preamble - comparison of mechanisms
收件人: Peilin YANG <[email-masked]>, Frank Xia <[email-masked]>
抄送: "[email-masked]" <[email-masked]>

Hello Peilin and Frank,

--Sandy MacInnis

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 19 Mar 2010 11:30:02 -0700

Roni Even
> Sent: Thursday, March 18, 2010 7:48 PM
> To: 'Sandy (Alexander) MacInnis'; 'Peilin YANG'; 'Frank Xia'
> Cc: [email-masked]

The mpeg2ts spec defines certain rules/requirements. This is not our
place to put new limits, reqs, etc. into that spec, which was produced
some time ago.

But, here at AVT, we are defining "preamble information" for faster
acquisition. We cannot mandate a single way of creating the *best -
optimal - fastest - or whatever* preamble since there is no such thing
that works in every case. But, we should acknowledge this issue and
create a payload format that allows any implementation to achieve
creating the best preamble.

-acbegen

> > Sorry if this info is in the draft, I looked quickly and did not see
it
> > yet.
> > Or, do you believe that this just isn't required for the IETF
preamble
> > solution?