Re: [AVT] [Fwd: I-DAction:draft-schierl-avt-rtp-multi-session-transmission-00.txt]

<Ye-Kui.Wang@nokia.com> Fri, 31 October 2008 15:55 UTC

Return-Path: <avt-bounces@ietf.org>
X-Original-To: avt-archive@optimus.ietf.org
Delivered-To: ietfarch-avt-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168BE3A6C3A; Fri, 31 Oct 2008 08:55:03 -0700 (PDT)
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 790ED3A6987 for <avt@core3.amsl.com>; Fri, 31 Oct 2008 08:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4]
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 fbEpsLdEYZ4G for <avt@core3.amsl.com>; Fri, 31 Oct 2008 08:55:00 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 351C03A6C3A for <avt@ietf.org>; Fri, 31 Oct 2008 08:55:00 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9VFsjZj030643; Fri, 31 Oct 2008 17:54:53 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 17:54:44 +0200
Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 17:54:44 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 31 Oct 2008 17:54:43 +0200
Message-ID: <44C96BEE548AC8429828A376231503470138C9A4@vaebe101.NOE.Nokia.com>
In-Reply-To: <49070636.5010904@hhi.fhg.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVT] [Fwd: I-DAction:draft-schierl-avt-rtp-multi-session-transmission-00.txt]
thread-index: Ack4+TFh8u/NBp0RTMSPIAfMTIK4tACcyUsw
References: <49070636.5010904@hhi.fhg.de>
From: Ye-Kui.Wang@nokia.com
To: schierl@hhi.fhg.de, avt@ietf.org
X-OriginalArrivalTime: 31 Oct 2008 15:54:44.0642 (UTC) FILETIME=[FE597020:01C93B70]
X-Nokia-AV: Clean
Cc: jonathan@vidyo.com, roni.even@polycom.co.il
Subject: Re: [AVT] [Fwd: I-DAction:draft-schierl-avt-rtp-multi-session-transmission-00.txt]
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Good draft! Just a few comments:

- There is one problem that is common for all timing based data
alignment methods (documented in sections 7.1, 7.2.1, 7.2.1, 7.2.3, and
7.2.4) but has not been mentioned in the draft. The timing based methods
themselves do not always work for encoding schemes wherein the decoding
order of coded data units is different from the output/playout order
(i.e. media timestamp order). Cases wherein the methods do not work well
include transporting media with pure temporal scalability using
multi-session transmission and when some packet loss patterns happen
(see detailed discussions in
http://research.nokia.com/files/SVC_cross_layer_decoder_order_recovery.p
pt). Thus, these methods may have to be used together with some payload
specific mechanisms, e.g. Empty NAL units as used by the NI-T and NI-TC
modes defined in the SVC payload draft, to make them complete.

- Note that in SVC, an enhancement may also be independent of the base
layer, similar as in MVC that a non-base view may be independent of the
base view. In addition, even though the current MVC codec may not fly,
it is likely some kind of multiview codecs will fly in the future.
Therefore, mandating using of a single SSRC may not be ideal, even
though that might be OK for now for SVC, for simplicity. However, if
possible, to have a complete and future-proof design would be desirable.
Therefore,.it should worth a discussion on potential issues and
solutions of using multiple SSRC values for different RTP sessions
transporting one scalable/embeded bitstream. 

- In multi-session transmission of scalable/embeded speech and audio,
e.g. G.718, though different layers may have different sampling rates,
there is no problem to use a common RTP timestamp clockrate, as is the
case in
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g718-00.txt.

BR, YK

>-----Original Message-----
>From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On 
>Behalf Of ext Thomas Schierl
>Sent: 28 October, 2008 14:32
>To: avt
>Cc: Jonathan Lennox; Even,Roni
>Subject: [AVT] [Fwd: 
>I-DAction:draft-schierl-avt-rtp-multi-session-transmission-00.txt]
>
>Dear all,
>
>As you may have already noticed, we submitted yesterday the 
>eagerly awaited draft on multi-session and multi-source related issues.
>
>There will be a presentation and a discussion at the next 
>meeting during one of the avt sessions.
>
>Best regards,
>Thomas
>
>--
>Thomas Schierl
>--------------
>Fraunhofer HHI
>
>
>
>
>
>----
>Visit us at
>
>MEDICA 2008 / Duesseldorf, Germany / 19 - 22 November 2008 / 
>Hall 16, Booth D55
>http://www.medica.de
>
>
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt