[MMUSIC] Comments on draft-greevenbosch-mmusic-signal-3d-format-01

"Pedro Capelastegui" <capelastegui@dit.upm.es> Sat, 15 October 2011 13:49 UTC

Return-Path: <capelastegui@dit.upm.es>
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 25BE021F8B54 for <mmusic@ietfa.amsl.com>; Sat, 15 Oct 2011 06:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 esT+-UeEAwPD for <mmusic@ietfa.amsl.com>; Sat, 15 Oct 2011 06:49:07 -0700 (PDT)
Received: from mail.dit.upm.es (mail.dit.upm.es [138.4.2.7]) by ietfa.amsl.com (Postfix) with ESMTP id 537D521F8B48 for <mmusic@ietf.org>; Sat, 15 Oct 2011 06:49:05 -0700 (PDT)
Received: from correo.dit.upm.es (correo.dit.upm.es [IPv6:2001:720:1500:42:250:56ff:fea2:1a03]) by mail.dit.upm.es (8.14.2/8.14.2) with ESMTP id p9EGI7U5007989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2011 18:18:07 +0200
Received: from delta (delta.dit.upm.es [138.4.7.204]) (authenticated bits=0) by correo.dit.upm.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9EGHr9w002491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Oct 2011 18:17:55 +0200
From: Pedro Capelastegui <capelastegui@dit.upm.es>
To: 'IETF - MMUSIC' <mmusic@ietf.org>, 'Bert Greevenbosch' <Bert.Greevenbosch@huawei.com>
Date: Fri, 14 Oct 2011 18:18:10 +0200
Message-ID: <000f01cc8a8c$dfb1fca0$9f15f5e0$@dit.upm.es>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CC8A9D.A33CC870"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcyKijb4TtB/B1/kTfyPYAoYdFul1g==
Content-Language: es
Subject: [MMUSIC] Comments on draft-greevenbosch-mmusic-signal-3d-format-01
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: Sat, 15 Oct 2011 13:49:08 -0000

Hi,

 

I have reviewed draft-greevenbosch-mmusic-signal-3d-format-01, and I have the following comments.

 

                - Backwards compatibility

 

When a 3D-enabled device using this specification calls a legacy device, it is very likely that the answerer will accept the session and end up receiving media that it can’t display properly, such as frame-packed video or a depth map. I think the default behaviour here should be that whenever the SDP answer omits the 3dFormat attribute, the offerer only sends 2D video (if available), avoiding further offers if possible. This speeds up session setup with legacy agents, and prevents transmitting useless media.

 

To implement this change, I would modify a few paragraphs in section 8.

 

In 8.1 (Frame Packing), replace:

 

“the offerer MAY update the offer with a 2D stream.  If the offerer is the streaming server, it  MAY choose to stream the frame packed video as it is.“

 

with

 

“the offerer SHOULD treat that media stream as a 2D stream.”

 

In 8.2 (2D and auxiliary as a single stream), replace:

                

“ the offerer MAY update its offer by offering only a 2D  video stream.”

 

with

                

“SHOULD treat that media stream as a 2D stream.”

 

In 8.3 (2D and auxiliary as two separate streams), replace:

                

" If the answerer selects only the auxiliary video, the offerer  SHOULD update its offer without the auxiliary video."

 

with

                

"If the answerer selects only the auxiliary video, the offerer  MAY treat that stream as a 2D video stream. If it does not, the offerer SHOULD update its offer without the auxiliary video."

 

 

                - H.264/MVC

 

I think that compatibility with the MVC format is a must for this specification. This will probably require defining new types of 3D formats and components. Unfortunately, the payload format for MVC (draft-ietf-payload-rtp-mvc-0) is still unfinished, with most of the SDP section missing…

 

 

                - Depth Maps in auxiliary streams.

 

Some transmission options use a single stream containing one view (centre or left) and its associated depth map (or parallax map). However, there is no mention as to how the view and map are packed in that stream. I suppose the specification assumes the use of the auxiliary data format defined in MPEG-C part 3, but this should probably be indicated explicitly.

 

Also, perhaps the “2DA” format should leave the door open to alternate packing mechanisms other than MPEG-C part 3. I don’t know of any currently existing alternatives, but it is not unreasonable to expect them at some point in the future.

 

                

                - Parallax Maps

 

The draft provides no reference for the use of parallax maps, so it’s probably worth mentioning that they are defined, like depth maps, in [ISO/IEC 23002-3]. Also, I have not found any examples of 3D video applications based on parallax maps in the literature.  How likely is it that this scenario will see actual use?

 

 

                - Frame Sequential packing

 

I think that the mechanism for identifying L- and R- streams in a frame sequential stream should be clearly explained.

 

 

                - Multiple 3D streams

 

On page 14, it says that “The answerer SHOULD select only one 3D format”. This means that, for any given session, only one 3D video stream can be used. I think this is too limiting, since it prevents describing sessions where one agent has multiple 3D displays, among others. 

 

 

                - Multiple Depth Maps.

 

The document assumes that depth maps will only be used in 2D+depth streams. However, I think that the combination of multiple views and depth maps (e.g. L/R views and 2 depth maps) is an interesting scenario that may deserve consideration.

 

 

Regards,

Pedro

 

 

---------------------------------------------------------------------------

 

Pedro Capelastegui

Researcher

Universidad Politécnica de Madrid