Re: [MMUSIC] Remarks from today
Bert Greevenbosch <Bert.Greevenbosch@huawei.com> Fri, 15 April 2011 06:21 UTC
Return-Path: <Bert.Greevenbosch@huawei.com>
X-Original-To: mmusic@ietfc.amsl.com
Delivered-To: mmusic@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E5E20E069D for <mmusic@ietfc.amsl.com>; Thu, 14 Apr 2011 23:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.563
X-Spam-Level:
X-Spam-Status: No, score=-4.563 tagged_above=-999 required=5 tests=[AWL=2.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jqghj8hjDPWM for <mmusic@ietfc.amsl.com>; Thu, 14 Apr 2011 23:21:36 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id A09FCE0693 for <mmusic@ietf.org>; Thu, 14 Apr 2011 23:21:35 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO001W5KBQIT@szxga04-in.huawei.com> for mmusic@ietf.org; Fri, 15 Apr 2011 14:21:26 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO00CQMKBQWI@szxga04-in.huawei.com> for mmusic@ietf.org; Fri, 15 Apr 2011 14:21:26 +0800 (CST)
Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Apr 2011 14:21:09 +0800
Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Fri, 15 Apr 2011 14:21:24 +0800
Date: Fri, 15 Apr 2011 06:21:24 +0000
From: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
In-reply-to: <BANLkTi==gPXY+=rOa_n3R0wWjtdy-jP3yA@mail.gmail.com>
X-Originating-IP: [10.70.109.52]
To: Ted Hardie <ted.ietf@gmail.com>
Message-id: <46A1DF3F04371240B504290A071B4DB6012C4B09@SZXEML501-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_S0ZqtuDCI19y4dUVviax7g)"
Content-language: en-US
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: [MMUSIC] Remarks from today
Thread-index: AcvwXoOgE0DCkTRQQHKEX80+mhJGZf//kNYA//ZfEUCAFPgEAP/7eJRwgAqv/YD//mkrcACdjgWA//69IJA=
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <46A1DF3F04371240B504290A071B4DB6012B2389@szxeml501-mbx.china.huawei.com> <19861.51136.463433.972475@irtcluster12.cs.columbia.edu> <46A1DF3F04371240B504290A071B4DB6012C2EFF@SZXEML501-MBS.china.huawei.com> <BANLkTikFyudyfqS90R3rL+ZTZJ2sgBayzw@mail.gmail.com> <46A1DF3F04371240B504290A071B4DB6012C3A46@SZXEML501-MBS.china.huawei.com> <BANLkTi=FuMJYvUN1dnzw0MxQWokcynnZUg@mail.gmail.com> <46A1DF3F04371240B504290A071B4DB6012C43B9@SZXEML501-MBS.china.huawei.com> <BANLkTi==gPXY+=rOa_n3R0wWjtdy-jP3yA@mail.gmail.com>
Cc: "lennox@cs.columbia.edu" <lennox@cs.columbia.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Remarks from today
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 06:21:38 -0000
Hi Ted, My suspicion is that there are probably practical limits to some system's ability to either upsample or interpolate. Would it make sense to add something to the 3dFormat line to indicate what the resulting per-view rate will be? So that a=3dFormat:FP SbS had an additional parameter: a=3dFormat:FP SbS 30Hz We could also consider using the SDP attribute "framerate" (RFC 4566). This attribute would give the frame rate of the 2D channel stream, but we can write in the draft that in the frame sequential case the frame rate per view is half of it. Or do you want to indicate the target shutter glass frequency? Best regards, Bert From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 15 April 2011 02:49 To: Bert Greevenbosch Cc: lennox@cs.columbia.edu; mmusic@ietf.org Subject: Re: [MMUSIC] Remarks from today On Wed, Apr 13, 2011 at 10:44 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com<mailto:Bert.Greevenbosch@huawei.com>> wrote: I agree, the 30Hz (per view) case would give a flickering effect. Since normal TVs have a frequency of 60Hz or more, for a similar quality with shutter glasses the frame rate should be 120Hz (=60 Hz/view) or more. But the receiver can also upsample the received signal to a higher display rate. For example, if it receives the following frame sequence at 30Hz/view: L1,R1,L2,R2,L3,R3,..., then it could display at 60Hz/view: L1,R1,L1,R1,L2,R2,L2,R2,L3,R3,L3,R3,.... The receiver can also use some interpolation technique to generate the frames between Lk and L(k+1). I think that in praxis the receiving device will process the received stream to make it fit the display system. This allows different types/standards of shutter glasses to be used, independent on the format in which the 3D stream was received. It also allows other display types such as polarisation or autostereoscopic displays. My suspicion is that there are probably practical limits to some system's ability to either upsample or interpolate. Would it make sense to add something to the 3dFormat line to indicate what the resulting per-view rate will be? So that a=3dFormat:FP SbS had an additional parameter: a=3dFormat:FP SbS 30Hz >I know only know one manufacturer's system at all well, and my understanding is that the timing signals which synchronize them are really matching the frame start times to the shuttering, but don't adjust the frame rates. Are there glasses which can modify the rate substantially as well? Can you please explain a bit more about the system you are referring too, especially about not modifying the frame rate? Do you mean the frame rate between the TV screen and the signalling device (that transmits the signal to the shutter glasses) or the frame rate of the video stream as it is received before it is decoded (by the codec)? I probably should have said "shuttering rate", sorry. I mean that it matches the shutters to the alternating left and right view, but that the shuttering rate is consistent (resulting in 60Hz per view, in this case). regards, Ted Hardie
- [MMUSIC] Remarks from today Bert Greevenbosch
- Re: [MMUSIC] Remarks from today lennox
- Re: [MMUSIC] Remarks from today Roni Even
- Re: [MMUSIC] Remarks from today Bert Greevenbosch
- Re: [MMUSIC] Remarks from today Ted Hardie
- Re: [MMUSIC] Remarks from today Bert Greevenbosch
- Re: [MMUSIC] Remarks from today Ted Hardie
- Re: [MMUSIC] Remarks from today Bert Greevenbosch
- Re: [MMUSIC] Remarks from today Ted Hardie
- Re: [MMUSIC] Remarks from today Bert Greevenbosch
- Re: [MMUSIC] Remarks from today Ted Hardie
- Re: [MMUSIC] Remarks from today Bert Greevenbosch
- Re: [MMUSIC] Remarks from today Ted Hardie
- Re: [MMUSIC] Remarks from today Stephen Botzko
- Re: [MMUSIC] Remarks from today Bert Greevenbosch
- Re: [MMUSIC] Remarks from today Stephen Botzko