[AVTCORE] Comments on draft-westerlund-avtcore-rtp-simulcast-00

"Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl> Wed, 26 October 2011 07:27 UTC

Return-Path: <ray.vanbrandenburg@tno.nl>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2251021F84D2 for <avt@ietfa.amsl.com>; Wed, 26 Oct 2011 00:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NOfn3kz12NX6 for <avt@ietfa.amsl.com>; Wed, 26 Oct 2011 00:27:26 -0700 (PDT)
Received: from mailouta.tno.nl (mailouta.tno.nl []) by ietfa.amsl.com (Postfix) with ESMTP id ED05521F84CC for <avt@ietf.org>; Wed, 26 Oct 2011 00:27:25 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.69,408,1315173600"; d="scan'208,217"; a="59439495"
Received: from unknown (HELO mail.tno.nl) ([]) by mailhost1a.tno.nl with ESMTP; 26 Oct 2011 09:27:13 +0200
Received: from EXC-MBX03.tsn.tno.nl ([]) by EXC-CASHUB03.tsn.tno.nl ([]) with mapi id 14.01.0323.003; Wed, 26 Oct 2011 09:27:13 +0200
From: "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
To: "avt@ietf.org" <avt@ietf.org>
Thread-Topic: Comments on draft-westerlund-avtcore-rtp-simulcast-00
Thread-Index: AcyTIZ2iVQibSCxwScyjBkbRqff1xw==
Date: Wed, 26 Oct 2011 07:27:13 +0000
Message-ID: <FCC100FC8D6B034CB88CD8173B2DA158155893E1@EXC-MBX03.tsn.tno.nl>
Accept-Language: en-US, nl-NL
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA158155893E1EXCMBX03tsntnon_"
MIME-Version: 1.0
Subject: [AVTCORE] Comments on draft-westerlund-avtcore-rtp-simulcast-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 26 Oct 2011 07:27:29 -0000

Hi Magnus,

I reviewed your draft draft-westerlund-avtcore-rtp-simulcast-00 and have some questions/comments:

-          Section 3: This section lacks a summary/conclusion. A number of different scenarios are introduced, some of which are explicitly stated to be out-of-scope (e.g. 3.5), and some are stated to be in-scope (e.g. 3.3). Some scenarios however (e.g. 3.2) are not specified to be either in- or out-of-scope.

-          Section 3: This section talks quite a bit about the relation between Simulcast and Scalable Coding and in which situations one of the two is more suitable. I'm not sure why this is relevant. Simulcast and Scalable Coding might be two techniques that in some cases can be used to solve the same problem, the layer on which they do this is completely different (codec-level versus transport level). The fact that Scalable Coding might, in some situations, be a better solution than Simulcast does not mean that Simulcast should not be standardized to handle those situations. I understand that you've written this mainly from a video conferencing perspective, in which Scalable Coding might be used more often, but in a lot of situations, such as IPTV, Scalable Coding is just not an option due to its inherent complexity. In these situations Simulcast might be able to solve some real issues, despite the fact that Scalable Coding might be able to solve these issues more efficiently.

-          Section 3.1.1 See comment above. Why is this section relevant to the rest of the document?

-          Section 3.2.1: This scenario is the only one of the scenarios in section 3 to make a clear pro/con of SSRC versus Session based multiplexing. Furthermore, it does so before the actual discussion of SSRC vs. Session-based multiplexing is introduced in section 4.

-          Section 3.3: For the tiled streaming use case described below, this scenario is especially relevant. Is there any technical reason why it has less emphasis than the RTP-Mixer scenario?

-          Section 5.5: Your conclusion here is that Session Based Multiplexing is the best choice, since SSRC multiplexing seems to require a large amount of extensions in order to work. How does this conclusion relate to the draft-lennox-rtcweb-rtp-media-type-mux-00 which seems to suggest that SSRC multiplexing is not that difficult? (I should note that I have no experience with sending multiple streams inside a single RTP session, so it could be that I don't understand the issues correctly)

-          Section 6.2: How do you suggest the sequence numbers and RTP timestamps are handled between multiple alternative streams? Would it make things easier if these were aligned across multiple streams?

And one more remark:

-          In the introduction session you describe three different ways in which the encoding of a media content can differ: bit-rate, codec and sampling. Recent work in the area of immersive media has proposed a fourth method: tiled video. With tiled video (or spatial segmentation), the video resulting from a single camera is split into a number of areas, each focusing on a particular spatial area of the video (e.g. a single video source could be tiled into four separate video streams, one describing the topleft quarter of the video and three more describing the topright, bottomleft and bottomright quarters respectively).

Are you willing to extend the scope of this document to include the tiled video scenario?

Best Regards,

Ray van Brandenburg

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer