Subject: [AVT] About post processing for the MPEG2-TS preamble

From: Peilin YANG <[email-masked]>
Date: Thu, 15 Apr 2010 10:00:10 +0800

Dear Ali and Eric,

In fact, as a reader I am not completely clear what post processing do in the Begen draft. Yet I summarize the post processing from the Begen draft and mailing list which includes:

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

Besides these post processings, are there other post processings? 

Many thanks.

Peilin

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 14 Apr 2010 20:40:04 -0700

Did you have a look at section 7 of the -05 version? We extended the text over there and I hope it will answer your questions. In summary, we take the TOLVs, create the TS packets fixing their CCs, timings, so that the preamble seamlessly integrates with the burst stream. In the mean time, some of the data could be used to program the hardware directly so that the decoder initializes faster, reducing the overall presentation times.

Also we make sure that the decoder is ready to digest the burst so we can have a successful channel change. If the burst is fed to the decoder before the decoder is ready, it will miss some of the critical information and then will fail to decode the burst.

It might be difficult to appreciate the importance of this step if one has not dealt with a variety of chipsets available in the market. Note that this has nothing to do with the spec. There are certain points in the spec left out as implementation details. We must pay attention to these details if we want this preamble stuff to improve RAMS performance.

If the above steps are still unclear to you, please go ahead and check the source code. The address is in the draft.

A final note is that the post processing we do allows us to address the unique requirements of each different decoder chipset. The preamble we produce at the server is generic, will not fit all. But, a few manipulations on the client side perfect that generic data and it provides the fastest speed out of the decoder.

Cheers, acbegen.

> -----Original Message-----
> From: Peilin YANG [mailto:[email-masked]]
> Sent: Wednesday, April 14, 2010 10:00 PM
> To: Ali C. Begen (abegen); Eric Friedrich (efriedri)
> Cc: [email-masked]
> Subject: About post processing for the MPEG2-TS preamble
> 
> Dear Ali and Eric,
> 
> In fact, as a reader I am not completely clear what post processing do in the Begen draft. Yet I
> summarize the post processing from the Begen draft and mailing list which includes:
>

---

From: Roni Even <[email-masked]>
Date: Thu, 15 Apr 2010 08:00:48 +0300

Hi,
I am not sure what the " In summary, we take the TOLVs, create the TS
packets fixing their CCs, timings, so that the preamble seamlessly
integrates with the burst stream." means. Do you need to parse the burst
stream to do it or are you just using the information from the TOLV to
create the MPEG2-TS stream in which case what does fixing mean. I read
section 7 and could not see any specific changes to the information received
from the server being done to construct the original MPEG2-TS stream.

I noticed that you suggest that there is an option to feed the chipset
directly and not the multiplexer. This is an implementation decision and can
be done with any payload received by the  RTP_Rx
Roni Even

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Thursday, April 15, 2010 6:40 AM
> To: Peilin YANG; Eric Friedrich (efriedri)
> Cc: [email-masked]
> Subject: Re: [AVT] About post processing for the MPEG2-TS preamble
> 
> Did you have a look at section 7 of the -05 version? We extended the
> text over there and I hope it will answer your questions. In summary,
> we take the TOLVs, create the TS packets fixing their CCs, timings, so
> that the preamble seamlessly integrates with the burst stream. In the
> mean time, some of the data could be used to program the hardware
> directly so that the decoder initializes faster, reducing the overall
> presentation times.
> 
> Also we make sure that the decoder is ready to digest the burst so we
> can have a successful channel change. If the burst is fed to the
> decoder before the decoder is ready, it will miss some of the critical
> information and then will fail to decode the burst.
> 
> It might be difficult to appreciate the importance of this step if one
> has not dealt with a variety of chipsets available in the market. Note
> that this has nothing to do with the spec. There are certain points in
> the spec left out as implementation details. We must pay attention to
> these details if we want this preamble stuff to improve RAMS
> performance.
> 
> If the above steps are still unclear to you, please go ahead and check
> the source code. The address is in the draft.
> 
> A final note is that the post processing we do allows us to address the
> unique requirements of each different decoder chipset. The preamble we
> produce at the server is generic, will not fit all. But, a few
> manipulations on the client side perfect that generic data and it
> provides the fastest speed out of the decoder.
> 
> Cheers, acbegen.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Peilin YANG <[email-masked]>
Date: Thu, 15 Apr 2010 15:19:27 +0800

Hi Ali,

Please see inline.

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期四, 四月 15日, 2010 上午11:41
主题: RE: About post processing for the MPEG2-TS preamble
收件人: Peilin YANG <[email-masked]>, "Eric Friedrich (efriedri)" <[email-masked]>
抄送: [email-masked]
>Did you have a look at section 7 of the -05 version? We extended the text over there and I hope it will answer your questions. In summary, we take the TOLVs, create the TS >packets fixing their CCs,

Peilin: Many thanks, I understood this step now but I don't know if it is correct, Please make sure. That is to say, When PSIs are retrieved from TOLVs which don't contain TS headers and adaptation field, TS headers of these PSIs are needed to reconstructe. The CCs value of TS header are retrieved from the PIDLIST TOLV element according to there PID. After TS packets of PSIs are retrieved from TOLV elements, the PAT and PMT are fed to the d
emux firstly, and then the EMM and ECM are fed, the last is elementary stream data. 
Are you sure that the above understanding is correct?

>timings, so that the preamble seamlessly integrates with the burst stream. 

Peilin: I am sorry. I don't know what's the "timings, so that the preamble seamlessly integrates with the burst stream" because I don't find "timings" in section 7.
Is "timings" before being retrieved from TOLV elements or after? Or is "timings" only for "The Section Data may optionally be programmed automatically into decoder hardware registers" which needs a special chipset interface. 

>In the mean time, some of the data could be used to program the hardware directly so that the decoder initializes faster, reducing the overall presentation times.

>Also we make sure that the decoder is ready to digest the burst so we can have a successful channel change. If the burst is fed to the decoder before the decoder is ready, it >will miss some of the critical information and then will fail to decode the burst.

>It might be difficult to appreciate the importance of this step if one has not dealt with a variety of chipsets available in the market. Note that this has nothing to do with >the spec. There are certain points in the spec left out as implementation details. We must pay attention to these details if we want this preamble stuff to improve RAMS >performance.

>A final note is that the post processing we do allows us to address the unique requirements of each different decoder chipset. The preamble we produce at the server is >generic, will not fit all. But, a few manipulations on the client side perfect that generic data and it provides the fastest speed out of the decoder.

---

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

Roni,

The information we need is part of the TOLVs we transmit (e.g., see PCR TOLV). We use that information to create the TS packets out of the preamble.

Regarding programming the chipset directly, this is something one can do only if post processing is done at the client. You mentioned several times you would not need to since your TS packets were in the right order. But, if you wanna do this direct programming, you can certainly do so after parsing your TS packets on the client. And for that as I mentioned earlier, you will need a TS parsing logic. You will also need to carefully feed your TS packets to make sure that the changes you made became effective.

