Re: [AVT] MPEG2-TS preamble - client customization
Peilin YANG <yangpeilin@huawei.com> Mon, 22 March 2010 22:28 UTC
Return-Path: <yangpeilin@huawei.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9FBF3A6982 for <avt@core3.amsl.com>; Mon, 22 Mar 2010 15:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.473
X-Spam-Level: ***
X-Spam-Status: No, score=3.473 tagged_above=-999 required=5 tests=[AWL=2.153, BAYES_00=-2.599, CN_BODY_35=0.339, DNS_FROM_OPENWHOIS=1.13, MIME_CHARSET_FARAWAY=2.45]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whRKDayiXZ3w for <avt@core3.amsl.com>; Mon, 22 Mar 2010 15:28:36 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 80CF13A693F for <avt@ietf.org>; Mon, 22 Mar 2010 15:28:36 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZP00C89FS5JF@szxga01-in.huawei.com> for avt@ietf.org; Tue, 23 Mar 2010 06:28:53 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZP00MJRFS4HC@szxga01-in.huawei.com> for avt@ietf.org; Tue, 23 Mar 2010 06:28:53 +0800 (CST)
Received: from [172.24.1.3] (Forwarded-For: [130.129.28.85]) by szxmc03-in.huawei.com (mshttpd); Tue, 23 Mar 2010 06:28:52 +0800
Date: Tue, 23 Mar 2010 06:28:52 +0800
From: Peilin YANG <yangpeilin@huawei.com>
In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540B9ACACA@xmb-sjc-215.amer.cisco.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
Message-id: <fe6ebefe5102.5102fe6ebefe@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006)
Content-type: text/plain; charset="gb2312"
Content-language: zh-CN
Content-transfer-encoding: quoted-printable
Content-disposition: inline
X-Accept-Language: zh-CN
Priority: normal
References: <fdfc97577647.7647fdfc9757@huawei.com> <1D60293E-F505-46D0-AA87-CAD9021F338E@cisco.com> <002901cac9e4$47046fc0$d50d4f40$%roni@huawei.com> <EE933D92D054D14089A336CC71A5CCA6D16274@XMB-RCD-213.cisco.com> <002701caca07$02f34680$08d9d380$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540B9ACACA@xmb-sjc-215.amer.cisco.com>
Cc: "Dave Oran (oran)" <oran@cisco.com>, "Bill Ver Steeg (versteb)" <versteb@cisco.com>, Roni Even <Even.roni@huawei.com>, avt@ietf.org
Subject: Re: [AVT] MPEG2-TS preamble - client customization
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Mar 2010 22:28:39 -0000
Dear Ali, It is undoubted that the preamble information is needed to demultiplex/decode correctly for receivers. In your solution you use TOLV; Xia draft uses raw TS packets. There is one thing until now I am not exactly clear that if the TOLV format should be converted to TS packet before being fed to demultiplexer/decoder. According to the understanding of a general reader, it should. If the TOLV format should be converted to TS packet before being fed to demultiplex/decode, how is it faster decoding and shorter zapping times than Xia draft? Because Xia draft doesn't need the converting steps and directly feed it to demultiplexer/decoder. Peilin ----- 原邮件 ----- 发件人: "Ali C. Begen (abegen)" <abegen@cisco.com> 日期: 星期二, 三月 23日, 2010 上午5:43 主题: RE: [AVT] MPEG2-TS preamble - client customization 收件人: Roni Even <Even.roni@huawei.com>, "Bill Ver Steeg (versteb)" <versteb@cisco.com>, "Dave Oran (oran)" <oran@cisco.com>, Peilin YANG <yangpeilin@huawei.com> 抄送: avt@ietf.org I truly believe that the first thing we should try to get an agreement on whether a set of decoder-agnostic TS packets sent by the server serves our purpose or not. Our purpose at least in our draft is to get the best out of the preamble, which means faster decoding and shorter zapping times compared to the scenarios where preamble is not used or not optimized. If anybody has a different goal or thinks our goal (as stated above) is not the right goal, it would be a good idea to clarify it as well. Until we get a consensus on this issue, discussing other items is pretty pointless. Once we are done with this issue, we can then decide on the packaging of the preamble (TLV encoding vs raw TS packets). -acbegen > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even > Sent: Monday, March 22, 2010 2:31 PM > To: Bill Ver Steeg (versteb); Dave Oran (oran); 'Peilin YANG' > Cc: avt@ietf.org > Subject: Re: [AVT] MPEG2-TS preamble - client customization > > Bill, > I think that part of the disconnect is that what you describe as option 1 is > interesting but this is not what the Xai draft suggest to do. I am not sure > where the claim that the xia draft does server side adaption is coming from. > I did not see it in the draft nor heard such claim from the authors of the > draft. > > Regards > Roni Even > As Individual > > > -----Original Message----- > > From: Bill Ver Steeg (versteb) [mailto:versteb@cisco.com] > > Sent: Monday, March 22, 2010 7:49 PM > > To: Roni Even; Dave Oran (oran); Peilin YANG > > Cc: avt@ietf.org > > Subject: RE: [AVT] MPEG2-TS preamble - client customization > > > > Roni- > > > > Sorry I was not clear. There is a body of best practices in use in the > > digital video world, which I did not elaborate very well. > > > > Care must be taken to minimize CPU load, and particularly to minimize > > bursts of CPU load when channel change events cluster around > > commercials > > and event boundaries. So, we need to consider client complexity and > > server complexity in this analysis. We need to be with resource > > utilization, particularly peak CPU load. During channel change, the > > client device's CPU is typically at the edge of its performance > > envelope. During top-of-the-hour correlated channel change, the server > > also tends to be at the edge of its performance envelope. We need to > > minimize real-time resource utilization. > > > > During the steady-state stream ingest process the server has to parse > > MPEG2TS and locally store the various data elements. It then has two > > options in real time when it gets the channel change request - > > > > Option 1- The server can regenerate a compliant MPEG2TS bitstream and > > send it to the client, where it is re-parsed into its component > > elements > > and locally processed (along with the local keys and device specific > > behavior). Note that the MPEG2TS regeneration process has to happen > > when > > the RAMS request comes in, and thus can cause severe resource spikes > > during top-of-the hour events. > > > > Option 2- The server can send the parsed data in TLV format, removing > > the extra step of MPEG2TS generation on the server and subsequent > > re-parsing on the client. > > > > The local key handling and device specific behavior are common to both > > cases. They are described here to highlight that the server can't > > reduce > > client load because there is significant client specific behavior. > > > > These are subtle points that drive significant scaling differences, and > > may be best handled by walking through an example. The most demanding > > (and thus most useful) case is when changing channels on a simulcrypt > > system between channels that use different CAS systems. > > > > Once again, I want to be sure we get the best algorithm, and I welcome > > a > > detailed examination of the alternative solutions. > > Bvs > > > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > > Roni Even > > Sent: Monday, March 22, 2010 10:23 AM > > To: Dave Oran (oran); 'Peilin YANG' > > Cc: avt@ietf.org > > Subject: Re: [AVT] MPEG2-TS preamble - client customization > > > > Hi Dave, > > I think that what Peilin said has to do with the receiver understanding > > of > > the data format and not about the post processing if it is needed. > > Roni Even > > > > > -----Original Message----- > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > > > David R Oran > > > Sent: Monday, March 22, 2010 6:55 PM > > > To: Peilin YANG > > > Cc: avt@ietf.org > > > Subject: Re: [AVT] MPEG2-TS preamble - client customization > > > > > > > > > On Mar 22, 2010, at 12:51 PM, Peilin YANG wrote: > > > > > > > Hi, > > > > > > > > I would like to try and clarify my meaning on client customization > > > since it looks like there are some misunderstanding. > > > > Our product solution does not require any customization on the > > client > > > side and we feed the MPEG2-TS stream directly to the MPEG2-TS > > > demultiplexer /decoder. > > > > Still the Xia preamble draft does not say that it is not allowed to > > > do client customization if needed. We think that this is is a post > > > processing topic that is external to the transport of the preamble > > > information. > > > > From the discussion on the list we see that this post processing > > may > > > also be needed in regular MPEG2-TS receivers without even having the > > > RAMS support. > > > > I think that this implies that these receivers know how to take an > > > MPEG2-TS stream and restructure it before feeding it to the > > > demultiplexer. So this demonstrates that receivers can know how to > > > handle the RFC 2250 / MPEG2-TS structures in the post processing and > > > they will be able to support the preamble according to the Xia draft > > > easily if needed. > > > Did you miss my analysis showing that the steady-state and startup > > > behavior of decoders is known to be different? That is what accounts > > > for not needing to mess with the content/timing of the transport > > stream > > > in the absence of RAMS. So, I don't think the implication you > > speculate > > > about above holds. > > > > > > Cheers, DaveO. > > > > > > > > > > > > > > > > > Peilin Yang > > > > > > > > _______________________________________________ > > > > Audio/Video Transport Working Group > > > > avt@ietf.org > > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt
- Re: [AVT] MPEG2-TS preamble - client customization Bill Ver Steeg (versteb)
- [AVT] MPEG2-TS preamble - client customization Peilin YANG
- Re: [AVT] MPEG2-TS preamble - client customization David R Oran
- Re: [AVT] MPEG2-TS preamble - client customization Roni Even
- Re: [AVT] MPEG2-TS preamble - client customization Roni Even
- Re: [AVT] MPEG2-TS preamble - client customization David R Oran
- Re: [AVT] MPEG2-TS preamble - client customization Bill Ver Steeg (versteb)
- Re: [AVT] MPEG2-TS preamble - client customization David R Oran
- Re: [AVT] MPEG2-TS preamble - client customization Roni Even
- Re: [AVT] MPEG2-TS preamble - client customization Ali C. Begen (abegen)
- Re: [AVT] MPEG2-TS preamble - client customization Roni Even
- Re: [AVT] MPEG2-TS preamble - client customization Peilin YANG
- Re: [AVT] MPEG2-TS preamble - client customization Ali C. Begen (abegen)
- Re: [AVT] MPEG2-TS preamble - client customization Tom Taylor
- Re: [AVT] MPEG2-TS preamble - client customization Roni Even
- Re: [AVT] MPEG2-TS preamble - client customization David R Oran
- Re: [AVT] MPEG2-TS preamble - client customization Peilin YANG
- Re: [AVT] MPEG2-TS preamble - client customization Allison, Art
- Re: [AVT] MPEG2-TS preamble - client customization Ning Zong
- Re: [AVT] MPEG2-TS preamble - client customization Allison, Art
- Re: [AVT] MPEG2-TS preamble - client customization Bill Ver Steeg (versteb)
- Re: [AVT] MPEG2-TS preamble - client customization Frank Xia