Subject: [AVT] Preamble follow-up

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 25 Mar 2010 10:58:36 -0700

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.

---

From: Peilin YANG <[email-masked]>
Date: Fri, 26 Mar 2010 05:07:48 +0800

Hi,
 
I am sorry I have to iterate once again though I repeated it several times - In our deployments our solution works well. 
But the one thing I am not clear is that why you suspect it until now. In fact, in your previous email you said you did it in both ways - I don't know if it is true or not. 
Undoubtedly our solution is very simple, what's more, the STBs don't need to be upgraded to handle the new format.

Peilin

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

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.

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 str
eam 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.

Cheers, acbegen.

---

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

> -----Original Message-----
> From: Peilin YANG [mailto:[email-masked]]
> Sent: Thursday, March 25, 2010 2:08 PM
> To: Ali C. Begen (abegen)
> Cc: [email-masked]
> Subject: re:[AVT] Preamble follow-up
> 
> Hi,
> 

Unfortunately, this statement (regardless of whether it comes from you or us) would not help much in the current process. That's why, we shared our code. If you do the same, folks will be able to make a better decision.

> But the one thing I am not clear is that why you suspect it until now. In fact, in your previous email
> you said you did it in both ways - I don't know if it is true or not.

Sorry, I don't understand what you mean above. I asked a specific question in my email below and am still waiting for an answer. Do you modify TS packets (i.e., post process them) or not? Yes or no?

> Undoubtedly our solution is very simple, what's more, the STBs don't need to be upgraded to handle the

Any STB software will need to be updated anyway to reflect the RAMS client code when the draft is finalized. The post processing code will be part of that client code, so there is no deployment problem that I can see. 

-acbegen

> 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 str
> eam 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.