Re: [clue] Multiple Streams - RTP muxing?
<bruno.chatras@orange-ftgroup.com> Tue, 01 February 2011 17:21 UTC
Return-Path: <bruno.chatras@orange-ftgroup.com>
X-Original-To: clue@core3.amsl.com
Delivered-To: clue@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1613A6AE5 for <clue@core3.amsl.com>; Tue, 1 Feb 2011 09:21:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001]
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 QQtj2GJh3iDI for <clue@core3.amsl.com>; Tue, 1 Feb 2011 09:21:28 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id AD3683A6DF4 for <clue@ietf.org>; Tue, 1 Feb 2011 09:21:27 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8CBA5FC400B; Tue, 1 Feb 2011 18:24:48 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id CBB2DFC4020; Tue, 1 Feb 2011 18:24:46 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 18:24:42 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC234.E8E31F43"
Date: Tue, 01 Feb 2011 18:22:41 +0100
Message-ID: <9ECCF01B52E7AB408A7EB8535264214102760898@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <596CBB52-4F55-4B7F-8099-D8070C34A6F0@vidyo.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [clue] Multiple Streams - RTP muxing?
Thread-Index: AcvCHZX8H4C+TKWlS8yng4JWCcWeHQAFmbqA
References: <9EEB6465-626A-43B9-A653-A9B67FC01E80@magorcorp.com><4D46ADFD.8010506@ericsson.com><AANLkTinjgDTfU+QWZEqT_O5_bAmhNfRVvLO-oLVJdZW5@mail.gmail.com><C19596B6-E00D-445C-A0B5-CFF2E1B879EB@teliris.com><4D4801B6.7020905@ericsson.com><AANLkTikfUg1ZrsqAUteLaZcY60ex-BS5YT9pZ4zY+uMd@mail.gmail.com> <596CBB52-4F55-4B7F-8099-D8070C34A6F0@vidyo.com>
From: bruno.chatras@orange-ftgroup.com
To: alex@vidyo.com, stephen.botzko@gmail.com
X-OriginalArrivalTime: 01 Feb 2011 17:24:42.0013 (UTC) FILETIME=[E96724D0:01CBC234]
Cc: clue@ietf.org
Subject: Re: [clue] Multiple Streams - RTP muxing?
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2011 17:21:38 -0000
If we use a single RTP session for all video streams (or audio streams) and stream-specific properties (e.g. stream position or image format) have to be signaled, then I guess RFC5576 will come into play.... Right? /Bruno De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de Alex Eleftheriadis Envoyé : mardi 1 février 2011 15:38 À : Stephen Botzko Cc : CLUE Objet : Re: [clue] Multiple Streams - RTP muxing? On Feb 1, 2011, at 3:34 PM, Stephen Botzko wrote: >>> As the general media type is part of the m= line one can't have both RTP payload types of both audio and video type in the same m= line. >>>There might be some confusion here, I didn't hear anyone propose multiplexing both audio and video in the same session. I believe the multiplex idea is to have two sessions, one for audio and one for video. This is what existing video systems that employ multiplexing do. Yes, I don't think anyone intentionally suggested that the two (audio and video) are muxed. >>> In general I think this discussion should up level for a while. >>> Probably a good idea. This will come back, there are a lot of folks who build telepresence systems who favor SSRC multiplexing. Certainly (and this goes beyond pure telepresence). We will need some additional signaling tools. Check out also draft-lennox-mmusic-sdp-source-selection-02, if you haven't already. For future discussion. Incidentally, since the iPad was mentioned, you can see a demonstration of iPad running RTP (de)muxing of 3 H.264 streams in http://bit.ly/fMTP6j (posted in August 2010). This is not a "demo"; this is our regular SDK running. The complexity argument is really moot, in view of all the other things that happen in a server or endpoint. --Alex Stephen Botzko On Tue, Feb 1, 2011 at 7:51 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote: aravind sethuraman skrev 2011-01-31 20:03: > Hi all, > if we chose a single RTP session for ALL video and AUDIO, how will we > signal which SSRC conforms to which screen etc? Not via RTCP like TIP does. I just want to point out that signalling this with a single m= line in SDP is impossible. As the general media type is part of the m= line one can't have both RTP payload types of both audio and video type in the same m= line. When it comes to RTP RFC 3550 discusses this type of multiplexing and has the following to say on the issue (from section 5.2 of RFC 3550): For efficient protocol processing, the number of multiplexing points should be minimized, as described in the integrated layer processing design principle [10]. In RTP, multiplexing is provided by the destination transport address (network address and port number) which is different for each RTP session. For example, in a teleconference composed of audio and video media encoded separately, each medium SHOULD be carried in a separate RTP session with its own destination transport address. Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. Interleaving packets with different RTP media types but using the same SSRC would introduce several problems: 1. If, say, two audio streams shared the same RTP session and the same SSRC value, and one were to change encodings and thus acquire a different RTP payload type, there would be no general way of identifying which stream had changed encodings. 2. An SSRC is defined to identify a single timing and sequence number space. Interleaving multiple payload types would require different timing spaces if the media clock rates differ and would require different sequence number spaces to tell which payload type suffered packet loss. 3. The RTCP sender and receiver reports (see Section 6.4) can only describe one timing and sequence number space per SSRC and do not carry a payload type field. 4. An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream. 5. Carrying multiple media in one RTP session precludes: the use of different network paths or network resource allocations if appropriate; reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth; and receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations. Using a different SSRC for each medium but sending them in the same RTP session would avoid the first three problems but not the last two. On the other hand, multiplexing multiple related sources of the same medium in one RTP session using different SSRC values is the norm for multicast sessions. The problems listed above don't apply: an RTP mixer can combine multiple audio sources, for example, and the same treatment is applicable for all of them. It may also be appropriate to multiplex streams of the same medium using different SSRC values in other scenarios where the last two problems do not apply. As can be seen if one puts audio and video in the same RTP session but with unique SSRCs for each stream one still do need to take care. Issue 4, can be solved by explicit signalling, but makes the solution more fragile in cases with dynamic memberships. If you don't have the inforamtion about the stream mixing decisions are more difficult. Issue 5, I think becomes important as soon as we talk about a heterogeneous set of session participants. A case that are part of the charter to consider and solve. In general I think this discussion should up level for a while. Lets start discussing the general architecture and use cases and what requirements that puts on the different nodes in the architecture. Then we can return to this and see what requirements we have and how they matches the capabilities of the protocols we intended to solve it with. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue
- [clue] Multiple Streams - RTP muxing? Peter Musgrave
- Re: [clue] Multiple Streams - RTP muxing? Lorenzo Miniero
- Re: [clue] Multiple Streams - RTP muxing? Aravind Sethuraman
- Re: [clue] Multiple Streams - RTP muxing? Stephen Botzko
- Re: [clue] Multiple Streams - RTP muxing? Marshall Eubanks
- Re: [clue] Multiple Streams - RTP muxing? aravind.sethuraman
- Re: [clue] Multiple Streams - RTP muxing? Peter Musgrave
- Re: [clue] Multiple Streams - RTP muxing? Peter Musgrave
- Re: [clue] Multiple Streams - RTP muxing? Allyn Romanow (allyn)
- Re: [clue] Multiple Streams - RTP muxing? aravind sethuraman
- Re: [clue] Multiple Streams - RTP muxing? Roni Even
- Re: [clue] Multiple Streams - RTP muxing? Stephen Botzko
- Re: [clue] Multiple Streams - RTP muxing? Allyn Romanow (allyn)
- Re: [clue] Multiple Streams - RTP muxing? Magnus Westerlund
- Re: [clue] Multiple Streams - RTP muxing? Stephen Botzko
- Re: [clue] Multiple Streams - RTP muxing? Charles Eckel (eckelcu)
- Re: [clue] Multiple Streams - RTP muxing? Christer Holmberg
- Re: [clue] Multiple Streams - RTP muxing? aravind sethuraman
- Re: [clue] Multiple Streams - RTP muxing? Stephen Botzko
- Re: [clue] Multiple Streams - RTP muxing? aravind sethuraman
- Re: [clue] Multiple Streams - RTP muxing? Jonathan Lennox
- Re: [clue] Multiple Streams - RTP muxing? Peter Musgrave
- Re: [clue] Multiple Streams - RTP muxing? Elwell, John
- Re: [clue] Multiple Streams - RTP muxing? Stephen Botzko
- Re: [clue] Multiple Streams - RTP muxing? Magnus Westerlund
- Re: [clue] Multiple Streams - RTP muxing? Stephen Botzko
- Re: [clue] Multiple Streams - RTP muxing? Alex Eleftheriadis
- Re: [clue] Multiple Streams - RTP muxing? Elwell, John
- Re: [clue] Multiple Streams - RTP muxing? bruno.chatras
- Re: [clue] Multiple Streams - RTP muxing? Henry Lum
- Re: [clue] Multiple Streams - RTP muxing? Peter Musgrave