-acbegen

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, April 15, 2010 1:01 AM
> To: Ali C. Begen (abegen); 'Peilin YANG'; Eric Friedrich (efriedri)
> Cc: [email-masked]
> Subject: RE: [AVT] About post processing for the MPEG2-TS preamble
> 
> Hi,

---

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

Hi Peilin,

I believe it will be easier if you just look at the code. When we create the TS packets we make sure that they are consistent with the burst packets the client is about to receive. The PIDLIST, PCR, etc. TOLVs are used for that purpose. 

And regarding the chipset programming, if there is an option for it, why don’t use it.

-acbegen

> Sent: Thursday, April 15, 2010 3:19 AM
> To: Ali C. Begen (abegen)
> Cc: Eric Friedrich (efriedri); [email-masked]
> Subject: RE: About post processing for the MPEG2-TS preamble
> 
> Hi Ali,
> 
> Please see inline.
> 
> 
> ----- 原邮件 -----
> >Did you have a look at section 7 of the -05 version? We extended the text over there and I hope it
> will answer your questions. In summary, we take the TOLVs, create the TS >packets fixing their CCs,
> 
> Peilin: Many thanks, I understood this step now but I don't know if it is correct, Please make sure.
> That is to say, When PSIs are retrieved from TOLVs which don't contain TS headers and adaptation
> field, TS headers of these PSIs are needed to reconstructe. The CCs value of TS header are retrieved
> from the PIDLIST TOLV element according to there PID. After TS packets of PSIs are retrieved from TOLV
> elements, the PAT and PMT are fed to the d
> Peilin: I am sorry. I don't know what's the "timings, so that the preamble seamlessly integrates with
> the burst stream" because I don't find "timings" in section 7.
> Is "timings" before being retrieved from TOLV elements or after? Or is "timings" only for "The Section
> Data may optionally be programmed automatically into decoder hardware registers" which needs a special
> chipset interface.
> 
> >In the mean time, some of the data could be used to program the hardware directly so that the decoder
> initializes faster, reducing the overall presentation times.
> 
> >Also we make sure that the decoder is ready to digest the burst so we can have a successful channel
> change. If the burst is fed to the decoder before the decoder is ready, it >will miss some of the
> critical information and then will fail to decode the burst.
> 
> >It might be difficult to appreciate the importance of this step if one has not dealt with a variety
> of chipsets available in the market. Note that this has nothing to do with >the spec. There are
> certain points in the spec left out as implementation details. We must pay attention to these details
> if we want this preamble stuff to improve RAMS >performance.
> 
> >A final note is that the post processing we do allows us to address the unique requirements of each
> different decoder chipset. The preamble we produce at the server is >generic, will not fit all. But, a
> few manipulations on the client side perfect that generic data and it provides the fastest speed out
> of the decoder.
> 
> >Cheers, acbegen.
>

---

From: Eric Friedrich <[email-masked]>
Date: Thu, 15 Apr 2010 11:44:50 -0400

Hi Peilin-
    Please see my comments inline.

On Apr 15, 2010, at 3:19 AM, Peilin YANG wrote:

>> Did you have a look at section 7 of the -05 version? We extended  
>> the text over there and I hope it will answer your questions. In  
>> summary, we take the TOLVs, create the TS >packets fixing their CCs,
>
> Peilin: Many thanks, I understood this step now but I don't know if  
> it is correct, Please make sure. That is to say, When PSIs are  
> retrieved from TOLVs which don't contain TS headers and adaptation  
> field, TS headers of these PSIs are needed to reconstructe. The CCs  
> value of TS header are retrieved from the PIDLIST TOLV element  
> according to there PID. After TS packets of PSIs are retrieved from  
> TOLV elements, the PAT and PMT are fed to the d
Yes, this is correct.

> Peilin: I am sorry. I don't know what's the "timings, so that the  
> preamble seamlessly integrates with the burst stream" because I  
> don't find "timings" in section 7.
> Is "timings" before being retrieved from TOLV elements or after? Or  
> is "timings" only for "The Section Data may optionally be programmed  
> automatically into decoder hardware registers" which needs a special  
> chipset interface.
We choose to include a PCR value in our preamble, because the I-Frame/ 
IDR may not always include a PCR sample. By priming the decoder clock  
with the preamble PCR, we must make sure the value correctly matches  
up with the PCR values found in the unicast burst. The preamble TOLV  
includes the PCR value of the first TS packet in the burst (not the  
value of the first PCR sample in the burst). The post-processing  
adjusts the TOLV value earlier so that whatever component of the  
decoder that tracks the PCR value does not get confused when the  
preamble switches to the unicast burst.

--Eric

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 15 Apr 2010 11:54:35 -0500

Peilin-

Thank you for the sniffer trace, as this does bring up some interesting points. In our discussion of clock timing issues, we were making different assumptions about the contents of the burst.

It is not clear to me that an implementer can assume that the PCR value directly precedes the PES, which directly precedes the I-frame. I am running this down now with our MEPG2TS experts.

If the PCR always directly precedes the rest of the burst in every video stream, the PCR can be sent in the burst (as opposed to the preamble) and any assumptions about the accuracy of the PCR clock are probably less concerning. If the PCR does not always directly precede the other elements of the burst, the PCR values need to be conveyed in the pre-amble. To Erics's point (and my previous discussion around clock values), when one changes the temporal relationship between a PCR value and the rest of the stream, one must be careful with the actual clock values.

I am still running some of this down, but it looks like we are making progress on the technical analysis. Once we determine if the PCR should sent in the pre-amble or in the burst, we will be in a better position to conclude the analysis.

I am pretty sure I have seen streams in the wild in which PCR is not tightly coupled to PES/I-Frames, but I will double check.

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Friedrich (efriedri)
Sent: Thursday, April 15, 2010 11:45 AM
To: Peilin YANG
Cc: [email-masked]
Subject: Re: [AVT] About post processing for the MPEG2-TS preamble

Hi Peilin-

Yes, this is correct.

--Eric

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Thu, 15 Apr 2010 09:58:49 -0700

PCRs do not have to be at any particular place in the stream - they just have to occur with at least a minimum frequency. It is very possible for there not to be a PCR immediately before a PES start or immediately before the start of an IDR or I picture. 

--Sandy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill Ver Steeg (versteb)
Sent: Thursday, April 15, 2010 9:55 AM
To: Eric Friedrich (efriedri); Peilin YANG
Cc: [email-masked]
Subject: Re: [AVT] About post processing for the MPEG2-TS preamble

Peilin-

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Friedrich (efriedri)
Sent: Thursday, April 15, 2010 11:45 AM
To: Peilin YANG
Cc: [email-masked]
Subject: Re: [AVT] About post processing for the MPEG2-TS preamble

Hi Peilin-

Yes, this is correct.

--Eric

---

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

Hi Bill,
I think that the first question that you and Ali had interest in was if
there are examples where you do not need to do post processing on the stream
in the RTP_Rx. So this was one example.
Do you agree that such cases exist in practice.
Roni Even
As individual

> Bill Ver Steeg (versteb)
> Sent: Thursday, April 15, 2010 7:55 PM
> Thank you for the sniffer trace, as this does bring up some interesting
> points. In our discussion of clock timing issues, we were making
> different assumptions about the contents of the burst.
> 
> It is not clear to me that an implementer can assume that the PCR value
> directly precedes the PES, which directly precedes the I-frame. I am
> running this down now with our MEPG2TS experts.
> 
> If the PCR always directly precedes the rest of the burst in every
> video stream, the PCR can be sent in the burst (as opposed to the
> preamble) and any assumptions about the accuracy of the PCR clock are
> probably less concerning. If the PCR does not always directly precede
> the other elements of the burst, the PCR values need to be conveyed in
> the pre-amble. To Erics's point (and my previous discussion around
> clock values), when one changes the temporal relationship between a PCR
> value and the rest of the stream, one must be careful with the actual
> clock values.
> 
> I am still running some of this down, but it looks like we are making
> progress on the technical analysis. Once we determine if the PCR should
> sent in the pre-amble or in the burst, we will be in a better position
> to conclude the analysis.
> 
> I am pretty sure I have seen streams in the wild in which PCR is not
> tightly coupled to PES/I-Frames, but I will double check.
> 
> 
> Bill VerSteeg
> 
> Eric Friedrich (efriedri)

---

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

Hi Bill,

As usual the time of PCR is earlier than the time of PTS of I frame. I tested some streams with PCR in the preamble and without PCR in the preamble. I found there is no explicit improvement to the time of fast channel change with PCR in the preamble compared to without PCR. In order to avoid possible effect, we also include PCR in the preamble. But in this bitstream PCR information is included in the adapation field of IDR frame so that we 
ignore it in this preamble.

Could you post your bitstream to us? Many thanks.

Peilin

----- 原邮件 -----
发件人: "Bill Ver Steeg (versteb)" <[email-masked]>
日期: 星期五, 四月 16日, 2010 上午0:54
主题: RE: [AVT] About post processing for the MPEG2-TS preamble
收件人: "Eric Friedrich (efriedri)" <[email-masked]>, Peilin YANG <[email-masked]>
抄送: [email-masked]

If the PCR always directly precedes the rest of the burst in every video stream, the PCR can be sent in the burst (as opposed to the preamble) and any assumptions about the accuracy of the PCR clock are probably less concerning. If the PCR does not always directly precede the other elements of the burst, the PCR values need to be conveyed in the pre-amble. To Erics's point (and my previous discussion around clock values), when one changes t
he temporal relationship between a PCR value and the rest of the stream, one must be careful with the actual clock values.

Bill VerSteeg

---

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

Hi Eric,

Thank you very much for explaining post processing and give the some confirmation.  
You said "The post-processing adjusts the TOLV value earlier so that whatever component of the decoder that tracks the PCR value does not get confused when the  
preamble switches to the unicast burst."
This still is not clear to me. What's more, there is no such description in the draft. 
I mean which TOLV value shall be adjusted, is it "PAT TOLV, PMT TOLV and CAT TOLV" and/or "ECMs or EMMs ", and/or "Elementary Stream Data"? 
Is it be adjusted for preamble RTP packets every time or sometimes? If it is sometimes, under swhat conditions shall it be adjusted?

Many thanks.

Peilin

----- 原邮件 -----
发件人: Eric Friedrich <[email-masked]>
日期: 星期四, 四月 15日, 2010 下午11:45
主题: Re: About post processing for the MPEG2-TS preamble
收件人: Peilin YANG <[email-masked]>
抄送: "Ali C. Begen (abegen)" <[email-masked]>, [email-masked]

> >> summary, we take the TOLVs, create the TS >packets fixing their 
> CCs,>
> >> timings, so that the preamble seamlessly integrates with the 
> burst  
> >> stream.
> >

---

From: Eric Friedrich <[email-masked]>
Date: Fri, 16 Apr 2010 08:42:23 -0400

Hi Peilin-
   I believe there is a satisfactory description in version -05 of the  
draft (http://tools.ietf.org/search/draft-begen-avt-rtp-mpeg2ts-preamble-05 
). Section 7 Bullet 2 contains a description of the Post-Processing  
performed on the PCR TOLV element.
"2. PCR Data A single TS packet is constructed from the PCR TOLV. This  
contains a 4-byte TS header with correct PID and continuity counter as  
retrieved from the PIDLIST. The Adaptation Field control bits should  
indicate that only an adaptation_field and no payload is present. The  
adaptation field should contain the PCR value from the PCR TOLV  
followed by padding to fill the TS packet. The discontinuity_indicator  
in the Adaptation Field should be set to one. The PCR value MUST be  
constructed to be continuous with the        MPEG2-TS timebase. The  
PCR TOLV packet contains the PCR value of the first packet in the  
unicast burst and this value MUST be adjusted by an amount equal to  
the time needed to the write the preamble into the decoder."
The PCR TOLV is post-processed into a single MPEG2TS packet. The  
location of this MPEG2TS packet in the preamble output determines how  
much its value must be adjusted by. I'll give an example. The value in  
the PCR TOLV is PCR_0. Because of the rate of the stream, each TS  
packet takes 10 ticks of PCR time. If I send the PCR MPEG2TS packet  
into the decoder after the PAT & PMT, followed by 3 ECMs, then I must  
adjust the PCR value in the MPEG2TS packet earlier by 40 ticks to  
account for its earlier position in the stream.

--Eric

On Apr 16, 2010, at 3:59 AM, Peilin YANG wrote:
Sec
> You said "The post-processing adjusts the TOLV value earlier so that  
> whatever component of the decoder that tracks the PCR value does not  
> get confused when the
> I mean which TOLV value shall be adjusted, is it "PAT TOLV, PMT TOLV  
> and CAT TOLV" and/or "ECMs or EMMs ", and/or "Elementary Stream Data"?
> Is it be adjusted for preamble RTP packets every time or sometimes?  
> If it is sometimes, under swhat conditions shall it be adjusted?
>
> Many thanks.
>
> Peilin
>
>
> ----- 原邮件 -----

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 16 Apr 2010 09:17:39 -0500

The MPEG specification does not require the PCR to directly precede the I-frame. There are production systems in the real world that have the PCR freewheel with respect to the GOPs. The data can be separated by 100s of milliseconds. In other words, the PCR values can occur anywhere in the stream relative to the I-frame. If you are testing with a stream that happens to have the PCR in front of the I-frame, you will get the results you describe.

For the more general case - If the clocks are not setup prior to getting audio/video data, the decoder will not work. If the clock values are wrong, the decoder will stutter. If you do not put PCR in the burst (and fix up the clock value, if required) some perfectly compliant MPEG2TS streams will not be accelerated at all.

Please see my other post for a more detailed explanation of this.

Bvs

-----Original Message-----
From: Peilin YANG [mailto:[email-masked]] 
Sent: Friday, April 16, 2010 3:44 AM
To: Bill Ver Steeg (versteb)
Cc: Eric Friedrich (efriedri); [email-masked]
Subject: RE: [AVT] About post processing for the MPEG2-TS preamble

Hi Bill,

Peilin

----- 原邮件 -----
发件人: "Bill Ver Steeg (versteb)" <[email-masked]>
日期: 星期五, 四月 16日, 2010 上午0:54
主题: RE: [AVT] About post processing for the MPEG2-TS preamble
收件人: "Eric Friedrich (efriedri)" <[email-masked]>, Peilin YANG <[email-masked]>
抄送: [email-masked]

Bill VerSteeg

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 16 Apr 2010 09:32:09 -0500

Roni-

Even this (very simple, very benign) stream sample still requires substantial post processing. Real world compliant streams are not always so simple, and additional post processing is required for more complex input streams. The exact nature of this post processing is very much device specific, and thus not subject to standardization. 

Having said that, I will lay out a sample series of events for a sample chipset. Every chipset will be different, but they all will require post processing.

First, let's consider timing - If one were to simply jam this simple stream into a decoder without introducing timing delays to allow the various devices to setup, the acceleration would fail. These delays are quite device-specific. After feeding the PAT to the demux, you have to wait for the demux to setup the PID filters so it can parse the PMT. You then feed the PMT to the demux, and need to wait for the demux to setup the PIDs for the AV. You then need to introduce some local data (the crypto data from the EMM) into the decryptor, and let it setup. You then jam the ECM into the decryptor, and wait for it to do the DES/3DES/AES operations (which can take a substantial amount of time, and may require substantial bit-banging on a given chipset). The sample stream is from a system with a single CAS, so it does not have the complexity of a simulcrypt system. For such systems, there is significant addition post processing at this point of the flow. Now you are in a position to feed the video data into the decryptor, and on to the decoder. For MPEG2 streams, you feed the PCR, the PES, then the I-frame, then the rest of the GOP. Once you get past the preamble portion of the flow you are using the original stream, so the timing issues are largely resolved.

I am not sure how you can get around these timing constraints for any device. Are you saying that you have a device that does demux/crypto operations faster than you can feed it data?

Next, let's consider NULL packets. Certain decryptors and decoders need more than time to process the data. They only process data when a local buffer gets full. In order to have the demux process the PAT, it needs to be pushed through the buffer by the data behind it. There is no data in the proposed solution to push the PAT through the buffers, so one needs to stuff MPEG2TS NULL packets. For this class of devices, you need to insert MPEG NULLs between each of the pre-amble's data elements.

Lastly, let's consider clocks. PCRs need to have very accurate clocks (I believe the spec calls for +-50 nanoseconds). In the original MPEG specification, the intent of these clocks was to allow the client to derive the precise clock rate of the source. If you fool around with the ordering/timing of PCRs, you need to adjust the clocks within the PCRs. Same for PTS and DTS. Because the decoder needs the clock value and PCR does not always precede the PES/I-frame, the PCR clock needs to be sent in the burst. When you send the PCR in the burst, you change the timing between reception of the PCR and the start of the I-frame. The timing is further perturbed by the setup times described in the previous section of this note. When change the relative timing of the data, you MUST modify the clock within the PCR. This is a subtle point and difficult to explain, but is quite clear to folks who are familiar with the way MPEG clock operate. If you try to send this data as an MPEG2TS stream without fixing up the clocks, you simply do not have a compliant stream.

For a given device, there may also be post processing required for continuity counters and discontinuity indicators. 

If you try to push all of this functionality (client specific timing, insertion of EMM information, insertion of NULL data, and clock fixup) to the server, you end up with an intractable problem.

So, the net effect is that the client side code is going to have to be able to build a local MPEG2TS stream from the elements contained in the pre-amble. It simply is extra work/complexity to build MPEG2TS on the server and then re-build it on the client. It is cleaner to build the stream on the client. This also avoids the issue of masking the preamble MPEG2TS compliance on the wire. We have a reference implementation, and have submitted it to the open source community. It has been tested with a wide range of streams, with a wide range of chipsets, with a wide range of encryption standards. 

Bvs

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Friday, April 16, 2010 2:24 AM
To: Bill Ver Steeg (versteb); Eric Friedrich (efriedri); 'Peilin YANG'
Cc: [email-masked]
Subject: RE: [AVT] About post processing for the MPEG2-TS preamble

Hi Bill,

---

From: Eric Friedrich <[email-masked]>
Date: Fri, 16 Apr 2010 20:44:44 -0400

Peilin, Roni-
   I've included a link to our post-processing output.
http://ali.begen.net/files/preamble_out.pcap

The first two TS packets are the output of our post-processing. The  
two packets are duplicates of each with with the exception of  
Continuity Counter differences and PCR differences as I described  
earlier. Each packet contains a PAT & PMT, followed by identical PAT &  
PMT. These repetitions of the PSI and the preamble output as a whole  
are all configurable based on the needs of the implementation. Our  
default settings put 2 PAT,PMT combos in each UDP packet and output 2  
identical UDP packets.

I've included more of the stream packets 2-70 so you can verify the  
continuity counters and timing are correct. If anything is not clear  
or if you have questions, please ask.

Eric

On Apr 16, 2010, at 3:44 AM, Peilin YANG wrote:

> Hi Bill,
>
> As usual the time of PCR is earlier than the time of PTS of I frame.  
> I tested some streams with PCR in the preamble and without PCR in  
> the preamble. I found there is no explicit improvement to the time  
> of fast channel change with PCR in the preamble compared to without  
> PCR. In order to avoid possible effect, we also include PCR in the  
> preamble. But in this bitstream PCR information is included in the  
> adapation field of IDR frame so that we
> Thank you for the sniffer trace, as this does bring up some  
> interesting points. In our discussion of clock timing issues, we  
> were making different assumptions about the contents of the burst.
>
> It is not clear to me that an implementer can assume that the PCR  
> value directly precedes the PES, which directly precedes the I- 
> frame. I am running this down now with our MEPG2TS experts.
>
> preamble) and any assumptions about the accuracy of the PCR clock  
> are probably less concerning. If the PCR does not always directly  
> precede the other elements of the burst, the PCR values need to be  
> conveyed in the pre-amble. To Erics's point (and my previous  
> discussion around clock values), when one changes t
> he temporal relationship between a PCR value and the rest of the  
> stream, one must be careful with the actual clock values.
>
> I am still running some of this down, but it looks like we are  
> making progress on the technical analysis. Once we determine if the  
> PCR should sent in the pre-amble or in the burst, we will be in a  
> better position to conclude the analysis.
>

---

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

Dear Eric,

Thank you very much for the explaination for post processing.

IHMO, both the result of post processing and TOLV elements are loose couple. The result of post processing is not the required conditions from the TOLV elements. 
Xia draft directly implements the result of post processing, and also finishs this function. In addition, the advantage of Xia draft is explicit because it can deal with unknown Private_Section PSIs and avoid upgrading.  
Verifying the continuity counters depends on the PIDLIST TOLV element. That is to say, it is verified at RS. If RS cannot provide the correct CCs in the PIDLIST TOLV element. How does the post processing do?

As for the output of two identical UDP packets, IHMO, this is a project implementation for reliably feeding PSIs to demultiplexing. 

In addition, could you provide the bitstream before post processing? Many thanks.

Peilin

----- 原邮件 -----
发件人: Eric Friedrich <[email-masked]>
日期: 星期六, 四月 17日, 2010 上午8:44
主题: Re: [AVT] About post processing for the MPEG2-TS preamble
收件人: Peilin YANG <[email-masked]>, Roni Even <[email-masked]>
抄送: "Bill Ver Steeg (versteb)" <[email-masked]>, "[email-masked] WG" <[email-masked]>

Peilin, Roni-

Eric

---

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

Dear Bill,

Yes, the PCR doesn't directly precede every I-frame. The bitstream is only a coincidence so that there is no PCR in the preamble.
Our solution also supports PCR and keeps its corrent CC value. 

Peilin 

----- 原邮件 -----
发件人: "Bill Ver Steeg (versteb)" <[email-masked]>
日期: 星期五, 四月 16日, 2010 下午10:18
主题: RE: [AVT] About post processing for the MPEG2-TS preamble
收件人: Peilin YANG <[email-masked]>
抄送: "Eric Friedrich (efriedri)" <[email-masked]>, [email-masked]

The MPEG specification does not require the PCR to directly precede the I-frame. There are production systems in the real world that have the PCR freewheel with respect to the GOPs. The data can be separated by 100s of milliseconds. In other words, the PCR values can occur anywhere in the stream relative to the I-frame. If you are testing with a stream that happens to have the PCR in front of the I-frame, you will get the results you descri
be.

Bvs

-----Original Message-----
From: Peilin YANG [mailto:[email-masked]] 
Sent: Friday, April 16, 2010 3:44 AM
To: Bill Ver Steeg (versteb)
Cc: Eric Friedrich (efriedri); [email-masked]
Subject: RE: [AVT] About post processing for the MPEG2-TS preamble

Hi Bill,

Peilin

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Mon, 19 Apr 2010 07:57:11 -0500

Peilin

I am less concerned with the Continuity Counter value, and more concerned with the clock value. I think we agree that if you change the timing relationship between a PCR and the rest of the data, you need to change the clock values in the PCR. 

The MPEG specs have detailed requirements for clock timing. You claim to be sending compliant MPEG data in the preamble. I am therefore assuming that you do a clock fixup on the server prior to sending the preamble. As discussed in our previous emails - there is substantial client specific manipulation of the preamble, much of which impacts the timing. The server can't (more accurately, it becomes very complex) know the client specific timing changes. So, you have to redo the clocks on the client.

It is not clear to me why you would calculate a PCR clock value on the server, then recalculate the clocks on the client. The obvious answer is to not try to use MPEG2TS for the preamble. We send the preamble as TLV, and only do the clock fixup once.

This is one of the ways that using TLV for the preamble makes the server simpler. 

Bill VerSteeg

-----Original Message-----
From: Peilin YANG [mailto:[email-masked]] 
Sent: Monday, April 19, 2010 5:06 AM
To: Bill Ver Steeg (versteb)
Cc: Eric Friedrich (efriedri); [email-masked]
Subject: RE: [AVT] About post processing for the MPEG2-TS preamble

Dear Bill,

Peilin 

----- 原邮件 -----
发件人: "Bill Ver Steeg (versteb)" <[email-masked]>
日期: 星期五, 四月 16日, 2010 下午10:18
主题: RE: [AVT] About post processing for the MPEG2-TS preamble
收件人: Peilin YANG <[email-masked]>
抄送: "Eric Friedrich (efriedri)" <[email-masked]>, [email-masked]

Bvs

-----Original Message-----
From: Peilin YANG [mailto:[email-masked]] 
Sent: Friday, April 16, 2010 3:44 AM
To: Bill Ver Steeg (versteb)
Cc: Eric Friedrich (efriedri); [email-masked]
Subject: RE: [AVT] About post processing for the MPEG2-TS preamble

Hi Bill,

Peilin

---

From: Eric Friedrich <[email-masked]>
Date: Mon, 19 Apr 2010 09:47:59 -0400

Peilin-
   Thanks for reviewing the bitstream I posted.
On Apr 19, 2010, at 4:00 AM, Peilin YANG wrote:

> IHMO, both the result of post processing and TOLV elements are loose  
> couple. The result of post processing is not the required conditions  
> from the TOLV elements.
> Xia draft directly implements the result of post processing, and  
> also finishs this function. In addition, the advantage of Xia draft  
> is explicit because it can deal with unknown Private_Section PSIs  
> and avoid upgrading.
> Verifying the continuity counters depends on the PIDLIST TOLV  
> element. That is to say, it is verified at RS. If RS cannot provide  
> the correct CCs in the PIDLIST TOLV element. How does the post  
> processing do?
  I do not think it is correct to say the continuity counters are  
verified at the RS. Rather, the decoder is the entity which cares most  
about the continuity_counters. RAMS will still work fine from the RS  
perspective if the CC values are discontinuous. Section 7 of the draft  
describes in detail and with an example how the post-processing  
generates the correct CC for the TS headers. Additionally, we have  
posted several links to our (open-source) post-processing code that  
you should reference if you would like to see the implementation  
specific details. If you are asking about how the PIDLIST TOLV is  
generated at the RS- The RS knows which RTP packet will be first in  
the RAMS burst and it must also know the continuity_counter of all  
PIDs at this same point. It simply places these continuity_counter  
values into the PIDLIST TOLV and sends it along with the rest of the  
preamble.

> As for the output of two identical UDP packets, IHMO, this is a  
> project implementation for reliably feeding PSIs to demultiplexing.
Agreed, I was not suggesting this be made part of the draft. Things of  
this sort should remain implementation specific.

> In addition, could you provide the bitstream before post processing?  
Our TOLV data is currently sent to the client as an RTCP App packet,  
not as the proposed RTP preamble-payload packet. This is a minor  
change in packaging, however the structure of the App may make it hard  
for others to parse the packet data. I can post just the TOLV data  
with a short description- I think that would probably be easiest.

--Eric

---

From: Tom Taylor <[email-masked]>
Date: Tue, 20 Apr 2010 11:28:40 -0400

Do I understand correctly that if the packets are sent in the MPEG2TS format,
extra processing is needed at the server to make sure they are conformant,
whereas the TOLV format dodges that issue by making the frank assumption that
clock values will be set correctly at the receiver? If so, the lack of
requirement for complete conformance is an advantage for the TOLV format in the
cases where the receiver will have to do post-processing anyway.

This is the first time I've perceived any hint that one format could be better
in more common cases than the other, but maybe my understanding is wrong :)

