From nobody Wed Dec 3 07:27:45 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75851A1A4E for ; Wed, 3 Dec 2014 07:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSn3I-DGQWdK for ; Wed, 3 Dec 2014 07:27:36 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EEB91A1B67 for ; Wed, 3 Dec 2014 07:27:36 -0800 (PST) Received: from [107.16.188.174] (unknown [107.16.188.174]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 76869F238B for ; Wed, 3 Dec 2014 07:27:35 -0800 (PST) Message-ID: <547F2BE6.7000601@xiph.org> Date: Wed, 03 Dec 2014 07:27:34 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "" References: <6489862A-6941-4C49-B19C-C12FC1FD9DFC@cisco.com> In-Reply-To: <6489862A-6941-4C49-B19C-C12FC1FD9DFC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/payload/vn99Tyd7VG1MG73NQcY7v2OtlGE Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-opus-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 15:27:39 -0000 Ali C. Begen (abegen) wrote: > This is to start WGLC for the opus draft. > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ > > The WGLC will end Dec. 1st. Please review the draft and send an email to the list even if you dont have any comments. Passing along some comments from Martin Thomson (who's not subscribed to payload): --- This document looks like it's in pretty good shape, but I have a surprisingly large number of small nits. None of these really rise to the level of issues, though I think a couple do need to be addressed before progressing. Section 2.1 doesn't need an entire section; and the table seems to have two captions. The definition of fullband (FB) appears to have an error. Either the bandwidth is 24kHz, or the sample rate is 40kHz, or something, but Nyquist's Theorum suggests one or other needs to give. The supposed upper limit on human hearing isn't really relevant for this case. I'm also not sure that the table needs to suggest that bandwidth is a range. Section 3.1 s|Opus supports all bitrates from 6 kb/s to 510 kb/s|Opus supports bitrates from 6 kb/s to 510 kb/s| (at this level of detail, the fact that this is continuous and not discrete isn't that relevant and the implication that there are no bitrates outside this range would be unfortunate) Section 3.2 (complexity) should note that this applies to the encoder. I'm assuming that the choices are far more limited on the decoder side. Section 3.3 "whether the receiving decoder has indicated it can take advantage of "in-band" FEC information" might benefit from an informative reference on how this signal might be conveyed. "The receiver can then configure its decoder to decode the FEC data from the packet rather than the regular audio data." might be better as "instead of performing loss concealing for a missing packet, the receiver can then configure its decoder to decode the FEC data from the next packet." And drop the following sentence. Unlike stereo, it's not clear whether a decoder is capable of decoding FEC packets. I'd assume that they have to not choke if they are present. Might be worth pointing out. Section 3.4 "Any implementation of the Opus decoder MUST be capable of receiving stereo signals" -- isn't this something that RFC 6716 says? Rather than a normative statement here, simply state this as fact: "An Opus decoder is capable of handling a stereo encoding, but an application might only be capable of consuming a single audio channel." Then the SHOULD regarding don't send if you know it's not being used. Section 4.1 "The payload MAY be padded by an integer number of octets according to [RFC3550]." probably needs to mention that Opus padding is preferred. "The RTP payload type for Opus has not been assigned statically and is expected to be assigned dynamically." -- this isn't an expectation, it's required, at least for the RTP profiles currently in existence. Can this be made more definite? Table 2 is a little insulting. The text is sufficient (I would have been even more sparse, noting that the sample rate can be dynamically adjusted on a per frame basis and that timestamps increment at a constant 48kHz anyway). Section 4.2, Figure 1: s/Payload/Packet (use consistent terminology) Section 6.1, sprop-maxcapturerate: Please use "audio bandwidth" here rather than "bandwidth" to avoid confusion. m(ax|in)ptime: does this "The decoder MUST be capable of accepting any allowed packet sizes to ensure maximum compatibility." imply that if I set a maxptime of 10, I have to deal with 20 anyway? What then is the point of the attribute? maxaveragebitrate: in SDP this is going to replicate b= functionality; has that been discussed by the working group? And how is this value measured? Does it include the RTP header, does it include headers at lower layers of the stack as well? This needs more definition. no sprop-cbr for senders that would prefer resistance against traffic analysis? "Gateways or senders that are sending the same encoded audio to multiple destinations SHOULD NOT use an audio bandwidth higher than necessary to represent audio sampled at "maxplaybackrate", [...]" should be "[...] sampled at the highest current value of "maxplaybackrate" of recipients" or something like that. Similar language doesn't exist for the bitrate, but might be necessary as well. Section 7: The Opus payload format does not have any built-in security mechanisms." ... so padding doesn't count? Section 8 can be removed. From nobody Mon Dec 8 11:31:24 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8F71ACDED; Mon, 8 Dec 2014 11:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jgw6iW9xRbal; Mon, 8 Dec 2014 11:31:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E721A0092; Mon, 8 Dec 2014 11:31:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141208193119.17466.42487.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 11:31:19 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/ckme--TPuVGNBihbPXWNFROGMIY Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-opus-05.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 19:31:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for Opus Speech and Audio Codec Authors : Julian Spittka Koen Vos Jean-Marc Valin Filename : draft-ietf-payload-rtp-opus-05.txt Pages : 16 Date : 2014-12-08 Abstract: This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded speech and audio data necessary to integrate the codec in the most compatible way. Further, it describes media type registrations for the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-opus-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-opus-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 8 11:33:53 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AB01AC3C2 for ; Mon, 8 Dec 2014 11:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZfXv4NI1cEL for ; Mon, 8 Dec 2014 11:33:49 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36AD31ACDEA for ; Mon, 8 Dec 2014 11:33:26 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable167.97-201-24.mc.videotron.ca [24.201.97.167]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id A7C19F2142; Mon, 8 Dec 2014 11:33:25 -0800 (PST) Message-ID: <5485FD04.5020809@mozilla.com> Date: Mon, 08 Dec 2014 14:33:24 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Timothy B. Terriberry" , "payload@ietf.org" References: <6489862A-6941-4C49-B19C-C12FC1FD9DFC@cisco.com> <547F2BE6.7000601@xiph.org> In-Reply-To: <547F2BE6.7000601@xiph.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/payload/_po0Ymb76N-0eziJcvAIfIXtSRg Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-opus-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 19:33:51 -0000 Here's a new version that should address Martin's comments below. > Section 2.1 doesn't need an entire section; and the table seems to > have two captions. Now all in section 2. > The definition of fullband (FB) appears to have an error. Either > the bandwidth is 24kHz, or the sample rate is 40kHz, or something, > but Nyquist's Theorum suggests one or other needs to give. The > supposed upper limit on human hearing isn't really relevant for > this case. > > I'm also not sure that the table needs to suggest that bandwidth is > a range. Defined "audio bandwidth" to be the range of frequencies, i.e. not just the Nyquist rate. > Section 3.1 s|Opus supports all bitrates from 6 kb/s to 510 > kb/s|Opus supports bitrates from 6 kb/s to 510 kb/s| (at this level > of detail, the fact that this is continuous and not discrete isn't > that relevant and the implication that there are no bitrates > outside this range would be unfortunate) Fixed. > Section 3.2 (complexity) should note that this applies to the > encoder. I'm assuming that the choices are far more limited on the > decoder side. Done. > Section 3.3 "whether the receiving decoder has indicated it can > take advantage of "in-band" FEC information" might benefit from an > informative reference on how this signal might be conveyed. > > "The receiver can then configure its decoder to decode the FEC data > from the packet rather than the regular audio data." might be > better as "instead of performing loss concealing for a missing > packet, the receiver can then configure its decoder to decode the > FEC data from the next packet." And drop the following sentence. Change applied. > Unlike stereo, it's not clear whether a decoder is capable of > decoding FEC packets. I'd assume that they have to not choke if > they are present. Might be worth pointing out. Added text. > Section 3.4 "Any implementation of the Opus decoder MUST be capable > of receiving stereo signals" -- isn't this something that RFC 6716 > says? Rather than a normative statement here, simply state this as > fact: "An Opus decoder is capable of handling a stereo encoding, > but an application might only be capable of consuming a single > audio channel." Then the SHOULD regarding don't send if you know > it's not being used. Fixed. > Section 4.1 "The payload MAY be padded by an integer number of > octets according to [RFC3550]." probably needs to mention that Opus > padding is preferred. Section 3.1.2 already says that Opus padding is preferred, but it is now repeated here (without 2119 keywords to avoid potential confusion). > "The RTP payload type for Opus has not been assigned statically and > is expected to be assigned dynamically." -- this isn't an > expectation, it's required, at least for the RTP profiles currently > in existence. Can this be made more definite? Done > Table 2 is a little insulting. The text is sufficient (I would > have been even more sparse, noting that the sample rate can be > dynamically adjusted on a per frame basis and that timestamps > increment at a constant 48kHz anyway). Table 2 removed. > Section 4.2, Figure 1: s/Payload/Packet (use consistent > terminology) Done. > Section 6.1, sprop-maxcapturerate: Please use "audio bandwidth" > here rather than "bandwidth" to avoid confusion. This name has been subject to much discussion and I'd rather not re-open that. > m(ax|in)ptime: does this "The decoder MUST be capable of accepting > any allowed packet sizes to ensure maximum compatibility." imply > that if I set a maxptime of 10, I have to deal with 20 anyway? > What then is the point of the attribute? As discussed with Martin, the idea here wasn't to change how any of the ptime are normally handled, so I removed all 2119 keywords and just defer to RFC. Similarly, minptime was removed since it's not defined in RFC4566. > maxaveragebitrate: in SDP this is going to replicate b= > functionality; has that been discussed by the working group? And > how is this value measured? Does it include the RTP header, does > it include headers at lower layers of the stack as well? This > needs more definition. As discussed with Martin too, maxaveragebitrate wasn't really providing anything useful over b=AS, so it's been removed. > no sprop-cbr for senders that would prefer resistance against > traffic analysis? sprop-cbr is not needed since the encoder can unilaterally decide to keep the bitrate constant. > "Gateways or senders that are sending the same encoded audio to > multiple destinations SHOULD NOT use an audio bandwidth higher > than necessary to represent audio sampled at "maxplaybackrate", > [...]" should be "[...] sampled at the highest current value of > "maxplaybackrate" of recipients" or something like that. Similar > language doesn't exist for the bitrate, but might be necessary as > well. We have tried avoiding "sampled at" terminology because with Opus audio bandwidth does not necessarily follow the actual sampling rate (which is often just 48 kHz internally). > Section 7: The Opus payload format does not have any built-in > security mechanisms." ... so padding doesn't count? Rephrased to "Opus does not provide any confidentiality or integrity protection." > Section 8 can be removed. Added actually acknowledgments instead. From nobody Mon Dec 8 13:47:18 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AD01A88B3; Mon, 8 Dec 2014 13:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6HFfn95hOa8; Mon, 8 Dec 2014 13:47:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B931A0006; Mon, 8 Dec 2014 13:47:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141208214712.10744.43119.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 13:47:12 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/sxl1WVj5Wr7JNUFA4yvaINnjUdI Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-07.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 21:47:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for High Efficiency Video Coding Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-07.txt Pages : 100 Date : 2014-12-08 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-h265-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 8 14:06:56 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3237E1A88B5 for ; Mon, 8 Dec 2014 14:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWQaYRI540g8 for ; Mon, 8 Dec 2014 14:06:52 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558B61A1B8D for ; Mon, 8 Dec 2014 14:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1418076412; x=1449612412; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+OPI01RLhFSupm0TO8sTb1P5K7+LOQtJopNpuPvxing=; b=ZznOfLF7iLBY3yjq3P+B5FVqSK3nZwXzQJXCYOeratgaSMRzwDKv2M5l yXDe1MiZTVII6FtMy2fOJ2xOPogLJELIiihhlmm2I6gTBDmS4BtPCbWLC h4cp/xdZKk7q7DiAbX2HEwRhgLirsEhbDeqAaorvrJUKcFw3lw9Edi1uk E=; X-IronPort-AV: E=McAfee;i="5600,1067,7646"; a="80428982" Received: from ironmsg06-lv.qualcomm.com ([10.47.202.185]) by sabertooth02.qualcomm.com with ESMTP; 08 Dec 2014 14:06:51 -0800 X-IronPort-AV: E=Sophos;i="5.07,540,1413270000"; d="scan'208";a="16705342" Received: from nalasexr01e.na.qualcomm.com ([10.49.56.51]) by Ironmsg06-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Dec 2014 14:06:51 -0800 Received: from NALASEXR01H.na.qualcomm.com (10.49.56.54) by nalasexr01e.na.qualcomm.com (10.49.56.51) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 8 Dec 2014 14:06:29 -0800 Received: from NALASEXR01H.na.qualcomm.com ([10.49.56.54]) by NALASEXR01H.na.qualcomm.com ([10.49.56.54]) with mapi id 15.00.0913.011; Mon, 8 Dec 2014 14:06:17 -0800 From: "Wang, Ye-Kui" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-07.txt Thread-Index: AQHQEzCWbH7+OTMcD0G8I+ezrcWVb5yGOtwQ Date: Mon, 8 Dec 2014 22:06:17 +0000 Message-ID: <27a957b15c0e4d448cdc0069d0d0a810@NALASEXR01H.na.qualcomm.com> References: <20141208214712.10744.43119.idtracker@ietfa.amsl.com> In-Reply-To: <20141208214712.10744.43119.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.70.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/OpTifk1vbjpZXdorKXJ9IRvNNcY Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-07.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 22:06:55 -0000 Compared to version -06, the changes are as follows: - Aligned some terminology with I-D.ietf-avtcore-rtp-multi-stream, I-D.ietf= -mmusic-sdp-bundle-negotiation, and I-D.ietf-avtext-rtp-grouping-taxonomy, = particularly including the use of the following:=20 MRMT Multiple RTP streams on Multiple Transports MRST Multiple RTP streams on a Single Transport SRST Single RTP stream on a Single Transport - Clarified that the use of MRST with SDP Offer/Answer is currently not ful= ly specified, and in particular currently MRST can only be used only when t= he RTP streams utilize distinct payload types, and more options would be av= ailable when the RFCs for [I-D.ietf-avtcore-rtp-multi-stream] and [I-D.ietf= -mmusic-sdp-bundle-negotiation] are available.=20 - Clarified that the required support of MRMT by receivers does not imply t= hat multicast must be supported by receivers. - Other minor editorial clarifications.=20 The authors would like to particularly thank Bernard Aboba for his valuable= and constructive suggestions. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Monday, December 08, 2014 1:47 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-07.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-07.txt Pages : 100 Date : 2014-12-08 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Tue Dec 9 13:13:13 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8571A8A14 for ; Tue, 9 Dec 2014 13:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwaQFuEqR1T6 for ; Tue, 9 Dec 2014 13:13:10 -0800 (PST) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10671A89AF for ; Tue, 9 Dec 2014 13:13:09 -0800 (PST) X-Note-AR-ScanTimeLocal: 12/9/2014 4:13:06 PM X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/21/2014 10:58:18 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-190/SG:2 12/9/2014 4:12:16 PM X-GBUdb-Analysis: 0, 67.231.157.197, Ugly c=0.728025 p=-0.967521 Source White X-Signature-Violations: 0-0-0-2229-c X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.157.197 X-Note-Reverse-DNS: mx0b-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G251 G252 G253 G254 G258 G259 G371 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.157.197] (HELO mx0b-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTP id 177473877 for payload@ietf.org; Tue, 09 Dec 2014 16:13:05 -0500 Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id sB9LCiEg023816 for ; Tue, 9 Dec 2014 16:13:06 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1r3yb49ae3-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 09 Dec 2014 16:13:05 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 15:13:05 -0600 From: Jonathan Lennox To: "payload@ietf.org" Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-opus-04 Thread-Index: AQHP/6qVxzeDaesXAEW7xxhUMW5aHpyITxcA Date: Tue, 9 Dec 2014 21:13:04 +0000 Message-ID: References: <6489862A-6941-4C49-B19C-C12FC1FD9DFC@cisco.com> In-Reply-To: <6489862A-6941-4C49-B19C-C12FC1FD9DFC@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: <01B36ED1757BCA4D9F504AC9E034D6FA@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-09_05:2014-12-09,2014-12-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412090208 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/2dXIXj2kr8JD2aEGdibZPogIyu4 Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-opus-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 21:13:11 -0000 I=92ve reviewed the just-published version -05, it looks good to me.= From nobody Tue Dec 9 21:36:25 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923781A1B73 for ; Tue, 9 Dec 2014 21:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.311 X-Spam-Level: X-Spam-Status: No, score=-13.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WavNfgc-E3GX for ; Tue, 9 Dec 2014 21:36:21 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304221A1B69 for ; Tue, 9 Dec 2014 21:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6088; q=dns/txt; s=iport; t=1418189781; x=1419399381; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SpF4JIipt+Hn22B2mZC20j9oTSx6c3IPraDFcFD+y8Y=; b=QGDMgbh0Jhufcpe1JBLg/pT6zu3pL+/WGfYk3Lq52OL+ZjlrYUCzDKFV vWcl+WaIohoe6wrN78A0QSBypWU3zPcmBJQnE0X2P05T/dIaHbxanrz2f E7vClo/7djiUbDze7H4t49q/mZlqbnT/dpeXYuFUcthlskgJ0zNQ5MX4v Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAI7bh1StJA2I/2dsb2JhbABZgmQiUlgExiUKhTtOAoEsFgEBAQEBfYQCAQEBAwEBAQE3NAsFCwIBCBgeECcLJQIEDgWIMAgBDNcNAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPKwEkMweDIYEVBY4IiQ6BDYJdh0WGL4Nub4EDAR8ifgEBAQ X-IronPort-AV: E=Sophos;i="5.07,550,1413244800"; d="scan'208";a="379006141" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 10 Dec 2014 05:36:20 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBA5aJtD004365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Dec 2014 05:36:19 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 23:36:19 -0600 From: "Ali C. Begen (abegen)" To: Jean-Marc Valin Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-opus-04 Thread-Index: AQHP/6qVxzeDaesXAEW7xxhUMW5aHpx+gJIAgAggVwCAAjrHgA== Date: Wed, 10 Dec 2014 05:36:18 +0000 Message-ID: References: <6489862A-6941-4C49-B19C-C12FC1FD9DFC@cisco.com> <547F2BE6.7000601@xiph.org> <5485FD04.5020809@mozilla.com> In-Reply-To: <5485FD04.5020809@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.99.226] Content-Type: text/plain; charset="us-ascii" Content-ID: <7454147C9322C742B234DE1639FDFF42@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/sIP3IIjSfKD0m-Fo8tsHjPul1Dc Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-opus-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 05:36:24 -0000 Thanks for the update. I will try to finish my chair review soon and then w= e will ship this. -acbegen > On Dec 8, 2014, at 9:33 PM, Jean-Marc Valin wrote: >=20 > Here's a new version that should address Martin's comments below. >=20 >> Section 2.1 doesn't need an entire section; and the table seems to=20 >> have two captions. >=20 > Now all in section 2. >=20 >> The definition of fullband (FB) appears to have an error. Either >> the bandwidth is 24kHz, or the sample rate is 40kHz, or something, >> but Nyquist's Theorum suggests one or other needs to give. The >> supposed upper limit on human hearing isn't really relevant for >> this case. >>=20 >> I'm also not sure that the table needs to suggest that bandwidth is >> a range. >=20 > Defined "audio bandwidth" to be the range of frequencies, i.e. not > just the Nyquist rate. >=20 >> Section 3.1 s|Opus supports all bitrates from 6 kb/s to 510 >> kb/s|Opus supports bitrates from 6 kb/s to 510 kb/s| (at this level >> of detail, the fact that this is continuous and not discrete isn't >> that relevant and the implication that there are no bitrates >> outside this range would be unfortunate) >=20 > Fixed. >=20 >> Section 3.2 (complexity) should note that this applies to the >> encoder. I'm assuming that the choices are far more limited on the >> decoder side. >=20 > Done. >=20 >> Section 3.3 "whether the receiving decoder has indicated it can >> take advantage of "in-band" FEC information" might benefit from an=20 >> informative reference on how this signal might be conveyed. >>=20 >> "The receiver can then configure its decoder to decode the FEC data >> from the packet rather than the regular audio data." might be >> better as "instead of performing loss concealing for a missing >> packet, the receiver can then configure its decoder to decode the >> FEC data from the next packet." And drop the following sentence. >=20 > Change applied. >=20 >> Unlike stereo, it's not clear whether a decoder is capable of >> decoding FEC packets. I'd assume that they have to not choke if >> they are present. Might be worth pointing out. >=20 > Added text. >=20 >> Section 3.4 "Any implementation of the Opus decoder MUST be capable >> of receiving stereo signals" -- isn't this something that RFC 6716 >> says? Rather than a normative statement here, simply state this as >> fact: "An Opus decoder is capable of handling a stereo encoding, >> but an application might only be capable of consuming a single >> audio channel." Then the SHOULD regarding don't send if you know >> it's not being used. >=20 > Fixed. >=20 >> Section 4.1 "The payload MAY be padded by an integer number of >> octets according to [RFC3550]." probably needs to mention that Opus >> padding is preferred. >=20 > Section 3.1.2 already says that Opus padding is preferred, but it is > now repeated here (without 2119 keywords to avoid potential confusion). >=20 >> "The RTP payload type for Opus has not been assigned statically and >> is expected to be assigned dynamically." -- this isn't an >> expectation, it's required, at least for the RTP profiles currently >> in existence. Can this be made more definite? >=20 > Done >=20 >> Table 2 is a little insulting. The text is sufficient (I would >> have been even more sparse, noting that the sample rate can be >> dynamically adjusted on a per frame basis and that timestamps >> increment at a constant 48kHz anyway). >=20 > Table 2 removed. >=20 >> Section 4.2, Figure 1: s/Payload/Packet (use consistent >> terminology) >=20 > Done. >=20 >> Section 6.1, sprop-maxcapturerate: Please use "audio bandwidth" >> here rather than "bandwidth" to avoid confusion. >=20 > This name has been subject to much discussion and I'd rather not > re-open that. >=20 >> m(ax|in)ptime: does this "The decoder MUST be capable of accepting >> any allowed packet sizes to ensure maximum compatibility." imply >> that if I set a maxptime of 10, I have to deal with 20 anyway? >> What then is the point of the attribute? >=20 > As discussed with Martin, the idea here wasn't to change how any of > the ptime are normally handled, so I removed all 2119 keywords and > just defer to RFC. Similarly, minptime was removed since it's not > defined in RFC4566. >=20 >> maxaveragebitrate: in SDP this is going to replicate b=3D >> functionality; has that been discussed by the working group? And >> how is this value measured? Does it include the RTP header, does >> it include headers at lower layers of the stack as well? This >> needs more definition. >=20 > As discussed with Martin too, maxaveragebitrate wasn't really > providing anything useful over b=3DAS, so it's been removed. >=20 >> no sprop-cbr for senders that would prefer resistance against >> traffic analysis? >=20 > sprop-cbr is not needed since the encoder can unilaterally decide to > keep the bitrate constant. >=20 >> "Gateways or senders that are sending the same encoded audio to=20 >> multiple destinations SHOULD NOT use an audio bandwidth higher >> than necessary to represent audio sampled at "maxplaybackrate", >> [...]" should be "[...] sampled at the highest current value of=20 >> "maxplaybackrate" of recipients" or something like that. Similar=20 >> language doesn't exist for the bitrate, but might be necessary as=20 >> well. >=20 > We have tried avoiding "sampled at" terminology because with Opus > audio bandwidth does not necessarily follow the actual sampling rate > (which is often just 48 kHz internally). >=20 >> Section 7: The Opus payload format does not have any built-in >> security mechanisms." ... so padding doesn't count? >=20 > Rephrased to "Opus does not provide any confidentiality or integrity > protection." >=20 >> Section 8 can be removed. >=20 > Added actually acknowledgments instead. >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Wed Dec 10 02:11:18 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC3E1A6F61 for ; Wed, 10 Dec 2014 02:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA_hXxsTckQj for ; Wed, 10 Dec 2014 02:11:10 -0800 (PST) Received: from mail-1.sr.se (mail-1.sr.se [IPv6:2001:67c:d8:ed80::87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1DD1A6F04 for ; Wed, 10 Dec 2014 02:11:08 -0800 (PST) CC: X-Halon-ID: d9584f5f-8054-11e4-b286-000c299c41b4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sverigesradio.se; s=sverigesradio; h=cc:x-halon-id:received:received:received:from:to:subject:thread-topic: thread-index:date:message-id:accept-language:content-language:x-ms-has-attach: x-ms-tnef-correlator:x-c2processedorg:content-type:mime-version; bh=s8EuwLxhlC49gVJ9va6O6iaU6SuLL+x3E4tM5tWNNoQ=; b=L4eH6B5N0SQbE3j8d1HPJg3bqW5ZcN+iSr7BZjVnh977M3t54HDw5sxqrMLlTs/y98mv3OhJz4TSE IePCCdyg+UdxCyqi8E1sI/ck9OiZ7S8G7wIma63BxhPJVS/rfrId15K/38e0mMYjV0C/nO/lHsP3bw SD6qQzcfkC3jizR8= Received: from STOEX22.sr.se (unknown [134.25.106.47]) by mail-1.sr.se (Halon Mail Gateway) with ESMTPS for ; Wed, 10 Dec 2014 11:11:03 +0100 (CET) Received: from STOEX21.sr.se (134.25.106.46) by STOEX22.sr.se (134.25.106.47) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 10 Dec 2014 11:11:03 +0100 Received: from STOEX21.sr.se ([fe80::5468:b672:14d8:77e6]) by STOEX21.sr.se ([fe80::5468:b672:14d8:77e6%22]) with mapi id 15.00.0995.028; Wed, 10 Dec 2014 11:11:03 +0100 From: Fredrik Bergholtz To: "payload@ietf.org" Thread-Topic: draft-ietf-payload-rtp-opus-05: maxaveragebitrate Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53A== Date: Wed, 10 Dec 2014 10:11:02 +0000 Message-ID: Accept-Language: en-GB, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: 17a716aa-7169-4253-8985-281a7037fe2e Content-Type: multipart/alternative; boundary="_000_feed31dea4094e8b9cf3501fde502f86STOEX21srse_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/meNBEnmXqyYC6Ns5R3OV_WN-vCM Subject: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 10:11:16 -0000 --_000_feed31dea4094e8b9cf3501fde502f86STOEX21srse_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. I read in the latest draft that you have removed the maxaveragebitrate para= meter from the SDP signalling for Opus. I think that this parameter is usef= ul and that it provides added value over the bandwidth modifiers added by R= FC 3556. I must admit that I haven't read all of RFC 3556 but as I understand it, a = b=3D line are not in any way related to an actual format of a media descrip= tion. This means that with this mechanism, only one bitrate specification c= an be sent with each media description. Different coding algorithms have di= fferent constraints on the allowed bitrate. For example, I might want to se= nd an SDP offer with both Enhanced apt-X at 576 kbit/s and Opus at 510kbit/= s with cbr. Now, specifying 576kbit/s via a b=3D line works for apt-X but m= akes no sense for Opus and vice versa. I think that the a=3Dfmtp line is th= e correct place to specify the desired bitrate. For the broadcasting use-case, it is often more important to have a constan= t and predictable audio quality and network usage than mere audibility at a= ny cost. Best regards, Fredrik Bergholtz Swedish Radio --_000_feed31dea4094e8b9cf3501fde502f86STOEX21srse_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi.

 

I read in the latest draft that you have removed the= maxaveragebitrate parameter from the SDP signalling for Opus. I think that= this parameter is useful and that it provides added value over the bandwid= th modifiers added by RFC 3556.

 

I must admit that I haven’t read all of RFC 35= 56 but as I understand it, a b=3D line are not in any way related to an act= ual format of a media description. This means that with this mechanism, onl= y one bitrate specification can be sent with each media description. Different coding algorithms have different constra= ints on the allowed bitrate. For example, I might want to send an SDP offer= with both Enhanced apt-X at 576 kbit/s and Opus at 510kbit/s with cbr. Now= , specifying 576kbit/s via a b=3D line works for apt-X but makes no sense for Opus and vice versa. I think t= hat the a=3Dfmtp line is the correct place to specify the desired bitrate.

 

For the broadcasting use-case, it is often more impo= rtant to have a constant and predictable audio quality and network usage th= an mere audibility at any cost.

 

Best regards,

Fredrik Bergholtz

Swedish Radio

 

--_000_feed31dea4094e8b9cf3501fde502f86STOEX21srse_-- From nobody Thu Dec 11 01:40:23 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B671ACD88 for ; Thu, 11 Dec 2014 01:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FR8TrfIIp-dx for ; Thu, 11 Dec 2014 01:40:21 -0800 (PST) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F341ACD91 for ; Thu, 11 Dec 2014 01:40:17 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hy10so2361147vcb.14 for ; Thu, 11 Dec 2014 01:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=l75zfZbreZPim63jrTG+St0QY+G4WpH44akeU0bNjys=; b=dMqDgeDpyhVCQFzKwjZgMVeqNljKu5XZ+dZ7/haU7WLi5KilO2ZtALpBGr9+kWPyjT Jq7l4nkYSvgIzZ13tn/GV8BT5wO1W1SO379qcE5NIWpHLp0RSMmiYFSdqCUNQ7Bk43zm XoCSRcpJU/+pkkAYVLyhhbk0y9XLvpCmTbhal6UaxypCueTKz6gry8Imx5mfhYmuNryK 87IUtfaaRPCccd7YQ4UblXMl6s+rd0rFRmmYI0NyygyXaPo2kDDHVGWyWjJB9EKN2QD7 DE+F8/TIhd2kc0xDm7qWW4EVRHRWIQp+xnKUcp8pQ6Zg708ynwcN1ZiKrqZ0b6Ufugrb BqtQ== X-Received: by 10.221.34.193 with SMTP id st1mr5725465vcb.77.1418290816161; Thu, 11 Dec 2014 01:40:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.137.8 with HTTP; Thu, 11 Dec 2014 01:39:56 -0800 (PST) From: Martin Ellis Date: Thu, 11 Dec 2014 11:39:56 +0200 Message-ID: To: payload@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/sJkz_hlB6UAjZ6D4LloEa6Y0MFs Subject: [payload] Specific PLI feedback from draft-ietf-payload-rtp-h265-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 09:40:22 -0000 Hi, In the early drafts of draft-ietf-payload-rtp-h265, there was a proposed feedback message, "Specific Picture Loss Indication (SPLI)", which was removed in later versions. >From the list archives, I see that there was some discussion about whether this feedback message should be defined in a separate document updating RFC 4585, but I can't find any further references to it. Does anyone know what happened there? If SPLI is not used, what would be the recommended approach to give feedback for specifically lost pictures, to allow tracking of errors on the encoder side? Cheers, Martin From nobody Thu Dec 11 05:24:14 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF691A896E for ; Thu, 11 Dec 2014 05:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAkONBhQwr4u for ; Thu, 11 Dec 2014 05:24:10 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D3D1A896B for ; Thu, 11 Dec 2014 05:24:09 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-72-54899af7d26a Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9D.B9.04076.7FA99845; Thu, 11 Dec 2014 14:24:08 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.148]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 14:24:07 +0100 From: Jonatan Samuelsson To: Martin Ellis , "payload@ietf.org" Thread-Topic: [payload] Specific PLI feedback from draft-ietf-payload-rtp-h265-01 Thread-Index: AQHQFSZ+5cJs7l9g6USKFtiW0FT/ApyKWnOA Date: Thu, 11 Dec 2014 13:24:06 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB2334A6F9@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje6PWZ0hBtNXsFqsutPKanHp4lkm ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj85yFjAV/eSsOty9ma2Dczd3FyMkhIWAi sWbNWhYIW0ziwr31bF2MXBxCAkcYJXZ+ec8MkhASWMIosfRMchcjBwebgJXE9xcRIGERgSCJ 1b1XmEBsYSD75PZWVoh4sMSOzQ/ZIWwjibVTXoPVsAioSuzad5UNxOYV8Jb4/mQnK8hIIYEA icsTRUDCnAKBEtuPHwYrZxSQlbj//R7YacwC4hK3nsxngjhTQGLJnvPMELaoxMvH/8DGSAgo Sizvl4Mo15FYsPsTG4StLbFs4WtmiK2CEidnPmGZwCg6C8nUWUhaZiFpmYWkZQEjyypG0eLU 4uLcdCMjvdSizOTi4vw8vbzUkk2MwAg5uOW31Q7Gg88dDzEKcDAq8fAaVnaGCLEmlhVX5h5i lOZgURLnXXhuXrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxvkbZHdIRLxV691r8bXGj618 zdenbibCs87e/mn8dN27J7L1xy0ui01bFDJv8jXVP4/PRriLGl9c+2lZ6Katvt6ql6KetNqp 7CtqMTFfeNlk+r4yrncZp/RWBjPPdk+TZls+84m9CguDfe/mSIHFdV9OGn487j/bdAv/HKEr Pjt3XeC48CetO06JpTgj0VCLuag4EQD0+kfFcQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/payload/F9czbAZMWAVhSsCqNecNFFEde4M Subject: Re: [payload] Specific PLI feedback from draft-ietf-payload-rtp-h265-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 13:24:13 -0000 Hi Martin, Thanks for bringing up the question of feedback for indicating specific los= t pictures in h.265. There were two more feedback message features discussed during the h.265 pa= yload drafting: - indicating incorrect Decoded Picture Hash values - indicating multiple reference pictures that can be used for reference I, Muhammed Coban and Stephan Wenger have been drafting text for a new feed= back message that is supposed to have support for all of these three featur= es . The feedback message should be possible to use with h.265 as well as o= ther codecs such as h.264. Our ambition is to soon submit an I-D in the AVT= EXT working group. Please let me know if you would like to receive our curr= ent (draft) version of the draft. Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Martin Ellis Sent: den 11 december 2014 10:40 To: payload@ietf.org Subject: [payload] Specific PLI feedback from draft-ietf-payload-rtp-h265-0= 1 Hi, In the early drafts of draft-ietf-payload-rtp-h265, there was a proposed fe= edback message, "Specific Picture Loss Indication (SPLI)", which was remove= d in later versions. >From the list archives, I see that there was some discussion about whether this feedback message should be defined in a separate document upda= ting RFC 4585, but I can't find any further references to it. Does anyone know what happened there? If SPLI is not used, what would be the recommended approach to give feedbac= k for specifically lost pictures, to allow tracking of errors on the encode= r side? Cheers, Martin _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Thu Dec 11 17:08:03 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46201A00C3 for ; Thu, 11 Dec 2014 17:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44KxOfYER9G2 for ; Thu, 11 Dec 2014 17:07:57 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9F21A90DE for ; Thu, 11 Dec 2014 17:07:55 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca [24.201.170.74]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 268DDF2019; Thu, 11 Dec 2014 17:07:55 -0800 (PST) Message-ID: <548A3FEA.2070400@mozilla.com> Date: Thu, 11 Dec 2014 20:07:54 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Fredrik Bergholtz , "payload@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/payload/CtUEzfjykvOaW-DuS9PAkhy_F0U Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 01:08:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have to say this is not something I understand really well. Does anyone else here have an opinion on how to specify bit-rate? Jean-Marc On 10/12/14 05:11 AM, Fredrik Bergholtz wrote: > Hi. > > > > I read in the latest draft that you have removed the maxaveragebitrate > parameter from the SDP signalling for Opus. I think that this parameter > is useful and that it provides added value over the bandwidth modifiers > added by RFC 3556. > > > > I must admit that I haven’t read all of RFC 3556 but as I understand it, > a b= line are not in any way related to an actual format of a media > description. This means that with this mechanism, only one bitrate > specification can be sent with each media description. Different coding > algorithms have different constraints on the allowed bitrate. For > example, I might want to send an SDP offer with both Enhanced apt-X at > 576 kbit/s and Opus at 510kbit/s with cbr. Now, specifying 576kbit/s via > a b= line works for apt-X but makes no sense for Opus and vice versa. I > think that the a=fmtp line is the correct place to specify the desired > bitrate. > > > > For the broadcasting use-case, it is often more important to have a > constant and predictable audio quality and network usage than mere > audibility at any cost. > > > > Best regards, > > Fredrik Bergholtz > > Swedish Radio > > > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUij/kAAoJEJ6/8sItn9q9V6EIALgEC6Iv+nZuu2BU8useaV4Z jLRz97vCEdcmj60jMzELC2gSKLpVW3AMcbP7gtPjm0odeLFEMvoweUFytnVt/cd6 bCadjHMPAOSNXrPtbmS57JdlcmWHnsrJIVrsV/Ipn6o44FWL2BN5g/LnwlSTKs/N OtrjAdLj8b/GsmVS6VTTjTkygL1bp1Wsry5oAGXIPwPqFgQwuGMAxv/Wf6eEu7c3 eoZzBKfBDM0bC8L+RCy6REYKHvSjPbyPAH0bQvkkKHfSc6I5ZLOZspvOHBmHvQFu DNj4DHCShHPnRRknVnXCXX9ddSC4/bLQSyZ9+WI9622N5lkre8+VnUIGx9iAr3I= =ZuN4 -----END PGP SIGNATURE----- From nobody Tue Dec 16 05:41:33 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016D91A1B0C for ; Tue, 16 Dec 2014 05:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM4mU3KhOLNq for ; Tue, 16 Dec 2014 05:41:29 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A2D1A1B1E for ; Tue, 16 Dec 2014 05:41:28 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-d3-549036865822 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 18.8F.29772.68630945; Tue, 16 Dec 2014 14:41:27 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.7]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 14:41:26 +0100 From: Jonatan Samuelsson To: Jonatan Samuelsson , Martin Ellis , "payload@ietf.org" Thread-Topic: [payload] Specific PLI feedback from draft-ietf-payload-rtp-h265-01 Thread-Index: AQHQFSZ+5cJs7l9g6USKFtiW0FT/ApyKWnOAgAfkEmA= Date: Tue, 16 Dec 2014 13:41:25 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB23362B13@ESESSMB109.ericsson.se> References: <634D3B5D82E3214DA9B6A36D5F50DB2334A6F9@ESESSMB109.ericsson.se> In-Reply-To: <634D3B5D82E3214DA9B6A36D5F50DB2334A6F9@ESESSMB109.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvjW672YQQgy/LmSxW3Wlltbh08SyT A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVx71oDW8FJkYptH2YxNzC2CHYxcnJICJhI rJu8gwnCFpO4cG89WxcjF4eQwBFGiUdbFrFAOIsYJTZf6WfuYuTgYBOwkvj+IgIkLiLQwSgx //wyZpBuYYEgiZPbW1lBbBGBYIkdmx+yQ9hWEgf3/2MC6WURUJVY/N8QJMwr4C2x8uUcdoj5 k4CWNb8Dm8Mp4CPx7NMJNhCbUUBW4v73eywgNrOAuMStJ/OhLhWQWLLnPDOELSrx8vE/Vghb SWLt4e1Q9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqc WpyUm25kpJdalJlcXJyfp5eXWrKJERgpB7f8NtjB+PK54yFGAQ5GJR5egwX9IUKsiWXFlbmH GKU5WJTEeReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTGw63ki952AZqHffto2M2S7 GYN/KT051Z9ls/+cwUGx7Wdmr1NLfnvmz6zbiSYMF07+5b2ya+nlvIaL8/6qCTiFRhn/+zT3 ful7t1fFdRv7ZvkVLE46JD4zSKjy7vWeCzq8EzcLzucPeN3B1mlspGhorDST9YGEyvfgsm7v PRdLDldsb3tcE6fEUpyRaKjFXFScCADFArBldQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/payload/D5aGUTk4h4W0PwFtQueSxksUXbA Subject: Re: [payload] Specific PLI feedback from draft-ietf-payload-rtp-h265-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 13:41:31 -0000 Hi again, The draft I mentioned below has now been submitted to the AVTEXT working gr= oup (https://datatracker.ietf.org/doc/draft-samuelsson-avtext-rpvi/). I hav= e just sent out a notification about the availability of the draft on the A= VTEXT mailing list. In order to avoid parallel discussions, I suggest that further discussions = on the topic are (primarily) held on the AVTEXT mailing list. Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Jonatan Samuel= sson Sent: den 11 december 2014 14:24 To: Martin Ellis; payload@ietf.org Subject: Re: [payload] Specific PLI feedback from draft-ietf-payload-rtp-h2= 65-01 Hi Martin, Thanks for bringing up the question of feedback for indicating specific los= t pictures in h.265. There were two more feedback message features discussed during the h.265 pa= yload drafting: - indicating incorrect Decoded Picture Hash values - indicating multiple reference pictures that can be used for reference I, Muhammed Coban and Stephan Wenger have been drafting text for a new feed= back message that is supposed to have support for all of these three featur= es . The feedback message should be possible to use with h.265 as well as o= ther codecs such as h.264. Our ambition is to soon submit an I-D in the AVT= EXT working group. Please let me know if you would like to receive our curr= ent (draft) version of the draft. Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Martin Ellis Sent: den 11 december 2014 10:40 To: payload@ietf.org Subject: [payload] Specific PLI feedback from draft-ietf-payload-rtp-h265-0= 1 Hi, In the early drafts of draft-ietf-payload-rtp-h265, there was a proposed fe= edback message, "Specific Picture Loss Indication (SPLI)", which was remove= d in later versions. >From the list archives, I see that there was some discussion about whether this feedback message should be defined in a separate document upda= ting RFC 4585, but I can't find any further references to it. Does anyone know what happened there? If SPLI is not used, what would be the recommended approach to give feedbac= k for specifically lost pictures, to allow tracking of errors on the encode= r side? Cheers, Martin _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Fri Dec 19 09:13:33 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD411A8A8B; Fri, 19 Dec 2014 09:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv94eusPW2zU; Fri, 19 Dec 2014 09:11:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1489B1A886E; Fri, 19 Dec 2014 09:11:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: yekuiw@qti.qualcomm.com, yago.sanchez@hhi.fraunhofer.de, ts@thomas-schierl.de, stewe@stewe.org, miska.hannuksela@nokia.com X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219171139.16022.19444.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 09:11:39 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/92ox3vwnKYhHTlgmmOeMQUcrDok X-Mailman-Approved-At: Fri, 19 Dec 2014 09:13:31 -0800 Cc: alissa@cooperw.in, payload@ietf.org, ipr-announce@ietf.org Subject: [payload] IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-payload-rtp-h265-07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 17:11:40 -0000 Dear Ye-Kui Wang, Yago Sanchez, Thomas Schierl, Stephan Wenger, Miska M. Hannuksela: An IPR disclosure that pertains to your Internet-Draft entitled "RTP Payload Format for High Efficiency Video Coding" (draft-ietf-payload-rtp-h265) was submitted to the IETF Secretariat on 2014-12-19 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2508/). The title of the IPR disclosure is "Nokia Corporation's Statement about IPR related to draft-ietf-payload- rtp-h265-07.""); The IETF Secretariat From nobody Tue Dec 23 09:49:52 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C877C1A1A7E; Tue, 23 Dec 2014 09:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nVqMLKZzWRK; Tue, 23 Dec 2014 09:49:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0871A1A93; Tue, 23 Dec 2014 09:49:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223174948.5580.24098.idtracker@ietfa.amsl.com> Date: Tue, 23 Dec 2014 09:49:48 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/5ALkJi-PqZ7pRov9oGpfnf_gXeQ Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-g7110-04.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 17:49:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for G.711.0 Authors : Michael A. Ramalho Paul E. Jones Noboru Harada Muthu Arul Mozhi Perumal Lei Miao Filename : draft-ietf-payload-g7110-04.txt Pages : 30 Date : 2014-12-23 Abstract: This document specifies the Real-Time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-g7110/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-g7110-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-g7110-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 23 21:42:48 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25671ACD1D; Tue, 23 Dec 2014 21:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTYQZRk7kgZr; Tue, 23 Dec 2014 21:42:37 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48AE31ACC82; Tue, 23 Dec 2014 21:42:37 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBO5gNxW015878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Dec 2014 00:42:25 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com sBO5gNxW015878 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1419399747; bh=kDX/Zg7ac4pE7FuZE3mZWd1pzTE=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=FiK4Glwc0fvu1dsOmxiQDWR4rDwpEUHbTKgMlHWxyGIVYNWNH/u7VUt7xO9ony4Hh Kk5L6om4TlDtXRV7fklK20qqFgqVkHs3qymv6Up6yxPnwTlbzbb3tkNJqJ9huTX7Pj iWyqfzgpXCERBh13dcIjlwikZrZXOugxgTUuGRvg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com sBO5gNxW015878 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Wed, 24 Dec 2014 00:42:03 -0500 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBO5g17v019492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Dec 2014 00:42:01 -0500 Received: from MXHUB107.corp.emc.com (10.253.50.23) by mxhub29.corp.emc.com (128.222.70.169) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 24 Dec 2014 00:42:01 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB107.corp.emc.com ([10.253.50.23]) with mapi id 14.03.0195.001; Wed, 24 Dec 2014 00:42:01 -0500 From: "Black, David" To: "mramalho@cisco.com" , "Paul E. Jones (paulej@packetizer.com)" , "harada.noboru@lab.ntt.co.jp" , "muthu.arul@gmail.com" , "lei.miao@huawei.com" , "ops-dir@ietf.org" Thread-Topic: OPS-Dir review of draft-ietf-payload-g7110-04 Thread-Index: AdAfPFVGeZeAXS5RRlmbbcNFHVlO1A== Date: Wed, 24 Dec 2014 05:42:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.44.92] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/payload/mhkXsy2SEvsBzmzoG0XtuNbXz04 Cc: "Black, David" , "payload@ietf.org" Subject: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 05:42:42 -0000 The -04 version of this draft is an improvement, but does not resolve all the issues from the Gen-ART and OPS-Dir review of the -03 version. This is now reduced to an OPS-Dir review (and email distribution), as Joel's holding the relevant "Discuss" position. The following issues are still open: -- Major -- (these four are all now minor issues in -04) > [A] Section 4.2.3 specifies a detailed decoding algorithm covering > how G.711.0 decompression interacts with received RTP G.711.0 payloads. > A corresponding encoding algorithm specification is needed on the > sending side for G.711.0 compression interaction with RTP sending. > The algorithm will have some decision points in it that cannot be > fully specified, e.g., time coverage of the generated G.711.0 frames. Section 4.2.2.1 does most of this. It needs to include generation of the "Prefix Code" octet that is described in Section 3.3. > [B] The G.711.0 frame format is not specified here, making it very > difficult to figure out what's going on when G.711.0 frames are > concatenated. A specific example is that the concept of a "prefix > code" that occurs at the start of a G.711.0 frame is far too important > to be hidden in step H5 of the decoding algorithm in Section 4.2.3. This is mostly done in Section 3.3, but is a bit unclear: The first octet of a G.711.0 frame is called the "Prefix Code" octet; the value of this octet conveys how many G.711 symbols the decoder is to create from a given G.711.0 input frame. The Prefix Code value of 0x00 is used to denote zero G.711 source symbols, which allows the use of 0x00 as a payload padding octet (to be described later). The word "conveys" is problematic, as the "Prefix Code" octet cannot contain the number of G.711 symbols, as that number could be 320, which is larger than 255. I'm guessing that the "Prefix Code"=20 is an encoded value - if so, here's some suggested text: OLD the value of this octet conveys how many G.711 symbols the decoder is to create from a given G.711.0 input frame. NEW (fill in value of 0xNN below) the encoded value in this octet indicates how many G.711 symbols the decoder is to create from a given G.711.0 input frame (e.g., the value 0xNN indicates that 320 G.711 symbols are expected). If there are invalid values of the "Prefix Code" octet, that will affect step H5 in Section 4.2.3 where finding an invalid value should cause decoding to stop. > [C] The discussion of use of the SDP ptime parameter is spread out and > imprecise (is SDP REQUIRED?, when is ptime REQUIRED, RECOMMENDED, or > recommended? - it's not obvious). > [... snip ...] >=20 > I would suggest that a subsection be added, possibly at the end of > Section 3, to gather/summarize all of the relevant ptime discussion > in one place. I suspect that the contents of this draft are mostly > correct wrt ptime, but it's hard to figure out what's going on from > the current spread-out text. =20 Not done, although the sentence added (for [D]) on negotiation being out of scope helps. The first mention of "ptime" is in A4 in Section 3.2, with effectively no explanation of what ptime is: A G.711.0 decoder need not know what ptime is, as it is able to decompress the G.711.0 frame presented to it without signaling knowledge. A definition would help - somewhere before that first use of ptime, define "ptime" using the words from RFC 4566: ptime: length of time in milliseconds represented by the media in a packet. This is an attribute that can be signaled via SDP [RFC 4566]. > [D] Backwards compatibility. >=20 > The problem here is that it's not clear that negotiation (e.g., via SDP) > is required. This sentence in Section 3.1 is a particular problem: >=20 > G.711.0, being both lossless and stateless, may also be employed as a > lossless compression mechanism anywhere between end systems which > have negotiated use of G.711. >=20 > That's definitely wrong. Use of G.711.0 when only G.711 has been > negotiated will fail to interoperate correctly. That problematic sentence is still there - I suggest a minor change to remove the word "negotiated": OLD G.711.0, being both lossless and stateless, may also be employed as a lossless compression mechanism for G.711 payloads anywhere between end systems which have negotiated use of G.711. NEW G.711.0, being both lossless and stateless, may also be employed as a lossless compression mechanism for G.711 payloads anywhere between end systems that support use of G.711. Then the added sentence on negotiation being out of scope (end of paragraph that begins with that problematic sentence) makes more sense. -- Minor -- > [F] Section 4.1: >=20 > PT - The assignment of an RTP payload type for the format defined > in this memo is outside the scope of this document. The RTP > profiles in use currently mandate binding the payload type > dynamically for this payload format. >=20 > Good start, but not sufficient - cite the "RTP profiles currently > in use" and I would expect those citations to be normative references. Not done. Just listing those profiles with RFC citations will suffice. > [G] Framing errors >=20 > Section 4 generally assumes that the G.711.0 decoder gets handed frames > generated by the G.711.0 encoder and can't get disaligned. I'm not > convinced that this "just works" based on the text in the draft - major > issue [B] is a significant reason why, and explaining that should help. Not done - the concern here is what happens when the decoder reads a G.711.0 payload octet (encoded from G.711 symbols) as a "Prefix Code" octet? I think resolving [B] will address most of this, especially if that results in a "Not a valid Prefix Code value" error. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Wednesday, October 22, 2014 11:44 AM > To: mramalho@cisco.com; Paul E. Jones (paulej@packetizer.com); > harada.noboru@lab.ntt.co.jp; muthu.arul@gmail.com; lei.miao@huawei.com; > General Area Review Team (gen-art@ietf.org); ops-dir@ietf.org > Cc: ietf@ietf.org; payload@ietf.org; Black, David > Subject: Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03 >=20 > This is a combined Gen-ART and OPS-DIR review. Boilerplate for both foll= ows > ... >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at: >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > I have reviewed this document as part of the Operational directorate's on= going > effort to review all IETF documents being processed by the IESG. These > comments > were written primarily for the benefit of the operational area directors. > Document editors and WG chairs should treat these comments just like any = other > last call comments. >=20 > Document: draft-ietf-payload-g7110-03 > Reviewer: David Black > Review Date: October 22, 2014 > IETF LC End Date: October 27, 2014 > IESG Telechat date: October 30, 2014 >=20 > Summary: This draft is on the right track, but has open issues > described in the review. >=20 > Process note: This is the second draft that I've reviewed recently > that has been scheduled for an IESG telechat almost immediately > following the end of IETF Last Call. The resulting overlap of > IETF LC with IESG Evaluation can result in significant last-minute > changes to the draft when issues are discovered during IETF LC. >=20 > This draft describes an RTP payload format for carrying G.711.0 > compressed G.711 voice. The details of G.711.0 compression are > left to the ITU-T G.711.0 spec (which is fine), and this draft > focuses on how to carry the compressed results in RTP and conversion > to/from uncompressed G.711 voice at the communication endpoints. > I found a few major issues and a couple of minor ones, although > a couple of the major issues depend on a meta-issue, - the intended > relationship of this draft be to the ITU-T G.711.0 spec. >=20 > In general, I expect IETF RFCs to be stand-alone documents that make > sense on their own, although one may need to read related documents > to completely understand what's going on. For this draft, I would > expect the actual compression/decompression algorithms to be left to > the ITU-T spec, and this draft to stand on its own in explaining how > to deploy G.711.0 compression/decompression with RTP. If that > expectation is incorrect, and this draft is effectively an RTP Annex > to G.711.0 that must be read in concert with G.711.0, then the > first two major issues below are not problems as they should be > obvious in the G.711.0 spec, although the fact that this draft is > effectively an Annex to G.711.0 should be stated. Otherwise, those > two major issues need attention. >=20 > -- Major Issues (4): >=20 > [A] Section 4.2.3 specifies a detailed decoding algorithm covering > how G.711.0 decompression interacts with received RTP G.711.0 payloads. > A corresponding encoding algorithm specification is needed on the > sending side for G.711.0 compression interaction with RTP sending. > The algorithm will have some decision points in it that cannot be > fully specified, e.g., time coverage of the generated G.711.0 frames. >=20 > [B] The G.711.0 frame format is not specified here, making it very > difficult to figure out what's going on when G.711.0 frames are > concatenated. A specific example is that the concept of a "prefix > code" that occurs at the start of a G.711.0 frame is far too important > to be hidden in step H5 of the decoding algorithm in Section 4.2.3. >=20 > [C] The discussion of use of the SDP ptime parameter is spread out and > imprecise (is SDP REQUIRED?, when is ptime REQUIRED, RECOMMENDED, or > recommended? - it's not obvious). >=20 > A specific example is that this sentence in Section 4.2.4 is an > invitation to interoperability problems ("could infer" - how is that > done and where do the inputs to that inference come from?): >=20 > Similarly, if the number of > channels was not known, but the payload "ptime" was known, one could > infer (knowing the sampling rate) how many G.711 symbols each channel > contained; then with this knowledge determine how many channels of > data were contained in the payload. >=20 > I would suggest that a subsection be added, possibly at the end of > Section 3, to gather/summarize all of the relevant ptime discussion > in one place. I suspect that the contents of this draft are mostly > correct wrt ptime, but it's hard to figure out what's going on from > the current spread-out text. It looks like "ptime" could provide a > cross-check on correctness of G.711.0 decoding - see minor issue [G] > below. >=20 > This major issue [C] is independent of the relationship between this > draft and the G.711.0 spec. >=20 > [D] Backwards compatibility. >=20 > The problem here is that it's not clear that negotiation (e.g., via SDP) > is required. This sentence in Section 3.1 is a particular problem: >=20 > G.711.0, being both lossless and stateless, may also be employed as a > lossless compression mechanism anywhere between end systems which > have negotiated use of G.711. >=20 > That's definitely wrong. Use of G.711.0 when only G.711 has been > negotiated will fail to interoperate correctly. >=20 > A subsection of section 3 on negotiation and SDP usage would help here. >=20 > This major issue [D] is independent of the relationship between this > draft and the G.711.0 spec. >=20 > -- Minor issues (3): >=20 > [E] Section 4.1: >=20 > The only significant difference is that the > payload type (PT) RTP header field will have a value corresponding to > the dynamic payload type assigned to the flow. This is in contrast > to most current uses of G.711 which typically use the static payload > assignment of PT =3D 0 (PCMU) or PT =3D 8 (PCMA) [RFC3551] even though > the negotiation and use of dynamic payload types is allowed for > G.711. >=20 > I would change "will have" to "MUST have" and add the following sentence: >=20 > The existing G.711 PT values of 0 and 8 MUST NOT be used for G.711.0 > content. >=20 > I'm suspect that this is obvious to the authors, but it'll help a reader > who's not familiar with the importance of the difference between G.711 > and G.711.0 . >=20 > [F] Section 4.1: >=20 > PT - The assignment of an RTP payload type for the format defined > in this memo is outside the scope of this document. The RTP > profiles in use currently mandate binding the payload type > dynamically for this payload format. >=20 > Good start, but not sufficient - cite the "RTP profiles currently > in use" and I would expect those citations to be normative references. >=20 > Would that be just RFC 3551 and RFC 4585 (both are already normative > references), or are there more RTP profiles? >=20 > [G] Framing errors >=20 > Section 4 generally assumes that the G.711.0 decoder gets handed frames > generated by the G.711.0 encoder and can't get disaligned. I'm not > convinced that this "just works" based on the text in the draft - major > issue [B] is a significant reason why, and explaining that should help. >=20 > Some discussion should be added on why the G.711.0 decoder can't get > disaligned wrt frame boundaries this can't happen, or what the G.711.0 > decoder will do when it discovers that it wasn't handed a complete G.711.= 0 > frame. For example, this error case and how to deal with it are not > covered by the algorithm in Section 4.2.3. >=20 > -- Nits/editorial comments: >=20 > Section 3.2: >=20 > A6 Bounded expansion: Since attribute A2 above requires G.711.0 to > be lossless for any payload, by definition there exists at > least one potential G.711 payload which must be > "uncompressible". >=20 > The "by definition" statement assumes that every possible bit string is > a valid G.711 input. If that is correct, it should be explicitly stated. >=20 > A8 Low Complexity: Less than 1.0 WMOPS average and low memory > footprint (~5k octets RAM, ~5.7k octets ROM and ~3.6 basic > operations) [ICASSP] [G.711.0]. >=20 > Expand WMOPS on first use, and check for other acronyms that need to be > expanded on first use. >=20 > Section 3.3: >=20 > Since the G.711.0 output frame is "self-describing", a G.711.0 > decoder (process "B") can losslessly reproduce the original G.711 > input frame with only the knowledge of which companding law was used > (A-law or mu-law). >=20 > "companding law"? The term "compression law" is used elsewhere in > this draft, including two paragraphs earlier in this section - I suggest > using "compression law" consistently. >=20 > Section 6: >=20 > We note that something must be stored for any G.711.0 frames that not > received at the receiving endpoint, no matter what the cause. >=20 > "that not" -> "that are not" >=20 > Section 6.2: >=20 > An entire frame of value 0++ or 0-- is expected to be > extraordinarily rare when the frame was in fact generated by a > natural signal (on the order of one in 2^{ptime in samples, minus > one}), as analog inputs such as speech and music are zero-mean and > are typically acoustically coupled to digital sampling systems. >=20 > This doesn't explain where the 2^{ptime in samples, minus one} order > of magnitude estimation came from. What assumption(s) is(are) being > made about randomness and distribution thereof in the analog input? > It might be simpler to delete the parenthesized text. >=20 > Section 11: Congestion Control >=20 > This section is mis-named, as it basically (correctly) says that there > is nothing useful that can be done in G.711.0 compression to respond > to congestion. I would retitle this to "Congestion Considerations". >=20 > Are there opportunities to respond to congestion elsewhere, e.g. > dynamically change the sampling rate? If so, a sentence mentioning > them would be good to add. >=20 > idnits 2.13.01 didn't find anything to complain about ;-). >=20 > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- >=20 > Most of these questions are N/A as this draft specifies a payload format > for RTP, so most of the operations and management concerns are wrt RTP > and SDP. >=20 > A.1.3. Has the migration path been discussed? >=20 > No, see major issue [D] above. >=20 > A.1.4 Have the Requirements on other protocols and functional > components been discussed? >=20 > Only in part - major issues [C] and [D] call out shortcomings in the > discussion of SDP interactions. >=20 > A.1.8 Are there fault or threshold conditions that should be reported? >=20 > Yes, the likelihood and consequences of framing problems at the G.711.0 > decoder (decoder is handed octet strings that are not G.711.0 frames > generated by the encoder) should be discussed. Major issue [B] needs > to be resolved first, and then see minor issue [G]. >=20 > A.2. Management Considerations >=20 > I would expect that the media type registration (Section 5.1 of this draf= t) > results in this new G.711.0 media type being usable in any relevant > management model and/or framework that has some notion of media type. >=20 > A.3 Documentation >=20 > By itself, this compressed payload format does not look like a likely > source of significant operational impacts on the Internet. >=20 > The shepherd's writeup indicates that an implementation exists. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From nobody Tue Dec 30 20:57:56 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716EF1A8A82 for ; Tue, 30 Dec 2014 20:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGP_KdFUvve9 for ; Tue, 30 Dec 2014 20:57:50 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827211A8A7B for ; Tue, 30 Dec 2014 20:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3098; q=dns/txt; s=iport; t=1420001871; x=1421211471; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wJPDfFdEg1Xffn0EqI30REoApXc7SedCR9BaP2jbEj0=; b=PuS/49lUtDdVDYgpttUguOuSuoZ+Li8qwFHoSxY51nRQVmjwuvsyWAgk qMzmFVxkTTzu/zU9zo7gOysr5/27IrMybGoR6dRA1iK7YrCnLQdltdts2 BDjpTGXPl3BEH/Pbc8x623V9xQyKzyZ+GVLrPLK2zr+k25Bv0hDjqtJDl E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAMKAo1StJV2U/2dsb2JhbABcgmQiUlgExk0KhSlKAoEFFgEBAQEBfYQMAQEBAwEBAQFrCwULAgEIGC4nCyUBAQQOBYgkCAEMxnUBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI9EMweDFoETBY4ViHOBDYUYiysiggEdgVBvgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,670,1413244800"; d="scan'208";a="109362195" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP; 31 Dec 2014 04:57:50 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sBV4vnUP014186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Dec 2014 04:57:49 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 30 Dec 2014 22:57:49 -0600 From: "Ali C. Begen (abegen)" To: Jean-Marc Valin Thread-Topic: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53ACMooEAA8OQx4A= Date: Wed, 31 Dec 2014 04:57:49 +0000 Message-ID: References: <548A3FEA.2070400@mozilla.com> In-Reply-To: <548A3FEA.2070400@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.75.182] Content-Type: text/plain; charset="Windows-1252" Content-ID: <10405125CEDC9B498F9330B108E3A222@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/pwyziWAFt7-Cs5lb3wHCPc7H6fs Cc: "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 04:57:52 -0000 My understanding is that the b=3D line in the SDP is quite a subjective par= ameter. I have seen people use it differently over the past several years. = So, it is a bit difficult to infer much accuracy from that line. OTOH, if someone feels like Opus needs to specify some sort of bitrate vari= ability in the SDP, it can do so in an optional (opus) parameter. Obviously= rules around how to set that value and what to do with that value need to = be clearly specified. Fredrik (or anyone else in the WG), do you see a strong need for this? If s= o, now is the time to mention that. -acbegen > On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > I have to say this is not something I understand really well. Does > anyone else here have an opinion on how to specify bit-rate? >=20 > Jean-Marc >=20 > On 10/12/14 05:11 AM, Fredrik Bergholtz wrote: >> Hi. >>=20 >>=20 >>=20 >> I read in the latest draft that you have removed the maxaveragebitrate >> parameter from the SDP signalling for Opus. I think that this parameter >> is useful and that it provides added value over the bandwidth modifiers >> added by RFC 3556. >>=20 >>=20 >>=20 >> I must admit that I haven=92t read all of RFC 3556 but as I understand i= t, >> a b=3D line are not in any way related to an actual format of a media >> description. This means that with this mechanism, only one bitrate >> specification can be sent with each media description. Different coding >> algorithms have different constraints on the allowed bitrate. For >> example, I might want to send an SDP offer with both Enhanced apt-X at >> 576 kbit/s and Opus at 510kbit/s with cbr. Now, specifying 576kbit/s via >> a b=3D line works for apt-X but makes no sense for Opus and vice versa. = I >> think that the a=3Dfmtp line is the correct place to specify the desired >> bitrate. >>=20 >>=20 >>=20 >> For the broadcasting use-case, it is often more important to have a >> constant and predictable audio quality and network usage than mere >> audibility at any cost. >>=20 >>=20 >>=20 >> Best regards, >>=20 >> Fredrik Bergholtz >>=20 >> Swedish Radio >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >>=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 >=20 > iQEcBAEBAgAGBQJUij/kAAoJEJ6/8sItn9q9V6EIALgEC6Iv+nZuu2BU8useaV4Z > jLRz97vCEdcmj60jMzELC2gSKLpVW3AMcbP7gtPjm0odeLFEMvoweUFytnVt/cd6 > bCadjHMPAOSNXrPtbmS57JdlcmWHnsrJIVrsV/Ipn6o44FWL2BN5g/LnwlSTKs/N > OtrjAdLj8b/GsmVS6VTTjTkygL1bp1Wsry5oAGXIPwPqFgQwuGMAxv/Wf6eEu7c3 > eoZzBKfBDM0bC8L+RCy6REYKHvSjPbyPAH0bQvkkKHfSc6I5ZLOZspvOHBmHvQFu > DNj4DHCShHPnRRknVnXCXX9ddSC4/bLQSyZ9+WI9622N5lkre8+VnUIGx9iAr3I=3D > =3DZuN4 > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Wed Dec 31 01:42:52 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ECC1A8AAC for ; Wed, 31 Dec 2014 01:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oc2fUh7iqI87 for ; Wed, 31 Dec 2014 01:42:48 -0800 (PST) Received: from mail-3.sr.se (mail-3.sr.se [192.165.8.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8E01A6EEF for ; Wed, 31 Dec 2014 01:42:47 -0800 (PST) X-Halon-ID: 5e39a170-90d1-11e4-b5a7-000c2976599e DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sverigesradio.se; s=sverigesradio; h=x-halon-id:received:received:received:from:to:cc:subject:thread-topic: thread-index:date:message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator:x-c2processedorg: content-type:content-transfer-encoding:mime-version; bh=MTO1BzqeGZ6vhwvmzAZKvyksBelEk3sMS3ZvdPqw5Iw=; b=e3ulaX8LvKJyA6ucdn3twzNCD+17qFZ6hxeq4MvjlCi595ceW3b6bY+DnIVpKbHfP0RnxJ1rITGoN CpuwbpWJapY6PdLLyJ9teujWpEBjM64fO/7wyKcZD+W3uIKgzY9k7OIKQriFw3U0jCmrrnPgyXlMN9 3vtX/E5zt8wo5GMo= Received: from RDCEX22.sr.se (unknown [134.25.170.83]) by mail-3.sr.se (Halon Mail Gateway) with ESMTPS; Wed, 31 Dec 2014 10:42:43 +0100 (CET) Received: from RDCEX21.sr.se (134.25.170.82) by RDCEX22.sr.se (134.25.170.83) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 31 Dec 2014 10:42:42 +0100 Received: from RDCEX21.sr.se ([fe80::cc2e:f081:5e77:d52e]) by RDCEX21.sr.se ([fe80::cc2e:f081:5e77:d52e%21]) with mapi id 15.00.0995.028; Wed, 31 Dec 2014 10:42:42 +0100 From: Fredrik Bergholtz To: "Ali C. Begen (abegen)" Thread-Topic: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53AB992kAA8ORFIAADAt6MQ== Date: Wed, 31 Dec 2014 09:42:41 +0000 Message-ID: <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> References: <548A3FEA.2070400@mozilla.com>, In-Reply-To: Accept-Language: en-GB, sv-SE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: 17a716aa-7169-4253-8985-281a7037fe2e Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/TgiSd9asIQOFpCkpjhWyEmL20Go Cc: "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 09:42:51 -0000 Yes, I do see a strong need for specifying the bitrate.=20 In the broadcasting use case we have to make sure that we get the best audi= o quality that is possible for the network that is currently used but never= try to send more data than the particular link is capable of. For this rea= son, specifying a maximum bit rate is required. In addition we often have the requirement that the quality is constant rath= er than the best possible. To avoid as many audible changes in the audio as= possible over time we will often use constant bit rate and then it becomes= even more important to be able to specify what bit rate should be.=20 We will use the Opus codec over various network links with different capabi= lities in terms of bit rate, delay variation, absolute delay, etc and we wi= ll typically use the SDP to signal the parameters that best fit both the cu= rrent network and the current type of radio production.=20 Best regards Fredrik Bergholtz Swedish Radio > On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)" wrot= e: >=20 > My understanding is that the b=3D line in the SDP is quite a subjective p= arameter. I have seen people use it differently over the past several years= . So, it is a bit difficult to infer much accuracy from that line. >=20 > OTOH, if someone feels like Opus needs to specify some sort of bitrate va= riability in the SDP, it can do so in an optional (opus) parameter. Obvious= ly rules around how to set that value and what to do with that value need t= o be clearly specified. >=20 > Fredrik (or anyone else in the WG), do you see a strong need for this? If= so, now is the time to mention that. >=20 > -acbegen >=20 >=20 >> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin wrote= : >>=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> I have to say this is not something I understand really well. Does >> anyone else here have an opinion on how to specify bit-rate? >>=20 >> Jean-Marc >>=20 >>> On 10/12/14 05:11 AM, Fredrik Bergholtz wrote: >>> Hi. >>>=20 >>>=20 >>>=20 >>> I read in the latest draft that you have removed the maxaveragebitrate >>> parameter from the SDP signalling for Opus. I think that this parameter >>> is useful and that it provides added value over the bandwidth modifiers >>> added by RFC 3556. >>>=20 >>>=20 >>>=20 >>> I must admit that I haven=92t read all of RFC 3556 but as I understand = it, >>> a b=3D line are not in any way related to an actual format of a media >>> description. This means that with this mechanism, only one bitrate >>> specification can be sent with each media description. Different coding >>> algorithms have different constraints on the allowed bitrate. For >>> example, I might want to send an SDP offer with both Enhanced apt-X at >>> 576 kbit/s and Opus at 510kbit/s with cbr. Now, specifying 576kbit/s vi= a >>> a b=3D line works for apt-X but makes no sense for Opus and vice versa.= I >>> think that the a=3Dfmtp line is the correct place to specify the desire= d >>> bitrate. >>>=20 >>>=20 >>>=20 >>> For the broadcasting use-case, it is often more important to have a >>> constant and predictable audio quality and network usage than mere >>> audibility at any cost. >>>=20 >>>=20 >>>=20 >>> Best regards, >>>=20 >>> Fredrik Bergholtz >>>=20 >>> Swedish Radio >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >>=20 >> iQEcBAEBAgAGBQJUij/kAAoJEJ6/8sItn9q9V6EIALgEC6Iv+nZuu2BU8useaV4Z >> jLRz97vCEdcmj60jMzELC2gSKLpVW3AMcbP7gtPjm0odeLFEMvoweUFytnVt/cd6 >> bCadjHMPAOSNXrPtbmS57JdlcmWHnsrJIVrsV/Ipn6o44FWL2BN5g/LnwlSTKs/N >> OtrjAdLj8b/GsmVS6VTTjTkygL1bp1Wsry5oAGXIPwPqFgQwuGMAxv/Wf6eEu7c3 >> eoZzBKfBDM0bC8L+RCy6REYKHvSjPbyPAH0bQvkkKHfSc6I5ZLOZspvOHBmHvQFu >> DNj4DHCShHPnRRknVnXCXX9ddSC4/bLQSyZ9+WI9622N5lkre8+VnUIGx9iAr3I=3D >> =3DZuN4 >> -----END PGP SIGNATURE----- >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >=20 From nobody Wed Dec 31 03:27:05 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B79E1A8AD9 for ; Wed, 31 Dec 2014 03:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5xwqB6Kd6ol for ; Wed, 31 Dec 2014 03:27:00 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F18F1A8AC6 for ; Wed, 31 Dec 2014 03:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11788; q=dns/txt; s=iport; t=1420025220; x=1421234820; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BmgQDdr5Q3WHZSFmY3eo7J4oLMu2Fkz4EOtWGEeZggo=; b=aMLep9gutur2rGnCTZ2KBIPbA83skwALSOE/RMLHBcXQ18lvT5ZhH2uZ PYt7i3uS/L8bc5haI2Ak1yFu46JHwcoSuSQHsz+uTJ2b33dZvbkQ7u9tx Vdxo/0um/O22WkGeg3+hp7eDwiIJB1aYzBDisRLnI7vT/AqZ81QzCqX92 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcFAGHdo1StJA2F/2dsb2JhbABcgkMhIlJYxiwBCYUpSgKBBhYBAQEBAX2EDAEBAQMBAQEBKkELBQsCAQgRBAEBAS4nCx0IAQEEDgUbiAkIAQzHEQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj3MEBwaEIwWOFYhzgQ2CZYIziysiggEdgVBvgkMBAQE X-IronPort-AV: E=Sophos;i="5.07,672,1413244800"; d="scan'208,217";a="383565733" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP; 31 Dec 2014 11:26:41 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sBVBQfAT021838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Dec 2014 11:26:41 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 31 Dec 2014 05:26:41 -0600 From: "Ali C. Begen (abegen)" To: Fredrik Bergholtz Thread-Topic: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Thread-Index: AdATp89X++FTuPj7QpWp8hHcyPj53ACMooEAA8OQx4AACfM1gP//uHjz Date: Wed, 31 Dec 2014 11:26:40 +0000 Message-ID: <26b91d07-8e22-4790-b06e-564ee30b071d@cisco.com> References: <548A3FEA.2070400@mozilla.com>, , <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> In-Reply-To: <7E6F2FBF-3E29-4608-A9AE-2C5124BCE261@sverigesradio.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_26b91d078e224790b06e564ee30b071dciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/P2gnfszTaRM-Urhkxa4ZvRu1QuU Cc: "payload@ietf.org" Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 11:27:03 -0000 --_000_26b91d078e224790b06e564ee30b071dciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Authors Please chime in and lets discuss s quick solution for this on the list. Onc= e agreed we can ship this draft. -acbegen From: Fredrik Bergholtz Sent: Dec 31, 2014 11:42 AM To: Ali C. Begen (abegen) Cc: Jean-Marc Valin ;Fredrik Bergholtz;payload@ietf.or= g Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebitrate Yes, I do see a strong need for specifying the bitrate. In the broadcasting use case we have to make sure that we get the best audi= o quality that is possible for the network that is currently used but never= try to send more data than the particular link is capable of. For this rea= son, specifying a maximum bit rate is required. In addition we often have the requirement that the quality is constant rath= er than the best possible. To avoid as many audible changes in the audio as= possible over time we will often use constant bit rate and then it becomes= even more important to be able to specify what bit rate should be. We will use the Opus codec over various network links with different capabi= lities in terms of bit rate, delay variation, absolute delay, etc and we wi= ll typically use the SDP to signal the parameters that best fit both the cu= rrent network and the current type of radio production. Best regards Fredrik Bergholtz Swedish Radio > On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)" wrot= e: > > My understanding is that the b=3D line in the SDP is quite a subjective p= arameter. I have seen people use it differently over the past several years= . So, it is a bit difficult to infer much accuracy from that line. > > OTOH, if someone feels like Opus needs to specify some sort of bitrate va= riability in the SDP, it can do so in an optional (opus) parameter. Obvious= ly rules around how to set that value and what to do with that value need t= o be clearly specified. > > Fredrik (or anyone else in the WG), do you see a strong need for this? If= so, now is the time to mention that. > > -acbegen > > >> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin wrote= : >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I have to say this is not something I understand really well. Does >> anyone else here have an opinion on how to specify bit-rate? >> >> Jean-Marc >> >>> On 10/12/14 05:11 AM, Fredrik Bergholtz wrote: >>> Hi. >>> >>> >>> >>> I read in the latest draft that you have removed the maxaveragebitrate >>> parameter from the SDP signalling for Opus. I think that this parameter >>> is useful and that it provides added value over the bandwidth modifiers >>> added by RFC 3556. >>> >>> >>> >>> I must admit that I haven=92t read all of RFC 3556 but as I understand = it, >>> a b=3D line are not in any way related to an actual format of a media >>> description. This means that with this mechanism, only one bitrate >>> specification can be sent with each media description. Different coding >>> algorithms have different constraints on the allowed bitrate. For >>> example, I might want to send an SDP offer with both Enhanced apt-X at >>> 576 kbit/s and Opus at 510kbit/s with cbr. Now, specifying 576kbit/s vi= a >>> a b=3D line works for apt-X but makes no sense for Opus and vice versa.= I >>> think that the a=3Dfmtp line is the correct place to specify the desire= d >>> bitrate. >>> >>> >>> >>> For the broadcasting use-case, it is often more important to have a >>> constant and predictable audio quality and network usage than mere >>> audibility at any cost. >>> >>> >>> >>> Best regards, >>> >>> Fredrik Bergholtz >>> >>> Swedish Radio >>> >>> >>> >>> >>> >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> >> iQEcBAEBAgAGBQJUij/kAAoJEJ6/8sItn9q9V6EIALgEC6Iv+nZuu2BU8useaV4Z >> jLRz97vCEdcmj60jMzELC2gSKLpVW3AMcbP7gtPjm0odeLFEMvoweUFytnVt/cd6 >> bCadjHMPAOSNXrPtbmS57JdlcmWHnsrJIVrsV/Ipn6o44FWL2BN5g/LnwlSTKs/N >> OtrjAdLj8b/GsmVS6VTTjTkygL1bp1Wsry5oAGXIPwPqFgQwuGMAxv/Wf6eEu7c3 >> eoZzBKfBDM0bC8L+RCy6REYKHvSjPbyPAH0bQvkkKHfSc6I5ZLOZspvOHBmHvQFu >> DNj4DHCShHPnRRknVnXCXX9ddSC4/bLQSyZ9+WI9622N5lkre8+VnUIGx9iAr3I=3D >> =3DZuN4 >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > --_000_26b91d078e224790b06e564ee30b071dciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Authors

Please chime in and lets discuss s quick solution for this o= n the list. Once agreed we can ship this draft.

-acbegen

Fro= m: Fredrik Bergholtz <fredrik.bergholtz@sverigesradio.se>
Sent: Dec 31, 2014 11:42 AM
To: Ali C. Begen (abegen)
Cc: Jean-Marc Valin <jmvalin@mozilla.com>;Fredrik Bergholtz;pa= yload@ietf.org
Subject: Re: [payload] draft-ietf-payload-rtp-opus-05: maxaveragebit= rate

Yes, I do see a strong need for specifying the bit= rate.

In the broadcasting use case we have to make sure that we get the best audi= o quality that is possible for the network that is currently used but never= try to send more data than the particular link is capable of. For this rea= son, specifying a maximum bit rate is required.

In addition we often have the requirement that the quality is constant rath= er than the best possible. To avoid as many audible changes in the audio as= possible over time we will often use constant bit rate and then it becomes= even more important to be able to specify what bit rate should be.

We will use the Opus codec over various network links with different capabi= lities in terms of bit rate, delay variation, absolute delay, etc and we wi= ll typically use the SDP to signal the parameters that best fit both the cu= rrent network and the current type of radio production.

Best regards
Fredrik Bergholtz
Swedish Radio


> On 31 dec 2014, at 05:57, "Ali C. Begen (abegen)" <abegen= @cisco.com> wrote:
>
> My understanding is that the b=3D line in the SDP is quite a subjectiv= e parameter. I have seen people use it differently over the past several ye= ars. So, it is a bit difficult to infer much accuracy from that line.
>
> OTOH, if someone feels like Opus needs to specify some sort of bitrate= variability in the SDP, it can do so in an optional (opus) parameter. Obvi= ously rules around how to set that value and what to do with that value nee= d to be clearly specified.
>
> Fredrik (or anyone else in the WG), do you see a strong need for this?= If so, now is the time to mention that.
>
> -acbegen
>
>
>> On Dec 12, 2014, at 3:07 AM, Jean-Marc Valin <jmvalin@mozilla.c= om> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I have to say this is not something I understand really well. Does=
>> anyone else here have an opinion on how to specify bit-rate?
>>
>>    Jean-Marc
>>
>>> On 10/12/14 05:11 AM, Fredrik Bergholtz wrote:
>>> Hi.
>>>
>>>
>>>
>>> I read in the latest draft that you have removed the maxaverag= ebitrate
>>> parameter from the SDP signalling for Opus. I think that this = parameter
>>> is useful and that it provides added value over the bandwidth = modifiers
>>> added by RFC 3556.
>>>
>>>
>>>
>>> I must admit that I haven=92t read all of RFC 3556 but as I un= derstand it,
>>> a b=3D line are not in any way related to an actual format of = a media
>>> description. This means that with this mechanism, only one bit= rate
>>> specification can be sent with each media description. Differe= nt coding
>>> algorithms have different constraints on the allowed bitrate. = For
>>> example, I might want to send an SDP offer with both Enhanced = apt-X at
>>> 576 kbit/s and Opus at 510kbit/s with cbr. Now, specifying 576= kbit/s via
>>> a b=3D line works for apt-X but makes no sense for Opus and vi= ce versa. I
>>> think that the a=3Dfmtp line is the correct place to specify t= he desired
>>> bitrate.
>>>
>>>
>>>
>>> For the broadcasting use-case, it is often more important to h= ave a
>>> constant and predictable audio quality and network usage than = mere
>>> audibility at any cost.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Fredrik Bergholtz
>>>
>>> Swedish Radio
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> payload mailing list
>>> payload@ietf.org
>>> http= s://www.ietf.org/mailman/listinfo/payload
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJUij/kAAoJEJ6/8sItn9q9V6EIALgEC6Iv+nZuu2BU8useaV= 4Z
>> jLRz97vCEdcmj60jMzELC2gSKLpVW3AMcbP7gtPjm0odeLFEMvoweUFytnVt/cd6 >> bCadjHMPAOSNXrPtbmS57JdlcmWHnsrJIVrsV/Ipn6o44FWL2BN5g/LnwlSTKs/N >> OtrjAdLj8b/GsmVS6VTTjTkygL1bp1Wsry5oAGXIPwPqFgQwuGMAxv/Wf6eEu7c3 >> eoZzBKfBDM0bC8L+RCy6REYKHvSjPbyPAH0bQvkkKHfSc6I5ZLOZspvOHBmHvQ= Fu
>> DNj4DHCShHPnRRknVnXCXX9ddSC4/bLQSyZ9+WI9622N5lkre8+VnUIGx9= iAr3I=3D
>> =3DZuN4
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> payload mailing list
>> payload@ietf.org
>> https://= www.ietf.org/mailman/listinfo/payload
>
--_000_26b91d078e224790b06e564ee30b071dciscocom_--