Subject: Re: [AVT] Preamble follow-up

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 8 Apr 2010 09:13:15 -0700

Peilin, Frank and Xingfen,

I sent the email below during the IETF week. Unless I missed it, I still have not received a concrete answer from any of you to the very basic question that:

	Whether you agree or not that post processing of the preamble information is always required. I claim it is required regardless of whether we use TLVs or regular TS packets to carry the preamble. Post processing makes sure that the PCRs, CCs are correct and in-order as well as the demux/decoder can be initialized with the right encryption keys, which is crucial in encrypted streams.

We revised our draft today and I hope the additional text (a summary of the long thread we had earlier in the list) will help you understand our reasoning.

Your timely response to this question is important for us to move forward in this topic. So, please let us know what your answer is.

Thanks,
-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C. Begen (abegen)
> Sent: Thursday, March 25, 2010 1:59 PM
> To: [email-masked]
> Subject: [AVT] Preamble follow-up
> 
> The information that goes into the preamble package comes from various places in the transport stream.
> Some part of that information shows up more frequently than others. The EMM elements, for example, may
> have showed up in the transport stream several seconds ago and they need to be cached by the server to
> be included later in the preamble. When multiple elements are extracted out of the transport stream
> and then sent to the other side in a preamble package, it is very clear that certain information needs
> to be rearranged (such as the PCR and CC values) so the TS packets fed into the demux/decoder are
> compliant and will not upset the device.
> 
> In our approach, we make sure this happens by a process called "post processing" on the receiver side
> (still in the RTP plane). It addresses the issues around TS compliancy as well as the device-specific
> requirements (which is as critical as being compliant, too). The necessity of this step has been
> voiced by not only myself but many others who have been working in this area for much longer than I
> have.
> 
> However, in yesterday's discussion, it was not still clear whether the co-authors of the Xia draft
> agreed that post processing was always needed or not. Actually, the answers I got from different co-
> authors were even more confusing.
> 
> Before I can call the current disagreement as only a packaging issue, I want to hear a *firm* response
> from the Xia co-authors. Please state whether you agree that post processing is required or not. You
> might be willing to do the processing on the server side (meaning that you modify the TS packets
> before you ship them). If that is the case, state that clearly as well.
> 
> When the stand of both sides is clear on this issue (and ours has been crystal clear since day 1), we
> can discuss whether using the regular TS packets or a TLV-based packaging is better, more scalable,
> etc. At this point, I will state it clearly again and say that TLV parsing support is already needed
> to make RAMS work and provides easier post processing. It also provides flexibility to the server to
> include stuff that was not in the TS stream within the preamble. Such information could be service-
> specific stuff that was provided to the server out-of-bands. We shared our open source code and can
> provide preamble examples who would like to see them.
> 
> As the Xia draft currently stands, I respectfully disagree that it generates compliant TS packets and
> the generated preamble will work on any compliant decoder. We probably do not need to run a full-scale
> compliancy test, etc. but we would like to see the code for the Xia draft or preamble examples it
> generates.
> 
> Finally, I am hoping that AVT will reach a consensus sooner rather than later. Since Hiroshima, we
> have been discussing pretty much the same things w/o making progress.
> 
> Cheers, acbegen.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Frank Xia <[email-masked]>
Date: Thu, 08 Apr 2010 11:45:02 -0500

Hi Ali

Personally, I would like to  stop reiterating
this kind of question. If you are not clear,
you can refer to the long discussion. Please
also read the summary slides in the IETF meeting,
it is clear.

As the follow-up of the IETF meeting, we will
post bit stream requested by the community.

Please do your part too.

BR
Frank.

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 11:13 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [AVT] Preamble follow-up

I sent the email below during the IETF week. Unless I missed it, I still
have not received a concrete answer from any of you to the very basic
question that:

	Whether you agree or not that post processing of the preamble
information is always required. I claim it is required regardless of whether
we use TLVs or regular TS packets to carry the preamble. Post processing
makes sure that the PCRs, CCs are correct and in-order as well as the
demux/decoder can be initialized with the right encryption keys, which is
crucial in encrypted streams.

We revised our draft today and I hope the additional text (a summary of the
long thread we had earlier in the list) will help you understand our
reasoning.

Your timely response to this question is important for us to move forward in
this topic. So, please let us know what your answer is.

Thanks,
-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 8 Apr 2010 10:00:50 -0700

I respectfully disagree. The answers I got from Peilin and you were not consistent and so far you occasionally (again not firmly) said the post processing was not within the scope of your draft. Well, I believe this is within the scope because it may affect how the WG will proceed. That is why I am repeating my question.

If you do not want to cover these issues and simply say you use a payload format that was defined years ago as it is, why would you need a draft in the first place? What I am saying is that unless you fix your TS packets one way or another, feeding them directly to the demux will fail; i.e., it won’t bring the advantages you were expecting. Using TS packets (rather than tlvs or whatever) does not save you from post-processing/fixing them. You claim your method works for both regular and encrypted streams on different chipsets. You need to explain this.

We cannot leave this discussion on the floor. So, let's work towards a productive discussion.

-acbegen

> From: Frank Xia [mailto:[email-masked]]
> Sent: Thursday, April 08, 2010 12:45 PM
> To: Ali C. Begen (abegen); [email-masked]; [email-masked]; [email-masked]

---

From: Roni Even <[email-masked]>
Date: Thu, 08 Apr 2010 20:30:32 +0300

Ali,
To be productive, look at the first bullet in slide 5 of the mpeg2ts
presentation. This summarizes the mailing list discussion on the topic and
did not cause anyone to go to the mic and disagree.

"Begen et. Al. stress that irrespective of the preamble transport method,
there must be post-processing done by any receiver design, as existing TS
demuxing/decoding logic in most cases will not respond in a desired way to a
burst of condensed MPEG2 TS preamble info
This was initially contested by Xia et al, but the Xia draft does not
preclude such post processing"

And I can see from Frank response that you will receive an example of a
stream that works with no post procressing

Roni Even
As Individual

