Re: [MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-signal-3d-format
Bert Greevenbosch <Bert.Greevenbosch@huawei.com> Tue, 15 November 2011 08:01 UTC
Return-Path: <Bert.Greevenbosch@huawei.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD101F0C3E for <mmusic@ietfa.amsl.com>; Tue, 15 Nov 2011 00:01:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.798
X-Spam-Level:
X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[AWL=-1.799, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmmlNQlc4Zoa for <mmusic@ietfa.amsl.com>; Tue, 15 Nov 2011 00:01:33 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E78601F0C45 for <mmusic@ietf.org>; Tue, 15 Nov 2011 00:01:32 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUO00LEEZK50G@szxga03-in.huawei.com> for mmusic@ietf.org; Tue, 15 Nov 2011 16:00:05 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUO00E4PZK2LD@szxga03-in.huawei.com> for mmusic@ietf.org; Tue, 15 Nov 2011 16:00:05 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFB22321; Tue, 15 Nov 2011 15:59:58 +0800
Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Nov 2011 15:59:54 +0800
Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.220]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0323.003; Tue, 15 Nov 2011 15:59:50 +0800
Date: Tue, 15 Nov 2011 07:59:50 +0000
From: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
In-reply-to: <002901cc9a46$771e6290$655b27b0$@dit.upm.es>
X-Originating-IP: [172.24.2.41]
To: Pedro Capelastegui <capelastegui@dit.upm.es>, 'IETF - MMUSIC' <mmusic@ietf.org>
Message-id: <46A1DF3F04371240B504290A071B4DB6231D5D12@szxeml509-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="Windows-1252"
Content-language: en-GB
Content-transfer-encoding: quoted-printable
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: [MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-signal-3d-format
Thread-index: AQHMmkZ8AmjgMGjWwkSMesWVKCSrNpWtjCH/
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
References: <002801cc9a45$69afeda0$3d0fc8e0$@dit.upm.es> <002901cc9a46$771e6290$655b27b0$@dit.upm.es>
Subject: Re: [MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-signal-3d-format
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: Tue, 15 Nov 2011 08:01:34 -0000
Hi Pedro, Sorry for my late response; I have been quite busy lately. Thanks for your e-mail, and for thinking with us about how to move forward with the 3D drafts. To summarise your proposal: (1) Point at multiple possible video streams in a single media "m=" line (i.e. a group of video streams per one media line; I'll call that a "media group"). (2) Stipulate that per media group, only one video stream can be chosen. (3) In one of the media groups, use the "depend" attribute to indicate which video streams are associated with which video streams from the other media group(s). (4) Use "3DS" grouping + "mid" attribute to label the media groups; needed for the "depend" attribute. (5) Use the payload type to differentiate the streams within a media group. I have thought about your proposal, and the following issues arose: (A) The usage of the payload type requires a different payload type for each video stream. This is OK for streams that use a dynamic payload type. However, certain RTP streams have fixed payload types. For example, MPEG-2 video over MPEG Transport Stream over RTP has fixed payload type 33. With your proposal, it is not possible to do 3D simulcast of L- and R-streams in MPEG-2. (B) It is true, that the number of "m=" lines in your proposal is less than in the current draft. But this is only a virtual reduction, as now multiple video streams are advertised in a single media line. In principle, the same number of video streams is advertised. (C) With your proposal, in addition to the "3DS" grouping and the "3dFormat" attribute, the "depend" attribute needs also be supported, with the particular meaning as you have defined it. (D) Does having less "m=" lines justify the additional complexity of using the "depend" attribute? (E) What if different video streams in the same media group require different SDP attributes? What do you think? Best regards, Bert ________________________________________ From: Pedro Capelastegui [capelastegui@dit.upm.es] Sent: 04 November 2011 00:34 To: 'IETF - MMUSIC'; Bert Greevenbosch Subject: RE: [MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-signal-3d-format Hi, In the previous post, I argued against the 3D format negotiation mechanism currently used in draft-greevenbosch-mmusic-signal-3d-format, and suggested associating 3D formats with payload types instead. Here I explain how this could be achieved. The process could be summarized as follows: 3d format configuration parameters are described in media level attributes (like in the current draft), but these attributes have a payload type as an additional parameter: a=3dformat:<Payload_Type> <3dformat parameters> Each 3D media stream will be composed of one or two media descriptions, each with one or more 3d format attributes. For each media description, an answerer would select one of the available media formats, with the preferred combination of codec and 3d format. In order to keep complexity manageable, the answerer would only be allowed to choose a single media format when 3d is enabled. This still leaves us with the problem of declaring dependencies between media descriptions within a 3D media stream (e.g. stream B is the depth map of stream A, or stream B is the right view and stream A is the left one). This could be signaled with the ‘a=depend’ attribute (see RFC 5583). As an example, here is how this system would work in the scenario shown in section 9.4 of draft-greevenbosch-mmusic-signal-3d-format. The offerer is trying to initiate a session with a 3D video stream which can have 2 possible configurations: (1) 1 stream for video and one stream for a parallax map (2) 1 stream for the left view and one for the right view. This is what the offer SDP would look like v=0 o=Alice 2890844526 2890842807 IN IP4 131.163.72.4 s=The technology of 3D-TV c=IN IP4 131.164.74.2 t=0 0 a=group:3DS 1 2 m=video 49170 RTP/AVP 99 100 a=rtpmap:99 H264/90000 a=3dFormat:99 2DA C a=rtpmap:100 H264/90000 a=3dFormat:100 SC L a=mid:1 m=video 49172 RTP/AVP 99 100 a=rtpmap:99 H264/90000 a=3dFormat:99 2DA P a=rtpmap:100 H264/90000 a=3dFormat:100 SC R a=mid:2 a=depend 99 3dv 1:99; 100 3dv 1:100 m=audio 52890 RTP/AVP 10 a=rtpmap:10 L16/16000/2 ‘3dv’ would be a new dependency-type defined for use with 3d format. The ‘depend’ attribute is tipically used in combination with “DDP” (decoding dependency) groups, though I think using it with “3DS” groups in this scenario wouldn’t go against the specification. This offer SDP has 2 video streams in a 3DS group, each with 2 possible configurations. The first one can be configured as a ‘center’ view in a video+auxiliary map scheme, or as a left view in a simulcast scheme. The second media stream can be configured as a parallax map in a video+aux configuration, or as a right view in a simulcast configuration. Only certain payload type combinations are viable, which is signaled in the ‘a=depend’ line: video stream 2 can only be configured as a parallax map if video stream 1 is the center view, and it can only be configured as a right view if stream 1 is the left view. The SDP answer would look like this, if the answerer chooses the "center view plus parallax map" option: v=0 o=Bob 2890844528 2890842809 IN IP4 131.163.72.5 s=The technology of 3D-TV c=IN IP4 131.164.74.3 t=0 0 a=group:3DS 1 2 m=video 48170 RTP/AVP 99 a=rtpmap:99 H264/90000 a=3dFormat:99 2DA C a=mid:1 m=video 48172 RTP/AVP 99 a=rtpmap:99 H264/90000 a=3dFormat:99 2DA P a=mid:2 a=depend 99 3dv 1:99; 100 3dv 1:100 m=audio 52890 RTP/AVP 10 a=rtpmap:10 L16/16000/2 Compared to the SDPs used in draft-greevenbosch-mmusic-signal-3d-format, this offer/answer exchange only uses 3 media descriptions instead of 5. Also, including additional 3D formats would be more simple using this mechanism. Regards, Pedro -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Pedro Capelastegui Sent: Thursday, November 03, 2011 5:27 PM To: IETF - MMUSIC; Bert.Greevenbosch@huawei.com Subject: [MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-signal-3d-format Hi, Here are some further comments on draft-greevenbosch-mmusic-signal-3d-format. These are focused on the 3d format negotiation process, and specifically how the extension behaves when multiple 3d configuration options are offered. My main concern is that, in order to offer alternate 3d format configurations, the offerer has to include additional 'm=' lines in the SDP. Currently, each media descriptor can have a single 3d format, and each 3d format is associated to 1 or 2 media descriptors. This is not an issue in offers with a single 3d format (see examples 9.1, 9.2 and 9.3), but when several 3d formats are offered, the number of media descriptors multiplies. This can be observed in example 9.4, where 4 media descriptors are used in the offer, though the answerer is expected to reject all but two. In general, in order to provide N 3D format options for a 3D video stream,between N and 2N media descriptors will be required in the offered SDP, of which only one or two will be used. I think this proliferation of media descriptions has several drawbacks. For one, it goes against the general philosophy of SDP negotiation. Normally, when different possible configurations exist for a media stream, they are shown as different media formats within a single media descriptor. Using multiple media descriptors that actually refer to the same media stream (the 3D video stream, or a subset of it), and having the answerer reject all but the ones with the desired configuration breaks this model. In addition, this excess of 'm=' lines may have a negative effect when combined with techniques such as ICE, and could be confusing for 3d-unaware nodes. On the other hand, this is only a problem if user agents are expected to select between many 3d formats on an average session. Unfortunately, I think this will be the case. At the very least, a UA starting a 3D session should provide a single 3D format and the option not to use 3D. Apart from that, a 3D user agent intended to be interoperable with other UAs should support several 3D formats, including video+depth and transmission of 2 views. The solution, in my opinion, would be to shift away from the current model and instead associate each 3D format with a payload type within a media description. I will discuss how this can be done in a separate mail. Regards, Pedro _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic ----- No se encontraron virus en este mensaje. Comprobado por AVG - www.avg.com Versión: 10.0.1411 / Base de datos de virus: 2092/3992 - Fecha de publicación: 11/02/11
- [MMUSIC] 3D format negotiation in draft-greevenbo… Pedro Capelastegui
- Re: [MMUSIC] 3D format negotiation in draft-greev… Pedro Capelastegui
- Re: [MMUSIC] 3D format negotiation in draft-greev… Bert Greevenbosch
- Re: [MMUSIC] 3D format negotiation in draft-greev… Pedro Capelastegui