Bill Ver Steeg (versteb) wrote:
> Peilin
> 
> 
> I am less concerned with the Continuity Counter value, and more concerned
> with the clock value. I think we agree that if you change the timing
> relationship between a PCR and the rest of the data, you need to change the
> clock values in the PCR.
> 
> The MPEG specs have detailed requirements for clock timing. You claim to be
> sending compliant MPEG data in the preamble. I am therefore assuming that you
> do a clock fixup on the server prior to sending the preamble. As discussed in
> our previous emails - there is substantial client specific manipulation of
> the preamble, much of which impacts the timing. The server can't (more
> accurately, it becomes very complex) know the client specific timing changes.
> So, you have to redo the clocks on the client.
> 
> It is not clear to me why you would calculate a PCR clock value on the
> server, then recalculate the clocks on the client. The obvious answer is to
> not try to use MPEG2TS for the preamble. We send the preamble as TLV, and
> only do the clock fixup once.
> 
...

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 20 Apr 2010 11:01:46 -0500

Tom-

That is correct. I have been (poorly) trying to explain this important
but subtle point since the two proposals surfaced. We originally came
upon the clock/timing issues during our detailed design stages, but it
took us a while for our MPEG2TS experts to recognize the root causes.
Having the audio/video stutter due to bad clock values is a powerful
motivator (8-)).

Having an example of a specific stream with a PCR is helpful to
illustrate the issues. 

Bill VerSteeg

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: Tuesday, April 20, 2010 11:29 AM
To: Bill Ver Steeg (versteb)
Cc: Peilin YANG; [email-masked]
Subject: Re: [AVT] About post processing for the MPEG2-TS preamble

Do I understand correctly that if the packets are sent in the MPEG2TS
format,
extra processing is needed at the server to make sure they are
conformant,
whereas the TOLV format dodges that issue by making the frank assumption
that
clock values will be set correctly at the receiver? If so, the lack of
requirement for complete conformance is an advantage for the TOLV format
in the
cases where the receiver will have to do post-processing anyway.

This is the first time I've perceived any hint that one format could be
better
in more common cases than the other, but maybe my understanding is wrong
:)

Bill Ver Steeg (versteb) wrote:
> This is one of the ways that using TLV for the preamble makes the
server
> simpler.
...

---

From: Roni Even <[email-masked]>
Date: Tue, 20 Apr 2010 19:11:35 +0300

Bill,
I do not know why you claim that there are substantial client manipulation.
I can understand that you have substantial number of implementations since
you try to adapt on the receiver for each hardware/ firmware, chipset. My
view all the time that this processing is not related to how the data is
transferred on the wire and if you think differently please explain. 

As for the PCR issue, I saw that Erik gave the following text
"I'll give an example. The value in  the PCR TOLV is PCR_0. Because of the
rate of the stream, each TS  packet takes 10 ticks of PCR time. If I send
the PCR MPEG2TS packet into the decoder after the PAT & PMT, followed by 3
ECMs, then I must adjust the PCR value in the MPEG2TS packet earlier by 40
ticks to account for its earlier position in the stream"

I am not sure about this.

1. If these numbers are correct than it means that in 10 ticks of 27Mhz
clock you are sending 1504 bits (188*8). This is a bit rate of over 4
Gbit/s. Is this correct
2. The text claims that the position of the PCR packet has changed and it is
now earlier. I am not sure I understand how you know that it is earlier
since you do not have the original order, so why move back by 40 ticks.

Roni Even
As individual

> Sent: Monday, April 19, 2010 3:57 PM
> To: Peilin YANG
> Cc: [email-masked]
> I am less concerned with the Continuity Counter value, and more
> concerned with the clock value. I think we agree that if you change the
> timing relationship between a PCR and the rest of the data, you need to
> change the clock values in the PCR.
> 
> The MPEG specs have detailed requirements for clock timing. You claim
> to be sending compliant MPEG data in the preamble. I am therefore
> assuming that you do a clock fixup on the server prior to sending the
> preamble. As discussed in our previous emails - there is substantial
> client specific manipulation of the preamble, much of which impacts the
> timing. The server can't (more accurately, it becomes very complex)
> know the client specific timing changes. So, you have to redo the
> clocks on the client.
> 
> server, then recalculate the clocks on the client. The obvious answer
> is to not try to use MPEG2TS for the preamble. We send the preamble as
> TLV, and only do the clock fixup once.
> 
> server simpler.
> Yes, the PCR doesn't directly precede every I-frame. The bitstream is
> only a coincidence so that there is no PCR in the preamble.
> The MPEG specification does not require the PCR to directly precede the
> I-frame. There are production systems in the real world that have the
> PCR freewheel with respect to the GOPs. The data can be separated by
> 100s of milliseconds. In other words, the PCR values can occur anywhere
> in the stream relative to the I-frame. If you are testing with a stream
> that happens to have the PCR in front of the I-frame, you will get the
> results you descri
> be.
> 
> 
> For the more general case - If the clocks are not setup prior to
> getting audio/video data, the decoder will not work. If the clock
> values are wrong, the decoder will stutter. If you do not put PCR in
> the burst (and fix up the clock value, if required) some perfectly
> compliant MPEG2TS streams will not be accelerated at all.
> 
> As usual the time of PCR is earlier than the time of PTS of I frame. I
> tested some streams with PCR in the preamble and without PCR in the
> preamble. I found there is no explicit improvement to the time of fast
> channel change with PCR in the preamble compared to without PCR. In
> order to avoid possible effect, we also include PCR in the preamble.
> But in this bitstream PCR information is included in the adapation
> field of IDR frame so that we
>

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 20 Apr 2010 11:17:44 -0500

Roni-

Let's take this one step at a time.

Do you agree that if you change the temporal relationship between the PCR and the I-frame, you need to change the clock value in the PCR?

Bvs

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Tuesday, April 20, 2010 12:12 PM
To: Bill Ver Steeg (versteb); 'Peilin YANG'
Cc: [email-masked]
Subject: RE: [AVT] About post processing for the MPEG2-TS preamble

Bill,

Roni Even
As individual

---

From: Eric Friedrich <[email-masked]>
Date: Tue, 20 Apr 2010 13:43:04 -0400

Roni-
   I just picked some numbers to show the general concept. Don't take  
them to mean a given stream rate :-) I know that the PCR is earlier  
because the PCR in the TOLV is the PCR of the first RAMS unicast  
packet. By definition, the preamble PCR packets must come before the  
RAMS burst and the PCR values must be smaller.

--Eric

---

From: Roni Even <[email-masked]>
Date: Tue, 20 Apr 2010 20:48:01 +0300

Eric,
You are saying that the PCR is of the first RAMS unicast packet. So this
means that the PCR is part of the first RAMS unicast packet. Otherwise the
PCR is the time of the last byte in the PCR packet and not of the first RAMS
unicast packet.

Roni Even

> From: Eric Friedrich [mailto:[email-masked]]
> Sent: Tuesday, April 20, 2010 8:43 PM
> To: Roni Even
> Cc: 'Bill Ver Steeg (versteb)'; 'Peilin YANG'; [email-masked]

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 20 Apr 2010 12:52:54 -0500

The analysis is significantly different if the PCR is not adjacent to the I-Frame in the original stream. The PCR then needs to be in the preamble, and the clocks in the PCR need to be adjusted. From the logic in the previous emails, the clock adjustment needs to be done on the client. You COULD also adjust the clocks in the server to make them MPEG2TS compliant, but you sometimes have to re-adjust them in the client anyway.

Bvs

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Tuesday, April 20, 2010 1:48 PM
To: Eric Friedrich (efriedri)
Cc: Bill Ver Steeg (versteb); 'Peilin YANG'; [email-masked]
Subject: RE: [AVT] About post processing for the MPEG2-TS preamble

Eric,

Roni Even

---

From: Eric Friedrich <[email-masked]>
Date: Tue, 20 Apr 2010 13:58:19 -0400

No, the PCR is not necessarily part of the first RAMS unicast packet.  
The server places a value in the PCR TOLV of the first RAMS packet.  
This PCR packet doesn't actually exist in the RAMS burst, the server  
estimates what the correct value is. Using this knowledge, the post- 
processing algorithm adjusts the PCR TOLV value so that it correctly  
represents the first byte of the generated preamble PCR packet.

--Eric

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 20 Apr 2010 13:06:38 -0500

Roni-

This is the difference we found when we looked at the sample stream.

If the PCR is adjacent to the I-Frame, the scheme you reference would work fine. However, the PCR and GOP structure are not mandated by the MPEG2TS specification to be sequential. In the wild, there are lots of streams with 100s of ms of slop. In order to accelerate the flow without artifacts, the PCR clock values have to be in the preamble. When you fool around with timing, the clocks need to be set by the client. I am not sure how else to describe this........

Bvs

-----Original Message-----
From: Eric Friedrich (efriedri) 
Sent: Tuesday, April 20, 2010 1:58 PM
To: Roni Even
Cc: Bill Ver Steeg (versteb); 'Peilin YANG'; [email-masked]
Subject: Re: [AVT] About post processing for the MPEG2-TS preamble

--Eric

---

From: Roni Even <[email-masked]>
Date: Tue, 20 Apr 2010 22:45:21 +0300

Hi Bill,
I will try to clarify my understanding of the timing issue in MPEG2-TS. This
is not related to any implementation but to the MPEG2-TS standard.

First of all the PCR clock may be adjusted, it is not mandatory according to
MPEG2-TS and note that the distance between two PCRs must be smaller than 0.
1 sec. The PCR is used to feed the MPEG2-TS buffer from the RTP buffer
according to the bit rate based on the PCR but until you have the next one
you do not really know it. If this buffer is big enough there is no problem
and according to RAMS it should be to allow the burst. The other usage is
for synchronization between audio and video and display time with the PTS if
exists. In the RAMS case you are trying to catch up so you may have some non
synchronization for the first 0.1 sec.

Now if you want to adjust it on the client side you need to know the
relative byte positions of the PCR and the first RAMS packet to adjust the
time. Using the position with regards to the first RAMS packet like Erik
explained does not fix the PCR even for the example he gave since he does
not know the PCR position except for the case where the PCR was directly
before the RAMS first packet and the receiver does not know it

Roni

> From: Bill Ver Steeg (versteb) [mailto:[email-masked]]
> Sent: Tuesday, April 20, 2010 8:53 PM
> To: Roni Even; Eric Friedrich (efriedri)
> The analysis is significantly different if the PCR is not adjacent to
> the I-Frame in the original stream. The PCR then needs to be in the
> preamble, and the clocks in the PCR need to be adjusted. From the logic
> in the previous emails, the clock adjustment needs to be done on the
> client. You COULD also adjust the clocks in the server to make them
> MPEG2TS compliant, but you sometimes have to re-adjust them in the
> client anyway.
> 
> 
> Bvs
> 
> 
> > > I can understand that you have substantial number of
> implementations
> > > since
> > > rate of the stream, each TS  packet takes 10 ticks of PCR time. If
> I
> > > send
> > > ECMs, then I must adjust the PCR value in the MPEG2TS packet
> earlier
> > > by 40
> > >> concerned with the clock value. I think we agree that if you
> change
> > >> the
> > >> client specific manipulation of the preamble, much of which
> impacts
> > >> the
> > >> is to not try to use MPEG2TS for the preamble. We send the
> preamble
> > >> as
> > >> The MPEG specification does not require the PCR to directly
> precede
> > >> the

---

From: Roni Even <[email-masked]>
Date: Tue, 20 Apr 2010 22:50:01 +0300

WARNING: contains banned part

Subject: RE: [AVT] About post processing for the MPEG2-TS preamble
From: Roni Even <[email-masked]>
To: "'Bill Ver Steeg (versteb)'" <[email-masked]>, "'Eric Friedrich (efriedri)'" <[email-masked]>
Cc: 'Peilin YANG' <[email-masked]>, [email-masked]
Date: Tue, 20 Apr 2010 22:50:01 +0300

Bill,

This is the MPEG2-TS requirement from PCR

2.7.2 Frequency of coding the program clock reference

The Transport Stream shall be constructed such that the time interval between the bytes containing the last bit of program_clock_reference_base fields in successive occurrences of the PCRs in Transport Stream packets of the PCR_PID for each program shall be less than or equal to 0.1 s. Thus:

for all i and i¢ where i and i¢ are the indexes of the bytes containing the last bit of consecutive program_clock_reference_base fields in the Transport Stream packets of the PCR_PID for each program.

It is not 100s, it should be less than 0.1 sec

Roni Even

> Sent: Tuesday, April 20, 2010 9:07 PM

> To: Eric Friedrich (efriedri); Roni Even

> If the PCR is adjacent to the I-Frame, the scheme you reference would

> work fine. However, the PCR and GOP structure are not mandated by the

> MPEG2TS specification to be sequential. In the wild, there are lots of

> streams with 100s of ms of slop. In order to accelerate the flow

> without artifacts, the PCR clock values have to be in the preamble.

> When you fool around with timing, the clocks need to be set by the

> client. I am not sure how else to describe this........

> > You are saying that the PCR is of the first RAMS unicast packet. So

> > this

> > means that the PCR is part of the first RAMS unicast packet.

> > Otherwise the

> > PCR is the time of the last byte in the PCR packet and not of the

> > first RAMS

> >>> I do not know why you claim that there are substantial client

> >>> manipulation.

> >>> you try to adapt on the receiver for each hardware/ firmware,

> >>> chipset. My

> >>> view all the time that this processing is not related to how the

> >>> data is

> >>> transferred on the wire and if you think differently please

> explain.

> >>> "I'll give an example. The value in  the PCR TOLV is PCR_0. Because

> >>> of the

> >>> the PCR MPEG2TS packet into the decoder after the PAT & PMT,