> Sent: Thursday, April 08, 2010 8:01 PM
> To: Frank Xia; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [AVT] Preamble follow-up
> 
> I respectfully disagree. The answers I got from Peilin and you were not
> consistent and so far you occasionally (again not firmly) said the post
> processing was not within the scope of your draft. Well, I believe this
> is within the scope because it may affect how the WG will proceed. That
> is why I am repeating my question.
> 
> If you do not want to cover these issues and simply say you use a
> payload format that was defined years ago as it is, why would you need
> a draft in the first place? What I am saying is that unless you fix
> your TS packets one way or another, feeding them directly to the demux
> will fail; i.e., it won't bring the advantages you were expecting.
> Using TS packets (rather than tlvs or whatever) does not save you from
> post-processing/fixing them. You claim your method works for both
> regular and encrypted streams on different chipsets. You need to
> explain this.
> 
> > > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ali
> > C. Begen (abegen)
> > > The information that goes into the preamble package comes from
> various
> > places in the transport stream.
> > > Some part of that information shows up more frequently than others.
> The
> > EMM elements, for example, may
> > > have showed up in the transport stream several seconds ago and they
> need
> > to be cached by the server to
> > > be included later in the preamble. When multiple elements are
> extracted
> > out of the transport stream
> > > and then sent to the other side in a preamble package, it is very
> clear
> > that certain information needs
> > > to be rearranged (such as the PCR and CC values) so the TS packets
> fed
> > into the demux/decoder are
> > > In our approach, we make sure this happens by a process called
> "post
> > processing" on the receiver side
> > > (still in the RTP plane). It addresses the issues around TS
> compliancy as
> > well as the device-specific
> > > requirements (which is as critical as being compliant, too). The
> necessity
> > of this step has been
> > > voiced by not only myself but many others who have been working in
> this
> > area for much longer than I
> > > have.
> > >
> > > However, in yesterday's discussion, it was not still clear whether
> the
> > co-authors of the Xia draft
> > > Before I can call the current disagreement as only a packaging
> issue, I
> > want to hear a *firm* response
> > > might be willing to do the processing on the server side (meaning
> that you
> > modify the TS packets
> > > When the stand of both sides is clear on this issue (and ours has
> been
> > crystal clear since day 1), we
> > > can discuss whether using the regular TS packets or a TLV-based
> packaging
> > is better, more scalable,
> > > etc. At this point, I will state it clearly again and say that TLV
> parsing
> > support is already needed
> > > to make RAMS work and provides easier post processing. It also
> provides
> > flexibility to the server to
> > > include stuff that was not in the TS stream within the preamble.
> Such
> > information could be service-
> > > specific stuff that was provided to the server out-of-bands. We
> shared our
> > open source code and can
> > > the generated preamble will work on any compliant decoder. We
> probably do
> > not need to run a full-scale
> > > compliancy test, etc. but we would like to see the code for the Xia
> draft
> > or preamble examples it
> > > generates.
> > >
> > > Finally, I am hoping that AVT will reach a consensus sooner rather
> than
> > later. Since Hiroshima, we

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 8 Apr 2010 10:54:20 -0700

> stream that works with no post procressing

A working stream can of course be found. If the TS packets carrying the preamble including the encryption keys are aligned in a way that they don't cause a discontinuity and they are perfectly aligned in the order the decoder would want them to be, that will work.

But, I wonder whether that has a chance of 1% or 0.1%. If we took this issue away from the discussion/draft, it will look like it is not an issue in practice. Would not it be misleading? Would not we then be doing a disservice?

-acbegen

---

From: Roni Even <[email-masked]>
Date: Thu, 08 Apr 2010 23:13:11 +0300

Hi Ali,
So let me see if I understand, now you agree that post processing is not
always needed and discussing the cases and what percentage this cases cover?
Roni Even
As individual

> Sent: Thursday, April 08, 2010 8:54 PM
> To: Roni Even; Frank Xia; [email-masked]; [email-masked];
> [email-masked]
> A working stream can of course be found. If the TS packets carrying the
> preamble including the encryption keys are aligned in a way that they
> don't cause a discontinuity and they are perfectly aligned in the order
> the decoder would want them to be, that will work.
> 
> But, I wonder whether that has a chance of 1% or 0.1%. If we took this
> issue away from the discussion/draft, it will look like it is not an
> issue in practice. Would not it be misleading? Would not we then be
> doing a disservice?
> 
> -acbegen
> 
> > Roni Even
> > As Individual

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 8 Apr 2010 13:44:46 -0700

I acknowledge that exceptions may occur in theory, but I don't think we can consider them practical. So I do think post processing is *always* necessary to make sure that decoder will not get upset and discard the data, which will clear all the advantages the RAMS will provide.

And for the record, I said something along the same lines on the mic as a response to Tom's (Taylor) comment towards the end of the session. He said he thought this was merely a packaging discussion and I said I disagreed. 

-acbegen

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, April 08, 2010 4:13 PM
> To: Ali C. Begen (abegen); 'Frank Xia'; [email-masked]; [email-masked]; [email-masked]

---

From: Tom Taylor <[email-masked]>
Date: Fri, 09 Apr 2010 11:49:45 -0400

The reason I said it was merely a packaging discussion is because I for one am 
convinced that post-processing is needed most of the time. Hence the only 
difference between the two drafts is how the content is packaged.

---

From: David R Oran <[email-masked]>
Date: Fri, 9 Apr 2010 14:05:32 -0400

On Apr 9, 2010, at 11:49 AM, Tom Taylor wrote:

> The reason I said it was merely a packaging discussion is because I for one am convinced that post-processing is needed most of the time. Hence the only difference between the two drafts is how the content is packaged.
> 
What this continues to come down to is which packaging makes more sense under what assumptions. A raw rfc2250/mpeg2ts packaging is undeniably simpler if you can just cram it into the decoder like any other part of an rfc2250 stream. The authors of that approach clearly believe that we should optimize for the no-postprocessing environment.

The authors of the TOLV-based draft clearly believe that since post-processing is almost always needed, the TOLV is a more "neutral" encoding, with fewer assumptions and restrictions imposed from a rfc2250/mpeg2ts compliant payload format. Based on the open-source code that was posted, one can pretty easily judge for oneself if that is the case (the code also contains the API-infrastructure for interacting with the decoder based on the TOLV payloads).

DaveO.

>> And for the record, I said something along the same lines on the mic as a response to Tom's (Taylor) comment towards the end of the session. He said he thought this was merely a packaging discussion and I said I disagreed. -acbegen

---

From: Roni Even <[email-masked]>
Date: Fri, 09 Apr 2010 21:55:39 +0300

Hi,
My understanding is that the begen draft takes an MPEG2-TS stream in the RS
and breaks it to a couple of TOLVs structure, it can be more than one for an
element.
On the receiver side it creates an MPEG2-TS stream from the TOLV and feed it
to the multiplexer. (I saw that there is a possible optimization that tries
to feed the specific registers in the decoder but this requires such
capability and is not the general case). 
Building the MPEG2-TS on the receiver from TOLV is not an optimization to
having an MPEG2-TS in the receiver that may be fed directly or if not can be
fixed.
Roni Even

> From: David R Oran [mailto:[email-masked]]
> Sent: Friday, April 09, 2010 9:06 PM
> To: Tom Taylor
> Cc: Ali C. Begen (abegen); Roni Even; [email-masked]
> > The reason I said it was merely a packaging discussion is because I
> for one am convinced that post-processing is needed most of the time.
> Hence the only difference between the two drafts is how the content is
> packaged.
> >
> What this continues to come down to is which packaging makes more sense
> under what assumptions. A raw rfc2250/mpeg2ts packaging is undeniably
> simpler if you can just cram it into the decoder like any other part of
> an rfc2250 stream. The authors of that approach clearly believe that we
> should optimize for the no-postprocessing environment.
> 
> The authors of the TOLV-based draft clearly believe that since post-
> processing is almost always needed, the TOLV is a more "neutral"
> encoding, with fewer assumptions and restrictions imposed from a
> rfc2250/mpeg2ts compliant payload format. Based on the open-source code
> that was posted, one can pretty easily judge for oneself if that is the
> case (the code also contains the API-infrastructure for interacting
> with the decoder based on the TOLV payloads).
> 
> DaveO.
> 
> >> I acknowledge that exceptions may occur in theory, but I don't think
> we can consider them practical. So I do think post processing is
> *always* necessary to make sure that decoder will not get upset and
> discard the data, which will clear all the advantages the RAMS will
> provide.
> >> And for the record, I said something along the same lines on the mic
> as a response to Tom's (Taylor) comment towards the end of the session.
> He said he thought this was merely a packaging discussion and I said I
> disagreed. -acbegen
> >>> To: Ali C. Begen (abegen); 'Frank Xia'; [email-masked];
> [email-masked]; [email-masked]
> Of
> >>>> Ali C. Begen (abegen)
> >>>>> And I can see from Frank response that you will receive an
> example of
> >>>> a

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 9 Apr 2010 12:50:45 -0700

> having an MPEG2-TS in the receiver that may be fed directly or if not can be

When you do post processing on TS packets rather than TLVs, you need TS parsing logic on the client. Are you claiming that is easier than TLV parsing? Remember TLV parsing is required anyway to run RAMS on the client.

-acbegen

---

From: David R Oran <[email-masked]>
Date: Fri, 9 Apr 2010 16:04:06 -0400

> When you do post processing on TS packets rather than TLVs, you need TS parsing logic on the client. Are you claiming that is easier than TLV parsing? Remember TLV parsing is required anyway to run…
I think the claim is it's easier to diddle a mpeg2ts encoding to correct the things that need fixing and feed it to the decoder in the right timing than it is to create one from the TLVs.

I can see the logic of that, but the code in the open source archive for constructing the TS from the TLVs is a very small part of the RAMS client to begin with, and not a lot in absolute terms either.

---

From: Roni Even <[email-masked]>
Date: Sat, 10 Apr 2010 01:13:43 +0300

Hi Dave,
This is what I meant (about diddle a mpeg2ts encoding) and I agree with you
that in both cases the processing overhead is small (I also think that
actual products are using a jitter buffer on the burst so the processing of
the burst stream is not starting when the burst is received). That led to my
view that there is no major difference between the two solutions except for
the packaging and I think this is what Tom Taylor was trying to say. 

In terms of general overhead the preamble will be in most cases one packet
while the RAMS burst is a couple of seconds and may include hundreds of
packets.

This was, in my view, the reason why some people suggested that since both
solutions work in shipping products it will be easier to endorse both and
decide which side (RS or RTP_Rx) will need to support both for
interoperability.

Roni Even
As individual

> Sent: Friday, April 09, 2010 11:04 PM
> To: Ali C. Begen (abegen)
> Cc: Roni Even; Tom Taylor; [email-masked]
> > When you do post processing on TS packets rather than TLVs, you need
> TS parsing logic on the client. Are you claiming that is easier than
> TLV parsing? Remember TLV parsing is required anyway to run RAMS on the
> client.
> >
> I think the claim is it's easier to diddle a mpeg2ts encoding to
> correct the things that need fixing and feed it to the decoder in the
> right timing than it is to create one from the TLVs.
> 
> I can see the logic of that, but the code in the open source archive
> for constructing the TS from the TLVs is a very small part of the RAMS
> client to begin with, and not a lot in absolute terms either.
> 
> > -acbegen
> >
> >> Roni Even

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 12 Apr 2010 20:31:00 -0700

A question for RTP gurus out there.

Is it indeed OK to carry something different than what is intended in a particular payload format? RFC 2250 defines the payload format for normal, compliant TS streams. The preamble data (which is a set of TS packets extracted from various places in a TS stream) does not really qualify for that IMO, and deserves to be carried in a separate payload format.

Looking at the SDP, a client will simply see that it is an 2250-formatted stream, whereas it is actually not (i.e., it cannot consume those TS packets as they are since they will require post processing). I am well aware that preamble is a special case (say it is a summary of a transport stream), but I believe it still deserves a different payload format and that is the correct way of implementing this. 

If one only cares about the packaging aspects of the preamble yet still uses an existing payload format, I don't see the need for writing a spec for it. What is there to define?

Insights are welcome.
-acbegen

> From: Dave Oran (oran)
> Sent: Friday, April 09, 2010 4:04 PM
> > When you do post processing on TS packets rather than TLVs, you need TS parsing logic on the client.
> Are you claiming that is easier than TLV parsing? Remember TLV parsing is required anyway to run RAMS
> on the client.
> >
> I think the claim is it's easier to diddle a mpeg2ts encoding to correct the things that need fixing
> and feed it to the decoder in the right timing than it is to create one from the TLVs.
> 
> I can see the logic of that, but the code in the open source archive for constructing the TS from the
> TLVs is a very small part of the RAMS client to begin with, and not a lot in absolute terms either.
> 
> > -acbegen
> >
> >> Roni Even

---

From: Roni Even <[email-masked]>
Date: Tue, 13 Apr 2010 08:43:21 +0300

Hi,
I believe that this question was answered before. This question starts with
an assumption that was addressed before about what is a valid MPEG2-TS
stream.

I think there is a confusion between a valid MPEG2-TS stream and required
post processing if needed. The payload sent in the preamble in Xia draft is
a valid MPEG2-TS transport stream according to ISO 13818-1 (ITU-t H.222.0).
A system reference decoder will process this stream. The proof is that there
are MPEG2-TS de-multiplexer and decoders that do not require post
processing.
Any post processing that may happen is to compensate on issues with specific
implementations. This post processing may be needed or not at all.

Roni Even

> Sent: Tuesday, April 13, 2010 6:31 AM
> To: Dave Oran (oran)
> Is it indeed OK to carry something different than what is intended in a
> particular payload format? RFC 2250 defines the payload format for
> normal, compliant TS streams. The preamble data (which is a set of TS
> packets extracted from various places in a TS stream) does not really
> qualify for that IMO, and deserves to be carried in a separate payload
> format.
> 
> Looking at the SDP, a client will simply see that it is an 2250-
> formatted stream, whereas it is actually not (i.e., it cannot consume
> those TS packets as they are since they will require post processing).
> I am well aware that preamble is a special case (say it is a summary of
> a transport stream), but I believe it still deserves a different
> payload format and that is the correct way of implementing this.
> 
> If one only cares about the packaging aspects of the preamble yet still
> uses an existing payload format, I don't see the need for writing a
> spec for it. What is there to define?
> 
> Insights are welcome.
> -acbegen
> 
> correct the things that need fixing
> for constructing the TS from the

---

From: Roni Even <[email-masked]>
Date: Tue, 13 Apr 2010 08:53:41 +0300

Hi Ali,
BTW: if you look at the SDP in the draft
		m=video 41002 RTP/AVPF 99 100
           i=Unicast Retransmission Stream + Preamble Data
           c=IN IP4 192.0.2.1
           a=rtpmap:99 rtx/90000
           a=rtcp:41003
           a=fmtp:99 apt=98; rtx-time=5000
           a=preamble 100
           a=rtpmap:100 MP2T/90000
           a=mid:4

You will see that there is a new attribute that identify PT 100 as preamble
to let the receiver know that this is the preamble that is part of the burst
and not a separate MPEG2-TS stream. Still the data itself is a valid
MPEG2-TS stream

Roni Even

---

From: Peilin YANG <[email-masked]>
Date: Tue, 13 Apr 2010 17:21:37 +0800

Dear Ali & Bill,

We upload a preamble bitstream at the following link. You can get it.
http://www-etud.iro.umontreal.ca/~sarikaya/drafts/MPEG2-TS preamble.pcap

In fact, I am not still clear how many post processing there are in the Begen draft. Yet I summarize the post processing from the Begen draft and mailing list.
Besides the following post processing, do you have other post processing? 

1. Convert TOLVs to TS packets
2. Ensure correct CCs of preamble TS packets(especial for PCR)
3. Ensure in-order preamble TS packets.

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期五, 四月 9日, 2010 上午0:13
主题: RE: [AVT] Preamble follow-up
收件人: [email-masked], [email-masked], [email-masked], [email-masked]

Thanks,
-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 13 Apr 2010 03:58:32 -0700

> Sent: Tuesday, April 13, 2010 1:43 AM
> To: Ali C. Begen (abegen); Dave Oran (oran)
> Cc: 'Tom Taylor'; [email-masked]

We keep coming back to the same question. You say there is proof and I say exceptions cannot be proofs and AFAICT this is an exception unless you fix the TS packets before you send them from the server. That is, you may prefer not doing the post processing on the client side but you do it on the server side. If that is the case, my question becomes irrelevant and we can start discussing the pros/cons of server-side and client-side post processing. But, I believe you still claim post processing is not required at all. 

At least two seasoned MPEG folks already mentioned in the list that preamble TS packets had to be fixed (post processed).

> implementations. This post processing may be needed or not at all.

See above. It is not to address some specific implementations.

Regarding the "a=preamble 100" line, I suppose it will be defined at some point, but even if it is defined, an rtp receiver that does not understand that attribute will skip it and think that those packets are regular 2250-formatted packets (from the rtpmap line). And as I asked in my email below, it will be incorrect since now there is something different than the regular 2250 payload. 

E.g., would it be OK if I modified the order of audio frames in a PCM packet? I guess not.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Tue, 13 Apr 2010 15:01:27 +0300

Ali,
I believe this will continue forever since we are not talking about the same
thing.
The stream on the wire that includes PAT, PMT, and may include PCR and ECM
in the preamble is a valid stream according to ISO 13818-1 (ITU-t H.222.0).
There are no specific requirements for the stream on the wire. This is why
the stream sent in the RTP is valid. 

The post processing has nothing to do with the question you asked since you
asked about what is going over the wire. 

As for cases where you do not need post processing I think Peilin sent a
link to one that was captured by a customer.

Roni Even

> Sent: Tuesday, April 13, 2010 1:59 PM
> To: Roni Even; Dave Oran (oran)
> Cc: Tom Taylor; [email-masked]
> We keep coming back to the same question. You say there is proof and I
> say exceptions cannot be proofs and AFAICT this is an exception unless
> you fix the TS packets before you send them from the server. That is,
> you may prefer not doing the post processing on the client side but you
> do it on the server side. If that is the case, my question becomes
> irrelevant and we can start discussing the pros/cons of server-side and
> client-side post processing. But, I believe you still claim post
> processing is not required at all.
> 
> At least two seasoned MPEG folks already mentioned in the list that
> preamble TS packets had to be fixed (post processed).
> 
> Regarding the "a=preamble 100" line, I suppose it will be defined at
> some point, but even if it is defined, an rtp receiver that does not
> understand that attribute will skip it and think that those packets are
> regular 2250-formatted packets (from the rtpmap line). And as I asked
> in my email below, it will be incorrect since now there is something
> different than the regular 2250 payload.
> 
> > > > >> having an MPEG2-TS in the receiver that may be fed directly or
> if
> > > not can be
> > > > >> fixed.
> > > > >
> > > > and feed it to the decoder in the right timing than it is to
> create
> > > one from the TLVs.
> > > >
> > > > TLVs is a very small part of the RAMS client to begin with, and
> not a
> > > lot in absolute terms either.
> > > >
> > > > > -acbegen
> > > > >
> > > > >> Roni Even

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 13 Apr 2010 05:22:55 -0700

I suppose the ISO/ITU spec was not considering that someone would mess with the order/timing of TS packets at the time it was developed. Remember that it was developed long time ago for almost perfect broadcast environments. It defined the nature of a standard decoder.

When we create a special stream such as preamble, I do think this becomes a concern even from the bit-on-the-wire viewpoint unless the stream is fixed before it is consumed. Since you claim that no fixing is necessary, I still see it as a concern. The preamble introduces a problem that has not been foreseen before so caution needs to be in place to take care of that problem.

-acbegen

> Sent: Tuesday, April 13, 2010 8:01 AM

---

From: Tom Taylor <[email-masked]>
Date: Tue, 13 Apr 2010 09:43:18 -0400

The post-processing is a spurious issue here. I believe the point made in 
earlier discussion was that a number of receivers on the market cannot cope with 
RFC 2250-compliant streams without special handling of the preamble, however it 
is packaged.

The real test of whether the result of manipulating the preamble packets at the 
server generates output that belongs in the original payload is whether a 
totally 2250-compliant receiver could handle the stream without any problems. I 
will let the experts give their view on that one.

Ali C. Begen (abegen) wrote:
> particular payload format? RFC 2250 defines the payload format for normal,
> compliant TS streams. The preamble data (which is a set of TS packets
> extracted from various places in a TS stream) does not really qualify for
> that IMO, and deserves to be carried in a separate payload format.
> 
> Looking at the SDP, a client will simply see that it is an 2250-formatted
> stream, whereas it is actually not (i.e., it cannot consume those TS packets
> as they are since they will require post processing). I am well aware that
> preamble is a special case (say it is a summary of a transport stream), but I
> believe it still deserves a different payload format and that is the correct
> way of implementing this.
> 
> If one only cares about the packaging aspects of the preamble yet still uses
> an existing payload format, I don't see the need for writing a spec for it.
> What is there to define?
> 
> Insights are welcome. -acbegen
> 
> ...

---

From: Roni Even <[email-masked]>
Date: Tue, 13 Apr 2010 18:40:35 +0300

Hi Ali,
I will try to answer your question inline, maybe I was not clear in my
previous response.

Roni

> normal, compliant TS streams. 

Roni: The preamble stream is compliant according to ISO 13818-1 (ITU-t
H.222.0). If you believe this is not true please point at the text in the
standard. The latest version of H.222.0 is from 2005, not that old!!! 

The preamble data (which is a set of TS
> payload format and that is the correct way of implementing this.

Roni: In order to help the receiver the SDP includes the attribute
a=preamble PT. If the receiver do not understand preamble (the attribute in
Xia draft or the mpeg2-ts-preamble payload in begen draft)
1. In the case of begen draft, it will not process the TOLVs and will wait
for the PAT, PMT,... in the burst or the following multicast stream
2. In the case of xia draft, it may ignore the mpeg2-ts since it expect only
to get retransmission according to base RAMS draft, this is similar to begen
case. It may decide to try to use the mpeg2-ts and feed it to the
demultiplexer in which case it may work in the cases that xia draft claims
work. The behavior can be specified in the RAMS draft.
3. If we adopt two solutions we will need to define the requirements for
supporting preamble on the receiver. It can be by sending preamble support
flag in RAMS-R. BTW: this will address the concerns in the first and second
case.

---

From: Peilin YANG <[email-masked]>
Date: Wed, 14 Apr 2010 13:47:23 +0800

Hi,

I am sorry I forgot to explain this bitstream.

The preamble RTP packet including PAT, PMT and ECM is at the line 430.
RTP packets from 10.203.201.105:8034 to 10.144.96.66:12143 are unicast burst packets.
RTP Packets from 10.203.201.230:8042 to 232.0.2.2:5002 are multicast stream before changing channel. 

Best regards,

Peilin

----- 原邮件 -----
发件人: Peilin YANG <[email-masked]>
日期: 星期二, 四月 13日, 2010 下午6:02
主题: [AVT] A preamble bitstream//RE:  Preamble follow-up
收件人: "Ali C. Begen (abegen)" <[email-masked]>, "Bill Ver Steeg (versteb)" <[email-masked]>
抄送: "DRAGE, Keith (Keith)" <[email-masked]>, [email-masked], Roni Even <[email-masked]>

Dear Ali & Bill,

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期五, 四月 9日, 2010 上午0:13
主题: RE: [AVT] Preamble follow-up
收件人: [email-masked], [email-masked], [email-masked], [email-masked]

Thanks,
-acbegen

---

From: Eric Friedrich <[email-masked]>
Date: Wed, 14 Apr 2010 08:17:33 -0400

Hi Peilin-
   Is packet #431 also a preamble packet? I see it has only a single  
MPEG2TS packet, unlike the rest of the stream which has 7TS per RTP

--Eric

On Apr 14, 2010, at 1:47 AM, Peilin YANG wrote:

> In fact, I am not still clear how many post processing there are in  
> the Begen draft. Yet I summarize the post processing from the Begen  
> draft and mailing list.
> I sent the email below during the IETF week. Unless I missed it, I  
> still have not received a concrete answer from any of you to the  
> very basic question that:
>
> information is always required. I claim it is required regardless of  
> whether we use TLVs or regular TS packets to carry the preamble.  
> Post processing makes sure that the PCRs, CCs are correct and in- 
> order as well as the demux/decoder can be initialized with the right  
> encryption keys, which is crucial in encrypted streams.
>
> We revised our draft today and I hope the additional text (a summary  
> of the long thread we had earlier in the list) will help you  
> understand our reasoning.
>
> Your timely response to this question is important for us to move  
> forward in this topic. So, please let us know what your answer is.
>
> Thanks,
> -acbegen
>
>
>> Of Ali C. Begen (abegen)
>> various places in the transport stream.
>> The EMM elements, for example, may
>> need to be cached by the server to
>> extracted out of the transport stream
>> clear that certain information needs
>> fed into the demux/decoder are
>> "post processing" on the receiver side
>> compliancy as well as the device-specific
>> necessity of this step has been
>> this area for much longer than I
>> have.
>>
>> the co-authors of the Xia draft
>> issue, I want to hear a *firm* response
>> that you modify the TS packets
>> been crystal clear since day 1), we
>> packaging is better, more scalable,
>> parsing support is already needed
>> provides flexibility to the server to
>> Such information could be service-
>> shared our open source code and can
>> probably do not need to run a full-scale
>> draft or preamble examples it
>> generates.
>>
>> than later. Since Hiroshima, we

---

From: Peilin YANG <[email-masked]>
Date: Thu, 15 Apr 2010 09:38:48 +0800

Hi,

Some told me that they cannot download the bitstream. I also found that the previous link may confuse you. I am sorry.

Please do not use the link "http://www-etud.iro.umontreal.ca/~sarikaya/drafts/MPEG2-TS" to download the bitstream.
Please use the link "http://www-etud.iro.umontreal.ca/~sarikaya/drafts/MPEG2-TS%20preamble.pcap" or "http://www-etud.iro.umontreal.ca/~sarikaya/drafts/MPEG2-TS preamble.pcap" to download it.

Regards,

Peilin

----- 原邮件 -----
发件人: Peilin YANG <[email-masked]>
日期: 星期二, 四月 13日, 2010 下午6:02
主题: [AVT] A preamble bitstream//RE:  Preamble follow-up
收件人: "Ali C. Begen (abegen)" <[email-masked]>, "Bill Ver Steeg (versteb)" <[email-masked]>
抄送: "DRAGE, Keith (Keith)" <[email-masked]>, [email-masked], Roni Even <[email-masked]>

Dear Ali & Bill,

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期五, 四月 9日, 2010 上午0:13
主题: RE: [AVT] Preamble follow-up
收件人: [email-masked], [email-masked], [email-masked], [email-masked]

Thanks,
-acbegen

---

From: Peilin YANG <[email-masked]>
Date: Thu, 15 Apr 2010 09:45:50 +0800

Hi Eric,

There is one preamble packet which is the packet #430. The packet #431 is not a preamble packet, and is the first unicast burst packet.

Peilin

----- 原邮件 -----
发件人: Eric Friedrich <[email-masked]>
日期: 星期三, 四月 14日, 2010 下午8:22
主题: Re: [AVT] A preamble bitstream//RE:  Preamble follow-up
收件人: Peilin YANG <[email-masked]>
抄送: "Ali C. Begen (abegen)" <[email-masked]>, "Bill Ver Steeg (versteb)" <[email-masked]>, "DRAGE, Keith (Keith)" <[email-masked]>, [email-masked], Roni Even <[email-masked]>

Hi Peilin-

--Eric

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 15 Apr 2010 13:34:37 -0700

Can a burst packet have a single TS packet (#431 as mentioned below)? Burst packets are supposed to be retransmissions of earlier SSM packets, which (normally) carry 7 TS packets in networks with 1500-byte MTU.

Am I missing something?

-acbegen

> From: Peilin YANG [mailto:[email-masked]]
> Sent: Wednesday, April 14, 2010 9:46 PM
> To: Eric Friedrich (efriedri)
> Cc: Ali C. Begen (abegen); Bill Ver Steeg (versteb); DRAGE, Keith (Keith); [email-masked]; Roni Even
> Subject: Re: [AVT] A preamble bitstream//RE: Preamble follow-up
> 
> Hi Eric,
> 
> 抄送: "Ali C. Begen (abegen)" <[email-masked]>, "Bill Ver Steeg (versteb)" <[email-masked]>,
> "DRAGE, Keith (Keith)" <[email-masked]>, [email-masked], Roni Even
> <[email-masked]>
> 
> Hi Peilin-

---

From: Roni Even <[email-masked]>
Date: Fri, 16 Apr 2010 09:18:47 +0300

Hi Ali,
I think you are missing something.
I am interested to see what you are doing if the first IDR TS packet is not
at the beginning of an RTP packet. Can you give such a capture of what you
are sending in this case. 
Are you sending the TS packets from previous frame and dropping them in the
receiver or do you feed them to the RTP_Rx.
Roni Even
As individual

> Sent: Thursday, April 15, 2010 11:35 PM
> To: Peilin YANG; Eric Friedrich (efriedri)
> Cc: Bill Ver Steeg (versteb); DRAGE, Keith (Keith); [email-masked]; Roni
> Even
> Subject: RE: [AVT] A preamble bitstream//RE: Preamble follow-up
> 
> Can a burst packet have a single TS packet (#431 as mentioned below)?
> Burst packets are supposed to be retransmissions of earlier SSM
> packets, which (normally) carry 7 TS packets in networks with 1500-byte
> MTU.
> 
> Am I missing something?
> 
> -acbegen
> 
> > There is one preamble packet which is the packet #430. The packet
> #431 is not a preamble packet, and
> > is the first unicast burst packet.
> >
> > Peilin
> >
> > ----- 原邮件 -----
> > > RTP Packets from 10.203.201.230:8042 to 232.0.2.2:5002 are
> multicast
> > > stream before changing channel.
> > >
> > > Best regards,
> > >
> > > Peilin
> > >
> > > ----- 原邮件 -----
> > > 抄送: "DRAGE, Keith (Keith)" <[email-masked]>,
> [email-masked]
> > > rg, Roni Even <[email-masked]>
> > >
> > > Dear Ali & Bill,
> > >

---

From: Peilin YANG <[email-masked]>
Date: Fri, 16 Apr 2010 16:16:04 +0800

HI Ali,

This is a bitstream I got from an operator. This implementation didn't completely comply with the RAMS. 
I am also interested in your bitstream.

Many thinks.

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期五, 四月 16日, 2010 上午4:35
主题: RE: [AVT] A preamble bitstream//RE:  Preamble follow-up
收件人: Peilin YANG <[email-masked]>, "Eric Friedrich (efriedri)" <[email-masked]>
抄送: "Bill Ver Steeg (versteb)" <[email-masked]>, "DRAGE, Keith (Keith)" <[email-masked]>, [email-masked], Roni Even <[email-masked]>

Am I missing something?

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 16 Apr 2010 08:00:37 -0700

Remember RAMS server (RS) is given the SSM stream from a source. By no means, RS is supposed to modify the retransmission or burst packets.

Say, we will burst starting from RTP seqnum 100 and it, as usual, includes 7 TS packets but the 4th TS packet is actually where the IDR frame begins.

We cannot dump the first 3 TS packets just because they are useless. This is a retransmission packet and server cannot modify the content. So, the first burst packet will still include 7 TS packets, and the decoder will skip the first 3 TS packets (similar to how the decoder discards useless data when it randomly changes the channel).

RS will not be in control what the source could be sending so it cannot guarantee that IDR frames will always be aligned at RTP-packet boundaries. If they are, good, if they are not, the server needs to deal with such cases. 

So, having a burst/retransmission packet with only 1 TS packet will look unusual.

-acbegen

> Sent: Friday, April 16, 2010 2:19 AM
> To: Ali C. Begen (abegen); 'Peilin YANG'; Eric Friedrich (efriedri)
> Cc: Bill Ver Steeg (versteb); 'DRAGE, Keith (Keith)'; [email-masked]

---

From: David R Oran <[email-masked]>
Date: Fri, 16 Apr 2010 14:40:27 -0400

> So, having a burst/retransmission packet with only 1 TS packet will look unusual.
It will also fail a crypto check if SRTP is used on the SSM stream since the payload portion of the retransmission packet is not identical to the original packet.

---

From: Roni Even <[email-masked]>
Date: Sat, 17 Apr 2010 00:26:59 +0300

Hi Dave,
I think the issue of the first burst packet and security is a RAMS issue and
not a preamble issue.

The question is if the IDR packet in the multicast packet is not the first
TS packet in the RTP payload should the RS send the original packet with the
non-IDR part or should it take out the TS packets before the IDR and send a
short RTP packet. I think this should be clarified in the RAMS text. My view
is that both are correct.

The first comment from Ali was that since this is a retransmission it should
be a retransmission of the full original packet. I believe this also relates
to Magnus comment that the burst is not a real retransmission since the
receiver did not get an original stream on which it sent a NACK. I am
wondering if there is a specific reason why to send the whole packet and not
just the IDR TS parts.

About Dave's comment on SRTP I am not sure. The RS has to be a trusted
entity. My understanding that the RS decrypt the SSM stream in order to find
the IDR and the preamble. 

The original RTP packet is part of the payload of the RFC 4588
retransmission packet so all of it must be encrypted and not only the
payload section of the original packet so that means that the RS will need
to create a security context with the RTP-RX for the burst. (this is what I
get from section 12 of RFC 4588). If my understanding is correct I do not
understand you comment.

Roni Even
As individual 

> Sent: Friday, April 16, 2010 9:40 PM
> Cc: Roni Even; Peilin YANG; Eric Friedrich (efriedri); DRAGE, Keith
> (Keith); [email-masked]; Bill Ver Steeg (versteb)
> > Remember RAMS server (RS) is given the SSM stream from a source. By
> no means, RS is supposed to modify the retransmission or burst packets.
> >
> > Say, we will burst starting from RTP seqnum 100 and it, as usual,
> includes 7 TS packets but the 4th TS packet is actually where the IDR
> frame begins.
> >
> > We cannot dump the first 3 TS packets just because they are useless.
> This is a retransmission packet and server cannot modify the content.
> So, the first burst packet will still include 7 TS packets, and the
> decoder will skip the first 3 TS packets (similar to how the decoder
> discards useless data when it randomly changes the channel).
> >
> > RS will not be in control what the source could be sending so it
> cannot guarantee that IDR frames will always be aligned at RTP-packet
> boundaries. If they are, good, if they are not, the server needs to
> deal with such cases.
> >
> It will also fail a crypto check if SRTP is used on the SSM stream
> since the payload portion of the retransmission packet is not identical
> to the original packet.
> 
> > -acbegen
> >
> >>>>> 收件人: "Ali C. Begen (abegen)" <[email-masked]>, "Bill Ver
> Steeg
> >>>>> (versteb)" <[email-masked]>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 16 Apr 2010 14:34:39 -0700

Roni,

It is plain and simple. RAMS uses 4588 format, so 4588 rules apply. There is nothing special about this in the RAMS draft. If the 1st burst packet has non-IDR TS packets, we don’t care, RS must still transmit that packet as it is. 

-acbegen

> Sent: Friday, April 16, 2010 5:27 PM
> To: Dave Oran (oran); Ali C. Begen (abegen)
> Cc: 'Peilin YANG'; Eric Friedrich (efriedri); 'DRAGE, Keith (Keith)'; [email-masked]; Bill Ver Steeg
> (versteb)
> Subject: RAMS first burst packets creation was RE: [AVT] A preamble bitstream//RE: Preamble follow-up
> 
> Hi Dave,

---

From: Roni Even <[email-masked]>
Date: Sat, 17 Apr 2010 07:59:27 +0300

Ali,
No problem, just clarify it in RAMS
Roni

> Sent: Saturday, April 17, 2010 12:35 AM
> Cc: Peilin YANG; Eric Friedrich (efriedri); DRAGE, Keith (Keith);
> [email-masked]; Bill Ver Steeg (versteb)
> Subject: RE: RAMS first burst packets creation was RE: [AVT] A preamble
> bitstream//RE: Preamble follow-up
> 
> Roni,
> 
> It is plain and simple. RAMS uses 4588 format, so 4588 rules apply.
> There is nothing special about this in the RAMS draft. If the 1st burst
> packet has non-IDR TS packets, we don’t care, RS must still transmit
> that packet as it is.
> 
> -acbegen
> 
> > > > So, having a burst/retransmission packet with only 1 TS packet
> will
> > > look unusual.
> > > >
> > > >> I am interested to see what you are doing if the first IDR TS
> packet
> > > is not
> > > >> at the beginning of an RTP packet. Can you give such a capture
> of
> > > what you
> > > >> Are you sending the TS packets from previous frame and dropping
> them
> > > in the
> > > >>> Cc: Bill Ver Steeg (versteb); DRAGE, Keith (Keith);
> [email-masked];
> > > Roni
> > > >>> Even
> > > >>> packets, which (normally) carry 7 TS packets in networks with
> 1500-
> > > byte
> > > >>> MTU.
> > > >>>
> > > >>> Am I missing something?
> > > >>>
> > > >>> -acbegen
> > > >>>
> > > >>>> Cc: Ali C. Begen (abegen); Bill Ver Steeg (versteb); DRAGE,
> Keith
> > > >>> (Keith); [email-masked]; Roni Even
> > > >>>> 抄送: "Ali C. Begen (abegen)" <[email-masked]>, "Bill Ver
> Steeg
> > > >>> (versteb)" <[email-masked]>,
> > > >>>> MPEG2TS packet, unlike the rest of the stream which has 7TS
> per
> > > RTP
> > > >>>>
> > > >>>> --Eric
> > > >>>>
> > > >>>>> The preamble RTP packet including PAT, PMT and ECM is at the
> line
> > > >>> 430.
> > > >>>>> RTP packets from 10.203.201.105:8034 to 10.144.96.66:12143
> are
> > > >>>>> unicast burst packets.
> > > >>>>> We upload a preamble bitstream at the following link. You can
> get
> > > >>> it.
> > > >>>>> In fact, I am not still clear how many post processing there
> are
> > > in

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 16 Apr 2010 22:03:07 -0700

Will do. 

-acbegen

----- Original Message -----
From: Roni Even <[email-masked]>
To: Ali C. Begen (abegen); Dave Oran (oran)
Cc: 'Peilin YANG' <[email-masked]>; Eric Friedrich (efriedri); 'DRAGE, Keith (Keith)' <[email-masked]>; [email-masked] <[email-masked]>; Bill Ver Steeg (versteb)
Sent: Fri Apr 16 21:59:27 2010
Subject: RE: RAMS first burst packets creation was RE: [AVT] A preamble bitstream//RE:  Preamble follow-up

Ali,

---

From: Peilin YANG <[email-masked]>
Date: Mon, 19 Apr 2010 17:12:04 +0800

Dear Ali,

The bitstream doesn't comply for RAMS. It seems what you said has nothing to do with the preamble topic.

Peilin

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期五, 四月 16日, 2010 下午11:01
主题: RE: [AVT] A preamble bitstream//RE:  Preamble follow-up
收件人: Roni Even <[email-masked]>, Peilin YANG <[email-masked]>, "Eric Friedrich (efriedri)" <[email-masked]>
抄送: "Bill Ver Steeg (versteb)" <[email-masked]>, "DRAGE, Keith (Keith)" <[email-masked]>, [email-masked]

> Remember RAMS server (RS) is given the SSM stream from a source. 
> By no means, RS is supposed to modify the retransmission or burst 
> packets.
> includes 7 TS packets but the 4th TS packet is actually where the 
> IDR frame begins.
> 
> We cannot dump the first 3 TS packets just because they are 
> useless. This is a retransmission packet and server cannot modify 
> the content. So, the first burst packet will still include 7 TS 
> packets, and the decoder will skip the first 3 TS packets (similar 
> to how the decoder discards useless data when it randomly changes 
> the channel).
> 
> cannot guarantee that IDR frames will always be aligned at RTP-
> packet boundaries. If they are, good, if they are not, the server 
> needs to deal with such cases. 
> 
> will look unusual.
> packet is not
> of what you
> them in the
> [email-masked]; Roni
> > > Can a burst packet have a single TS packet (#431 as mentioned 
> below)?> > Burst packets are supposed to be retransmissions of 
> earlier SSM
> 1500-byte
> Keith> > (Keith); [email-masked]; Roni Even
> > > > There is one preamble packet which is the packet #430. The 
> packet> > #431 is not a preamble packet, and
> per RTP
> > > > > The preamble RTP packet including PAT, PMT and ECM is at 
> the line
> > > 430.
> Steeg> > > > (versteb)" <[email-masked]>
> > > > > We upload a preamble bitstream at the following link. You 
> can get
> > > it.

---

From: Peilin YANG <[email-masked]>
Date: Mon, 19 Apr 2010 17:16:32 +0800

Dear Dave,

Thank you very much for your reminder. Our RAMS product will consider this issue. I also agree Roni viewpoint. This is the issue of the first burst packet and security is a RAMS issue and not a preamble issue.

Many thanks.

Peilin

----- 原邮件 -----
发件人: David R Oran <[email-masked]>
日期: 星期六, 四月 17日, 2010 上午2:41
主题: Re: [AVT] A preamble bitstream//RE:  Preamble follow-up
收件人: "Ali C. Begen (abegen)" <[email-masked]>
抄送: Roni Even <[email-masked]>, Peilin YANG <[email-masked]>, "Eric Friedrich (efriedri)" <[email-masked]>, "DRAGE, Keith (Keith)" <[email-masked]>, [email-masked], "Bill Ver Steeg (versteb)" <[email-masked]>

> packets.> 
> > Say, we will burst starting from RTP seqnum 100 and it, as 
> usual, includes 7 TS packets but the 4th TS packet is actually 
> where the IDR frame begins.
> > 
> since the payload portion of the retransmission packet is not 
> identical to the original packet.
> 
> > -acbegen
> > 
> below)?>>> Burst packets are supposed to be retransmissions of 
> earlier SSM
> >>>>   Is packet #431 also a preamble packet? I see it has only a 
> single>>>> MPEG2TS packet, unlike the rest of the stream which has 
> 7TS per RTP
> >>>> 
> >>>> --Eric
> >>>> 
> line>>> 430.
> are in