> >>> followed by 3

> >>> 1. If these numbers are correct than it means that in 10 ticks of

> >>> 27Mhz

> >>> clock you are sending 1504 bits (188*8). This is a bit rate of

> >>> over 4

> >>> 2. The text claims that the position of the PCR packet has changed

> >>> and it is

> >>> now earlier. I am not sure I understand how you know that it is

> >>> since you do not have the original order, so why move back by 40

> >>> ticks.

> >>>> From: [email-masked] [mailto:[email-masked]] On Behalf

> >> Of

> >>>> timing relationship between a PCR and the rest of the data, you

> >>>> need to

> >>>> The MPEG specs have detailed requirements for clock timing. You

> >> claim

> >>>> assuming that you do a clock fixup on the server prior to sending

> >>>> preamble. As discussed in our previous emails - there is

> >>>> substantial

> >>>> timing. The server can't (more accurately, it becomes very

> complex)

> >>>> It is not clear to me why you would calculate a PCR clock value on

> >>>> server, then recalculate the clocks on the client. The obvious

> >> answer

> >>>> Yes, the PCR doesn't directly precede every I-frame. The bitstream

> >> is

> >>>> 抄送: "Eric Friedrich (efriedri)" <[email-masked]>,

> >>>> I-frame. There are production systems in the real world that have

> >>>> PCR freewheel with respect to the GOPs. The data can be separated

> >>>> by

> >>>> 100s of milliseconds. In other words, the PCR values can occur

> >>>> anywhere

> >>>> in the stream relative to the I-frame. If you are testing with a

> >>>> stream

> >>>> that happens to have the PCR in front of the I-frame, you will get

> >>>> values are wrong, the decoder will stutter. If you do not put PCR

> >>>> in

> >>>> As usual the time of PCR is earlier than the time of PTS of I

> >>>> frame. I

> >>>> tested some streams with PCR in the preamble and without PCR in

> >>>> preamble. I found there is no explicit improvement to the time of

> >>>> fast

> >>>> channel change with PCR in the preamble compared to without PCR.

> In

> >>>> order to avoid possible effect, we also include PCR in the

---

From: Roni Even <[email-masked]>
Date: Tue, 20 Apr 2010 22:56:27 +0300

Tom,
The begen draft requires the server to adjust the PCR see from Eric's
response. 

"No, the PCR is not necessarily part of the first RAMS unicast packet.  
The server places a value in the PCR TOLV of the first RAMS packet.  
This PCR packet doesn't actually exist in the RAMS burst, the server
estimates what the correct value is. Using this knowledge, the post-
processing algorithm adjusts the PCR TOLV value so that it correctly
represents the first byte of the generated preamble PCR packet."

Roni

> Tom Taylor
> Sent: Tuesday, April 20, 2010 6:29 PM
> concerned
> to be
> is to

---

From: Roni Even <[email-masked]>
Date: Tue, 20 Apr 2010 22:59:12 +0300

Hi Eric,
I am not sure what estimate means, you need to get the latest PCR before the
first RAMS packet in the RS and add the number of ticks till the first RAMS
packet in order to get the right value in the PCR. For that you need to
calculate the bit rate of the stream using two consecutive PCRs
Roni

> Sent: Tuesday, April 20, 2010 8:58 PM
> To: Roni Even

---

From: Eric Friedrich <[email-masked]>
Date: Tue, 20 Apr 2010 16:01:18 -0400

Hi Roni-
    You may need to correct my understanding of RAMS, but is it not  
the RTP timestamp that controls when a packet is fed from the RTP  
buffer to the MPEG2-TS buffer? Also, I agree that the PCR is used for  
A/V synchronization, although it is possible that an incorrect PCR  
value can cause problems for much longer that .1sec. It may take  
longer than .1sec, because the decoder's clock may not make a large  
jump to adjust to the PCR, it may adjust over time. Similarly, the PCR  
is also used to adjust the amount of data in the decoder's buffers.  
Getting the PCR wrong here can lead to issues with buffer fullness  
(either overfilling or underfilling).

I'm not sure how much more I can clarify the adjustment of the PCR,  
however you can see for yourself that it does work from the pcap I  
posted last week. The post-processing in all cases knows the PCR value  
of the first byte of the RAMS burst (even when there is not a PCR  
associated with that packet). Knowing both the value and location  
allow the post-processing to correctly create the other PCR packets  
needed for priming the decoder.
--Eric

On Apr 20, 2010, at 3:45 PM, Roni Even wrote:

>> Otherwise
>> first
>> RAMS

---

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

> buffer to the MPEG2-TS buffer?
 
Correct.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Wed, 21 Apr 2010 00:50:31 +0300

Hi Eric,

My understanding is that RFC 2250 has a different use for the RTP time stamp
than other payload
" The RTP timestamp will not be passed to the MPEG
   decoder.  This use of the timestamp is somewhat different than
   normally is the case in RTP, in that it is not considered to be the
   media display or presentation timestamp. The primary purposes of the
   RTP timestamp will be to estimate and reduce any network-induced
   jitter and to synchronize relative time drift between the transmitter
   and receiver."

The PCR is used in MPEG2-TS  and not the RTP time stamp to fill the buffers
at the correct rate so no overflow will happen.
I thought that in RAMS the buffer fullness is handled by the RAMS-R using
the max RAMS buffer fill requirement parameter.

Now I was not saying that you do not need to adjust the PCR but that it will
work also if you do not adjust it.

I understand how you are adjusting it but like you said, it requires the RS
to adjust the PCR to the time of the first byte of the burst, so processing
is done also on the RS.

Roni

> Eric Friedrich
> Sent: Tuesday, April 20, 2010 11:01 PM
> To: Roni Even
> Cc: [email-masked]; 'Bill Ver Steeg (versteb)'
> over
> >> 4

---

From: Peilin YANG <[email-masked]>
Date: Wed, 21 Apr 2010 17:33:24 +0800

Hi Eric,

In our implementation, we obey CCs of original MPEG2-TS for PCR because CCs of PCR aren't always continuous. Some cases are continuous. some cases are not.
When PCR share its PID with video, CCs of PCR are also CCs of video. CCs of video are continous, CCs of all PCR TS packets are discontinous. In the preamble,it adjusts CCs correctly between the first TS packet of I frame and PCR TS packet. 

When PCR has its own PID, we comply with original MPEG2-TS for PCR from primary multicast stream. If CCs of PCR are discontinous, CC of PCR in the preamble is the same as original MPEG2-TS for PCR. Assume that all CCs of PCR is set to 0, CC of PCR in the preamble is also set to 0.

Peilin

----- 原邮件 -----
发件人: Eric Friedrich <[email-masked]>
日期: 星期五, 四月 16日, 2010 下午8:42
主题: Re: About post processing for the MPEG2-TS preamble
收件人: Peilin YANG <[email-masked]>
抄送: "Ali C. Begen (abegen)" <[email-masked]>, [email-masked]

Hi Peilin-

--Eric