From nobody Tue Mar 3 12:52:37 2015 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 E3D5F1A894F; Tue, 3 Mar 2015 12:52:33 -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 f1VeJZC4jldl; Tue, 3 Mar 2015 12:52:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6503B1A895B; Tue, 3 Mar 2015 12:52:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150303205231.10208.20421.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 12:52:31 -0800 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-14.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, 03 Mar 2015 20:52:34 -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 VP8 Video Authors : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-14.txt Pages : 25 Date : 2015-03-03 Abstract: This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-vp8-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-14 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 Mar 3 12:56:59 2015 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 C28361A895D for ; Tue, 3 Mar 2015 12:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.193 X-Spam-Level: X-Spam-Status: No, score=0.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 M0UUU9Cpby-o for ; Tue, 3 Mar 2015 12:56:51 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C35E1A8965 for ; Tue, 3 Mar 2015 12:56:50 -0800 (PST) Received: by igbhl2 with SMTP id hl2so28918157igb.0 for ; Tue, 03 Mar 2015 12:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NyvjXcJMkH0iKLdgp3/BO/AaKrKXh2j2D29pENqlmys=; b=XkcXz1hh/4VCsFPPzkEcSAVOaeKa5F2wsjGBaJKcOWSliioGmTEyYPBelra75N4Qrc Tkn60GCe4VYIayMUkPjbP+8c+OMU95PiHwQVf1mSBZBD3wXqUY7zJD6LCebB9aklgOo3 p5o+4G4IwEiQlWSN1HkPL28L8d4891olB6FnoZti8hnyowGc8IB3CENgx/Zli5oeTBkZ 1uILwan71dMFLkC1+RU+oB0r1LiQrJtDozUEDZ7NSTTEMP7wzl7DsoDnSf3NynWqqY2l qPGvJcJKDl5xFTv/Ptbk8nAnRNjpJkznPdTK5UMgcC368xpdQ8KEi5RCB3ln2vABDrMx j6mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NyvjXcJMkH0iKLdgp3/BO/AaKrKXh2j2D29pENqlmys=; b=OhSOdkS+z+uByppJfZ28CF9lfgPY9w3EIn2IRpW7cHHHBN4Jze9wHWJXgGLppDK0pL W5lAc5p9pYRJBo04gvjoEDNvNP2i9ldCDpq41zH0z/F7UoMXcCX0qo6SqJgS+h0JGbMI u8bU0unXZZwv8OAiXxZnQVcAQOAfUpj6rnfTEE7bCY3So5tyRXxSDp9Bt8SBEM7/H3Ft TpGWT44UfaME9CG+f6d9VQZ+i59rAIiW0VGCPYYTDoqFFIYtSsEe30xO9hh12YtjZjcE sMdbn7KDekV6F7n5u2ohClUp9bh1ExJkm9t4OKfUQL7IA4pHasv5s1zUdqMaPYAsDabC ZE+g== X-Gm-Message-State: ALoCoQnSNRWkGoUfYrRoVkCzBMIbhuERP9QwW0OU+bYMJXLDuUR34bZ7JJNkXof1P+3vSxBF2Nmo MIME-Version: 1.0 X-Received: by 10.107.137.101 with SMTP id l98mr4879574iod.23.1425416209385; Tue, 03 Mar 2015 12:56:49 -0800 (PST) Received: by 10.64.149.7 with HTTP; Tue, 3 Mar 2015 12:56:49 -0800 (PST) In-Reply-To: <00e801d003b8$18880ea0$49982be0$@gmail.com> References: <013301cf9a71$2f863420$8e929c60$@gmail.com> <39731C83-C883-4E7A-9F0F-C007C7B9AD0E@live555.com> <5457CB53.1080805@alvestrand.no> <546B6082.8030205@alvestrand.no> <00e801d003b8$18880ea0$49982be0$@gmail.com> Date: Tue, 3 Mar 2015 21:56:49 +0100 Message-ID: From: Henrik Lundin To: Roni Even Content-Type: multipart/alternative; boundary=001a113ed540d1674b0510689221 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 (draft-ietf-payload-vp8-11) 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, 03 Mar 2015 20:56:53 -0000 --001a113ed540d1674b0510689221 Content-Type: text/plain; charset=UTF-8 A new version was submitted with Harald's proposal: https://tools.ietf.org/html/draft-ietf-payload-vp8-14 Sincerely, /Henrik On Wed, Nov 19, 2014 at 6:17 AM, Roni Even wrote: > Hi, > I am OK with herald proposal > Roni > > > -----Original Message----- > > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Harald > > Alvestrand > > Sent: 18 November, 2014 5:07 PM > > To: payload@ietf.org; Roni Even > > Subject: Re: [payload] WGLC for VP8 (draft-ietf-payload-vp8-11) > > > > Just a ping - want to check that the fix suggested is acceptable to Roni > and the > > WG before getting it committed. > > > > Den 03. nov. 2014 19:37, skrev Harald Alvestrand: > > > On 10/27/2014 11:56 PM, Ross Finlayson wrote: > > >>> On Jul 7, 2014, at 10:55 PM, Roni Even > >>> > wrote: > > >>> > > >>> Hi, > > >>> I reviewed the document and have some comments as individual > > >> [.] > > >>> 6. In section 6.2.2 what is the meaning of max-fr and max-fs if the > > >>> stream is sendonly? > > >> > > >> Ditto if a 'declarative' SDP description is generated for a stream - > > >> e.g., for RTSP? > > >> > > >> Section 6.2.1 "Mapping of Media Subtype Parameters to SDP" of the > > >> latest VP8 payload format draft ("draft-ietf-payload-vp8-13") says > > >> The parameters "max-fs", and "max-fr", MUST be included in the > > >> "a=fmtp" line of SDP I think this is too strong. IMHO it should be a > > >> MUST only if the SDP is used in an 'offer-answer' environment, and > > >> the stream is not 'sendonly' (i.e., the offerer is asking to receive > > >> video). > > >> > > >> Also, BTW, the same language is in the corresponding section (7.2.1) > > >> of the new VP9 RTP payload format draft: "draft-uberti-payload-vp9-00" > > >> > > > > > > Thanks, this fix seems reasonable: > > > > > > - MUST be included if the SDP is used to declare receiver capabilities > > > > > > I don't want to get into the quagmire of describing all the situations > > > where it is (or isn't) used in that way. > > > > > > I'm unsure what we should do on sendonly; MUST NOT would be logical > > > and consistent, but seems to complicate implementations that just want > > > to hardcode their SDP strings to the extent possible. MAY, and say > > > that the a=fmtp parameters are then those that would have been used if > > > the stream had been receive-only? > > > > > > I'm sure we can get the same fix into VP9. This is not where we want > > > to be creative :-) > > > > > >> > > >> > > >> Ross Finlayson > > >> Live Networks, Inc. > > >> http://www.live555.com/ > > >> > > >> > > >> > > >> _______________________________________________ > > >> payload mailing list > > >> payload@ietf.org > > >> https://www.ietf.org/mailman/listinfo/payload > > > > > > > > > -- > > > Surveillance is pervasive. Go Dark. > > > > > > > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --001a113ed540d1674b0510689221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A new version was submitted with Harald's proposal:=C2= =A0https:= //tools.ietf.org/html/draft-ietf-payload-vp8-14

Sinc= erely,
/Henrik


On Wed, Nov 19, 2014 at 6:17 AM, Roni Eve= n <ron.even.tlv@gmail.com> wrote:
Hi,
I am OK with herald proposal
Roni

> -----Original Message-----
> From: payload [mailto:payl= oad-bounces@ietf.org] On Behalf Of Harald
> Alvestrand
> Sent: 18 November, 2014 5:07 PM
> To: payload@ietf.org; Roni Eve= n
> Subject: Re: [payload] WGLC for VP8 (draft-ietf-payload-vp8-11)
>
> Just a ping - want to check that the fix suggested is acceptable to Ro= ni
and the
> WG before getting it committed.
>
> Den 03. nov. 2014 19:37, skrev Harald Alvestrand:
> > On 10/27/2014 11:56 PM, Ross Finlayson wrote:
> >>> On Jul 7, 2014, at 10:55 PM, Roni Even <ron.even.tlv@gmail.com
> >>> <mailto:ron.= even.tlv@gmail.com>> wrote:
> >>>
> >>> Hi,
> >>> I reviewed the document and have some comments as individ= ual
> >> [.]
> >>> 6. In section 6.2= .2 what is the meaning of max-fr and max-fs if the
> >>> stream is sendonly?
> >>
> >> Ditto if a 'declarative' SDP description is generated= for a stream -
> >> e.g., for RTSP?
> >>
> >> Section 6.2.1 "Mapping of Media Subtype Parameters to SD= P" of the
> >> latest VP8 payload format draft ("draft-ietf-payload-vp8= -13") says
> >> The parameters "max-fs", and "max-fr", MU= ST be included in the
> >> "a=3Dfmtp" line of SDP I think this is too strong.= =C2=A0 IMHO it should be a
> >> MUST only if the SDP is used in an 'offer-answer' env= ironment, and
> >> the stream is not 'sendonly' (i.e., the offerer is as= king to receive
> >> video).
> >>
> >> Also, BTW, the same language is in the corresponding section = (7.2.1)
> >> of the new VP9 RTP payload format draft: "draft-uberti-p= ayload-vp9-00"
> >>
> >
> > Thanks, this fix seems reasonable:
> >
> > - MUST be included if the SDP is used to declare receiver capabil= ities
> >
> > I don't want to get into the quagmire of describing all the s= ituations
> > where it is (or isn't) used in that way.
> >
> > I'm unsure what we should do on sendonly; MUST NOT would be l= ogical
> > and consistent, but seems to complicate implementations that just= want
> > to hardcode their SDP strings to the extent possible. MAY, and sa= y
> > that the a=3Dfmtp parameters are then those that would have been = used if
> > the stream had been receive-only?
> >
> > I'm sure we can get the same fix into VP9. This is not where = we want
> > to be creative :-)
> >
> >>
> >>
> >> Ross Finlayson
> >> Live Networks, Inc.
> >> http://= www.live555.com/
> >>
> >>
> >>
> >> _______________________________________________
> >> payload mailing list
> >> payload@ietf.org
> >> https://www.ietf.org/mailman/listinfo/payload
> >
> >
> > --
> > Surveillance is pervasive. Go Dark.
> >
> >
> >
> > _______________________________________________
> > 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

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload



--
=
= Henrik Lundin=C2=A0|=C2=A0WebRTC Software Eng=C2=A0|=C2=A0hlundin@google.com=C2=A0|= =C2=A0+46 70 646 13 41

--001a113ed540d1674b0510689221-- From nobody Thu Mar 5 12:25:59 2015 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 63B7F1A8A68 for ; Thu, 5 Mar 2015 12:25:58 -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 t1Y8duf4cdON for ; Thu, 5 Mar 2015 12:25:51 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208881A8A67 for ; Thu, 5 Mar 2015 12:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7382; q=dns/txt; s=iport; t=1425587151; x=1426796751; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bzZICtXcCgj+dQKsK4Cn5z6JwLxqvGYD1sdrHsaIZjQ=; b=VMtbUVpDFRm4yIN7W9QTxlClzdfS6VeXYgwVtluWI7EXgblaWnt34fmy d4q89Ah7OjeGtPkxtY3A+LI/bG2YlMu0JLkI1WjPHPtt2fI0t/8VYLN99 +7Mvz7ZSJOt6zQTD0UW3MF0f0i37K3L828f1O05Dfx/DxPA2ew5iqq7c2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DnBQB1u/hU/51dJa1agkNDUlUFBL8/gXABCYUnSQKBO00BAQEBAQF8hBABAQQBAQFlBgsQAgEIPwcnCxQRAgQOBQmIJggF2CgBAQEBAQEBAwEBAQEBAQEBAQEBF4sXhGoEBwmEIgWOB4IAg2OFaoEaOYJtjy8jg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,348,1422921600"; d="scan'208,217";a="129338192" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 05 Mar 2015 20:25:50 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t25KPo2v015438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 20:25:50 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 14:25:49 -0600 From: "Mo Zanaty (mzanaty)" To: "draft-ietf-payload-vp8@tools.ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-vp8-14.txt Thread-Index: AQHQV4KRtiskyQQX60ea5utmiik65Q== Date: Thu, 5 Mar 2015 20:25:49 +0000 Message-ID: References: <20150303205231.10208.20421.idtracker@ietfa.amsl.com> In-Reply-To: <20150303205231.10208.20421.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.150.31.38] Content-Type: multipart/alternative; boundary="_000_D11E22FF472D3mzanatyciscocom_" MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-14.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: Thu, 05 Mar 2015 20:25:58 -0000 --_000_D11E22FF472D3mzanatyciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The simulcast draft (draft-ietf-mmusic-sdp-simulcast) uses payload formats = to express different simulcast encodings. This assumes the underlying paylo= ad format can express the desired encodings in its a=3Dfmtp parameters. VP8= can express max-fs (roughly resolution) and max-fr (frame rate), which cov= ers most simulcast use cases. However, you may want to consider adding max-= br (bit rate) if you want to express simulcasting VP8 at different bit rate= s (for the same or different resolutions and frame rates). Regards, Mo On 3/3/15, 3:52 PM, internet-drafts@ietf.org > wrote: 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 Gro= up of the IETF. Title : RTP Payload Format for VP8 Video Authors : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-14.txt Pages : 25 Date : 2015-03-03 Abstract: This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-vp8-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-14 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 --_000_D11E22FF472D3mzanatyciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <54C29DE5954B074F85F06CFDE5D5126A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

The simulcast draft (draft-ietf-mmusic-sdp-simulcast) uses payload for= mats to express different simulcast encodings. This assumes the underlying = payload format can express the desired encodings in its a=3Dfmtp parameters= . VP8 can express max-fs (roughly resolution) and max-fr (frame rate), which covers most simulcast use cases= . However, you may want to consider adding max-br (bit rate) if you want to= express simulcasting VP8 at different bit rates (for the same or different= resolutions and frame rates).

Regards,
Mo
 



A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF.

        Title   = ;        : RTP Payload Format for VP8 Vi= deo
        Authors  &nb= sp;      : Patrik Westin
           &nbs= p;            &= nbsp; Henrik F Lundin
           &nbs= p;            &= nbsp; Michael Glover
           &nbs= p;            &= nbsp; Justin Uberti
           &nbs= p;            &= nbsp; Frank Galligan
Filena= me        : draft-ietf-payload-vp8-= 14.txt
Pages&= nbsp;          : 25
Date&n= bsp;           : 201= 5-03-03

Abstract:
   This memo describes an RTP payload format for the VP8 vid= eo codec.
   The payload format has wide applicability, as it supports=
   applications from low bit-rate peer-to-peer usage, to hig= h bit-rate
   video conferences.


The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:


Please note that it may take a couple of minutes from the time of subm= ission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:

_______________________________________________
payload mailing list

--_000_D11E22FF472D3mzanatyciscocom_-- From nobody Thu Mar 5 19:08:45 2015 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 3403C1AC3BB for ; Thu, 5 Mar 2015 19:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, 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 schm6mI94es2 for ; Thu, 5 Mar 2015 19:08:42 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F581AC3C4 for ; Thu, 5 Mar 2015 19:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5106; q=dns/txt; s=iport; t=1425611321; x=1426820921; h=from:to:cc:subject:date:message-id:mime-version; bh=K4aK5QotHyMC+O319hOQXTg9lWt+HF0dI9W2my4HnQ8=; b=PElz3HknD68vFQ/vKXtWdo6bBMJaMoTNoqmmdaADb3Gf1siykk8yq/z7 Op9p5tpptAoU30AKapk1KaI3VO2Jf+rLKzIWNd8arDh5oKW3G1/ZYXBJQ 81Nh0hj71Bvc9mEyWefVqvx8/nA6yCxa9qXlJ/Q3fLCPHDC+Pomox+o7n A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJBQCxGflU/5BdJa1cgkNDgTDHN4E/TQEBAQEBAXyEFnkSAQx0JwQOiDTTQwEBAQEBAQEDAQEBAQEBAQEajyJjhDIFkAeFe4NSk28jg26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,350,1422921600"; d="scan'208,217";a="129381772" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP; 06 Mar 2015 03:08:40 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2638eTW022146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Mar 2015 03:08:40 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 21:08:40 -0600 From: "Mo Zanaty (mzanaty)" To: "draft-ietf-payload-rtp-h265@tools.ietf.org" Thread-Topic: DON in H.265 RTP draft Thread-Index: AQHQV7rY/VilcNCsCUOrqBDdMos+9A== Date: Fri, 6 Mar 2015 03:08:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [64.100.32.216] Content-Type: multipart/alternative; boundary="_000_D11E8469474F4mzanatyciscocom_" MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" Subject: [payload] DON in H.265 RTP draft 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, 06 Mar 2015 03:08:44 -0000 --_000_D11E8469474F4mzanatyciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on implementation experience with DON in draft-ietf-payload-rtp-h265-= 07, here are some suggested changes in the draft to simplify implementation= s and improve robustness. DON (Decoding Order Number) DON is only necessary when using interleaved transmission (for error resili= ence) or reordered frames (for coding efficiency), if willing to incur the = additional latency and complexity of these techniques. These techniques are= not used in many (probably most) systems, so DON should not be required in= those cases. However, the current draft requires DON when tx-mode is MRST or MRMT (or sp= rop-max-don-diff>0). This causes unnecessary complexity, RTP packet overhea= d, and potential for RTP packet parsing failure due to conditional DON fiel= ds whose presence depends on subtle SDP rules. If implementations interpret= these subtle SDP rules differently or improperly, RTP packet parsing compl= etely fails, which is undesirably fragile. The suggested change is to revert to the original design in the individual = 00 draft (and RFC 6190), which uses separate explicit payload structures fo= r RTP packets without DON (FU-A, STAP-A) and with DON (FU-B, STAP-B). Recei= vers must still support DON, but senders only use it when necessary, i.e. i= nterleaved transmission or reordered frames. This has several benefits. a. RTP packet parsing is more robust since RTP packets are self-describing = with no dependency on subtle SDP rules. b. RTP packet overhead is reduced in cases where DON is unnecessary, includ= ing many/most MRST and MRMT cases. c. Aligns better with H.264 so those implementations can more easily add H.= 265. The only drawback is this requires 2 extra NAL unit types (51, 52), but tha= t is acceptable since the space is doubled in H.265 (64 vs. 32 in H.264). If there is agreement on this suggested change, I will propose specific tex= t changes. Although conceptually simple, it does impact a non-trivial amoun= t of text, mostly repeated. Regards, Mo --_000_D11E8469474F4mzanatyciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <21BB452F981B834CBD12B790AFF64DE9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,
Based on implementation experience with DON in draft-ietf-payload-rtp-= h265-07, here are some suggested changes in the draft to simplify implement= ations and improve robustness.

DON (Decoding Order Number)

DON is only necessary when using interleaved transmission (for error r= esilience) or reordered frames (for coding efficiency), if willing to incur= the additional latency and complexity of these techniques. These technique= s are not used in many (probably most) systems, so DON should not be required in those cases. 

However, the current draft requires DON when tx-mode is MRST or MRMT (= or sprop-max-don-diff>0). This causes unnecessary complexity, RTP packet= overhead, and potential for RTP packet parsing failure due to conditional = DON fields whose presence depends on subtle SDP rules. If implementations interpret these subtle SDP rules diff= erently or improperly, RTP packet parsing completely fails, which is undesi= rably fragile.

The suggested change is to revert to the original design in the indivi= dual 00 draft (and RFC 6190), which uses separate explicit payload structur= es for RTP packets without DON (FU-A, STAP-A) and with DON (FU-B, STAP-B). = Receivers must still support DON, but senders only use it when necessary, i.e. interleaved transmission or r= eordered frames. This has several benefits.

a. RTP packet parsing is more robust since RTP packets are self-descri= bing with no dependency on subtle SDP rules.
b. RTP packet overhead is reduced in cases where DON is unnecessary, i= ncluding many/most MRST and MRMT cases.
c. Aligns better with H.264 so those implementations can more easily a= dd H.265.

The only drawback is this requires 2 extra NAL unit types (51, 52), bu= t that is acceptable since the space is doubled in H.265 (64 vs. 32 in H.26= 4).

If there is agreement on this suggested change, I will propose specifi= c text changes. Although conceptually simple, it does impact a non-trivial = amount of text, mostly repeated.

Regards,
Mo


--_000_D11E8469474F4mzanatyciscocom_-- From nobody Thu Mar 5 19:09:37 2015 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 112731AC3BE for ; Thu, 5 Mar 2015 19:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, 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 2Opz0D-hPb4J for ; Thu, 5 Mar 2015 19:09:34 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3ACA1AC3BB for ; Thu, 5 Mar 2015 19:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3192; q=dns/txt; s=iport; t=1425611374; x=1426820974; h=from:to:cc:subject:date:message-id:mime-version; bh=Xur9IWrRjG+iOlQtEcvf4iKCTXuxbWeiRJ5FXPH8XTY=; b=LFHiPdWxi14oO8aWdZt9yoEjT5PckslPj3EfnjroJUrbVJO9wuOzkB2M hgiv5V3CGiP6WtlI+mCYy10iVrNVYccoa6iNWAnZuvRR+tMx2zv3mPsOq 67FyJ0AAhyaMxqZX/7D1ktQisa7AKMdITXFu0rd5YA2URUTKMGofKvqnj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJBQCxGflU/4kNJK1cgkNDgTDHN4E/TQEBAQEBAXyEFnkSAQx0JwQOiDTTQwEBAQEBAQEDAQEBAQEBARuQBYQyBZAHiU2TbyODboIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,350,1422921600"; d="scan'208,217";a="129381881" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP; 06 Mar 2015 03:09:31 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2639VAU022717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Mar 2015 03:09:31 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 21:09:31 -0600 From: "Mo Zanaty (mzanaty)" To: "draft-ietf-payload-rtp-h265@tools.ietf.org" Thread-Topic: tx-mode in H.265 RTP draft Thread-Index: AQHQV7r2sraCp7G+kkawBZdanSxNxw== Date: Fri, 6 Mar 2015 03:09:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [64.100.32.216] Content-Type: multipart/alternative; boundary="_000_D11E849B474FBmzanatyciscocom_" MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" Subject: [payload] tx-mode in H.265 RTP draft 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, 06 Mar 2015 03:09:36 -0000 --_000_D11E849B474FBmzanatyciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on implementation experience with tx-mode in draft-ietf-payload-rtp-h= 265-07, here are some suggested changes in the draft to simplify implementa= tions and SDP as well as avoid PT exhaustion. tx-mode (Transmission Mode) The tx-mode parameter is a symmetric configuration point that can be SRST, = MRST or MRMT. If multiple are supported, each must be declared in a separat= e payload type, causing combinatorial explosion of tx-mode, profile, 4 othe= r configuration point parameters, simulcast streams, etc. It is better if t= he offer can declare support for multiple tx-mode values (comma separated) = in the same payload type, and the answer can select a (single) symmetric co= nfiguration point. For example, offer both SRST and MRST: a=3Dfmtp:96 tx-mode=3DSRST,MRST; ... Answer selects MRST: a=3Dfmtp:96 tx-mode=3DMRST; ... This is a very simple extension of the ABNF and SDP O/A rules with modest t= ext changes. It would require review by the SDP Directorate. If there is agreement on this suggested change, I will propose specific tex= t changes. Regards, Mo --_000_D11E849B474FBmzanatyciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <936BCA5AD68197428A9BE7DB02F7E228@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,
Based on implementation experience with tx-mode in draft-ietf-payload-= rtp-h265-07, here are some suggested changes in the draft to simplify imple= mentations and SDP as well as avoid PT exhaustion.
 
tx-mode (Transmission Mode)

The tx-mode parameter is a symmetric configuration point that can be S= RST, MRST or MRMT. If multiple are supported, each must be declared in a se= parate payload type, causing combinatorial explosion of tx-mode, profile, 4= other configuration point parameters, simulcast streams, etc. It is better if the offer can declare support for = multiple tx-mode values (comma separated) in the same payload type, and the= answer can select a (single) symmetric configuration point.

For example, offer both SRST and MRST:
a=3Dfmtp:96 tx-mode=3DSRST,MRST; ...

Answer selects MRST:
a=3Dfmtp:96 tx-mode=3DMRST; ...

This is a very simple extension of the ABNF and SDP O/A rules with mod= est text changes. It would require review by the SDP Directorate.

If there is agreement on this suggested change, I will propose specifi= c text changes.

Regards,
Mo

--_000_D11E849B474FBmzanatyciscocom_-- From nobody Thu Mar 5 22:04:23 2015 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 D6E331ACCDC for ; Thu, 5 Mar 2015 22:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.01 X-Spam-Level: X-Spam-Status: No, score=-6.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=1, HTML_MESSAGE=0.001, 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 f_AEGoPbFgXZ for ; Thu, 5 Mar 2015 22:04:19 -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 3BA891ACCDF for ; Thu, 5 Mar 2015 22:04:19 -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=1425621859; x=1457157859; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AXTZZdc1ZYat4XoL5h/dqiSYZx0IUclM5f2JM+28IiA=; b=bmPrMwDkbsYv6a4Scn/q1FNnoWXnL59gfqHsymLhernM9QatTFmZBFnS GZ2V2BNEOLrc2yOdVBhABGlkJu6PGLlhtBq1Xe/7mvKlU0mfEICyGtBsZ u2ufEiddHOERHdd42B/YKpz2+Adxe5DFFISljqkrFUnijeh1sauXJQv+k k=; X-IronPort-AV: E=McAfee;i="5600,1067,7731"; a="85183471" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2015 22:04:18 -0800 X-IronPort-AV: E=Sophos;i="5.11,351,1422950400"; d="scan'208,217";a="864700852" Received: from nasanexm01d.na.qualcomm.com ([10.85.0.84]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Mar 2015 22:04:18 -0800 Received: from NASANEXM01H.na.qualcomm.com (10.85.0.34) by NASANEXM01D.na.qualcomm.com (10.85.0.84) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 5 Mar 2015 22:04:17 -0800 Received: from NASANEXM01H.na.qualcomm.com ([10.85.0.34]) by NASANEXM01H.na.qualcomm.com ([10.85.0.34]) with mapi id 15.00.0995.032; Thu, 5 Mar 2015 22:04:17 -0800 From: "Wang, Ye-Kui" To: "Mo Zanaty (mzanaty)" Thread-Topic: DON in H.265 RTP draft Thread-Index: AQHQV7rY/VilcNCsCUOrqBDdMos+9J0O8Vxg Date: Fri, 6 Mar 2015 06:04:17 +0000 Message-ID: <022732c119ee429294f122a2eb25db9f@NASANEXM01H.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_022732c119ee429294f122a2eb25db9fNASANEXM01Hnaqualcommco_" MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] DON in H.265 RTP draft 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, 06 Mar 2015 06:04:22 -0000 --_000_022732c119ee429294f122a2eb25db9fNASANEXM01Hnaqualcommco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mo, See my comments inline below. BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Mo Zanaty (mza= naty) Sent: Thursday, March 05, 2015 7:09 PM To: draft-ietf-payload-rtp-h265@tools.ietf.org Cc: payload@ietf.org Subject: [payload] DON in H.265 RTP draft Hi, Based on implementation experience with DON in draft-ietf-payload-rtp-h265-= 07, here are some suggested changes in the draft to simplify implementation= s and improve robustness. DON (Decoding Order Number) DON is only necessary when using interleaved transmission (for error resili= ence) or reordered frames (for coding efficiency), if willing to incur the = additional latency and complexity of these techniques. These techniques are= not used in many (probably most) systems, so DON should not be required in= those cases. [YK] No, DON is needed when either interleaved transmission or multi-stream= transmission (MRST/MRMT), otherwise DON is not needed. Reordered pictures = for improve coding efficiency is not a reason for DON. However, the current draft requires DON when tx-mode is MRST or MRMT (or sp= rop-max-don-diff>0). This causes unnecessary complexity, RTP packet overhea= d, and potential for RTP packet parsing failure due to conditional DON fiel= ds whose presence depends on subtle SDP rules. If implementations interpret= these subtle SDP rules differently or improperly, RTP packet parsing compl= etely fails, which is undesirably fragile. [YK] Could you please clarify what is the unnecessary complexity and RTP pa= cket overhead? Also, when tx-mode is present, the value is clear, and when = not present, the default value is specified. This rule is simple and clear.= Could you please provide an example use case where a problem can occur? The suggested change is to revert to the original design in the individual = 00 draft (and RFC 6190), which uses separate explicit payload structures fo= r RTP packets without DON (FU-A, STAP-A) and with DON (FU-B, STAP-B). Recei= vers must still support DON, but senders only use it when necessary, i.e. i= nterleaved transmission or reordered frames. This has several benefits. a. RTP packet parsing is more robust since RTP packets are self-describing = with no dependency on subtle SDP rules. b. RTP packet overhead is reduced in cases where DON is unnecessary, includ= ing many/most MRST and MRMT cases. c. Aligns better with H.264 so those implementations can more easily add H.= 265. The only drawback is this requires 2 extra NAL unit types (51, 52), but tha= t is acceptable since the space is doubled in H.265 (64 vs. 32 in H.264). [YK] If you do that, then you would also need to specify different packetiz= ation modes, and which payload structures are allowed in which packetizatio= n mode, and you would also need to specify different modes of de-packetizat= ion. Basically, the complexity would be similarly to the sum of RFC 6184 an= d RFC 6190. That makes it significantly more complicated than what we have = now. Note that we intentionally avoided all these to simply the design and = this was welcomed by the group. If there is agreement on this suggested change, I will propose specific tex= t changes. Although conceptually simple, it does impact a non-trivial amoun= t of text, mostly repeated. [YK] I thus certainly disagree to go back. Note that in the individual 00 d= raft a lot of details were not included yet. Feel free to try to do the tex= t changes, and if you make it working and complete you would agree that thi= ngs would become much more complicated than what we have now. Regards, Mo --_000_022732c119ee429294f122a2eb25db9fNASANEXM01Hnaqualcommco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mo,

 

See my comments inline below.

 

BR, YK

 

From: payload [mailto:payload-bounce= s@ietf.org] On Behalf Of Mo Zanaty (mzanaty)
Sent: Thursday, March 05, 2015 7:09 PM
To: draft-ietf-payload-rtp-h265@tools.ietf.org
Cc: payload@ietf.org
Subject: [payload] DON in H.265 RTP draft

 

Hi,

Based on implementation experience with DO= N in draft-ietf-payload-rtp-h265-07, here are some suggested changes in the= draft to simplify implementations and improve robustness.

 

DON (Decoding Order Number)

 

DON is only necessary when using interleav= ed transmission (for error resilience) or reordered frames (for coding effi= ciency), if willing to incur the additional latency and complexity of these techniques. These techniques are not used in many = (probably most) systems, so DON should not be required in those cases. = ;

 

[YK] No, DON is needed when either in= terleaved transmission or multi-stream transmission (MRST/MRMT), otherwise = DON is not needed. Reordered pictures for improve coding efficiency is not a reason for DON.

 

However, the current draft requires DON wh= en tx-mode is MRST or MRMT (or sprop-max-don-diff>0). This causes unnece= ssary complexity, RTP packet overhead, and potential for RTP packet parsing failure due to conditional DON fields whose presenc= e depends on subtle SDP rules. If implementations interpret these subtle SD= P rules differently or improperly, RTP packet parsing completely fails, whi= ch is undesirably fragile.

 

[YK] Could you please clarify what is= the unnecessary complexity and RTP packet overhead? Also, when tx-mode is = present, the value is clear, and when not present, the default value is specified. This rule is simple and clear. Could you p= lease provide an example use case where a problem can occur?

 

The suggested change is to revert to the o= riginal design in the individual 00 draft (and RFC 6190), which uses separa= te explicit payload structures for RTP packets without DON (FU-A, STAP-A) and with DON (FU-B, STAP-B). Receivers must sti= ll support DON, but senders only use it when necessary, i.e. interleaved tr= ansmission or reordered frames. This has several benefits.

 

a. RTP packet parsing is more robust since= RTP packets are self-describing with no dependency on subtle SDP rules.

b. RTP packet overhead is reduced in cases= where DON is unnecessary, including many/most MRST and MRMT cases.

c. Aligns better with H.264 so those imple= mentations can more easily add H.265.

 

The only drawback is this requires 2 extra= NAL unit types (51, 52), but that is acceptable since the space is doubled= in H.265 (64 vs. 32 in H.264).

 

[YK] If you do that, then you would a= lso need to specify different packetization modes, and which payload struct= ures are allowed in which packetization mode, and you would also need to specify different modes of de-packetization. Ba= sically, the complexity would be similarly to the sum of RFC 6184 and RFC 6= 190. That makes it significantly more complicated than what we have now. No= te that we intentionally avoided all these to simply the design and this was welcomed by the group. =

 

If there is agreement on this suggested ch= ange, I will propose specific text changes. Although conceptually simple, i= t does impact a non-trivial amount of text, mostly repeated.

 

[YK] I thus certainly disagree to go = back. Note that in the individual 00 draft a lot of details were not includ= ed yet. Feel free to try to do the text changes, and if you make it working and complete you would agree that things would = become much more complicated than what we have now.

 

Regards,

Mo

 

 

--_000_022732c119ee429294f122a2eb25db9fNASANEXM01Hnaqualcommco_-- From nobody Fri Mar 6 03:51:39 2015 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 B4C9F1ACD9D for ; Fri, 6 Mar 2015 03:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, T_RP_MATCHES_RCVD=-0.01] 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 tfej_Zequgd5 for ; Fri, 6 Mar 2015 03:51:35 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id F24A71ACD9A for ; Fri, 6 Mar 2015 03:51:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0480F7C43AC for ; Fri, 6 Mar 2015 12:51:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNZXbuR34PVu for ; Fri, 6 Mar 2015 12:51:31 +0100 (CET) Received: from [10.100.7.176] (160.Red-88-0-254.dynamicIP.rima-tde.net [88.0.254.160]) by mork.alvestrand.no (Postfix) with ESMTPSA id 482A87C4345 for ; Fri, 6 Mar 2015 12:51:30 +0100 (CET) Message-ID: <54F994BA.1050402@alvestrand.no> Date: Fri, 06 Mar 2015 11:51:22 +0000 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: payload@ietf.org References: <20150303205231.10208.20421.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010402050701020407000404" Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-14.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: Fri, 06 Mar 2015 11:51:37 -0000 This is a multi-part message in MIME format. --------------010402050701020407000404 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/05/2015 08:25 PM, Mo Zanaty (mzanaty) wrote: > Hi, > > The simulcast draft (draft-ietf-mmusic-sdp-simulcast) uses payload > formats to express different simulcast encodings. This assumes the > underlying payload format can express the desired encodings in its > a=fmtp parameters. VP8 can express max-fs (roughly resolution) and > max-fr (frame rate), which covers most simulcast use cases. However, > you may want to consider adding max-br (bit rate) if you want to > express simulcasting VP8 at different bit rates (for the same or > different resolutions and frame rates). Thanks for the alert to mmusic-simulcast! I've protested vehemently about the (ab)use of (codec-specific) a=fmtp parameters to express (codec-independent) quality distinctions in the past. I'll go protest again. Harald > > Regards, > Mo > > > On 3/3/15, 3:52 PM, internet-drafts@ietf.org > > wrote: > > > 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 VP8 Video > Authors : Patrik Westin > Henrik F Lundin > Michael Glover > Justin Uberti > Frank Galligan > Filename : draft-ietf-payload-vp8-14.txt > Pages : 25 > Date : 2015-03-03 > > Abstract: > This memo describes an RTP payload format for the VP8 video codec. > The payload format has wide applicability, as it supports > applications from low bit-rate peer-to-peer usage, to high bit-rate > video conferences. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-payload-vp8-14 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-14 > > > 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/ > > _______________________________________________ > 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 -- Surveillance is pervasive. Go Dark. --------------010402050701020407000404 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 03/05/2015 08:25 PM, Mo Zanaty (mzanaty) wrote:
Hi,

The simulcast draft (draft-ietf-mmusic-sdp-simulcast) uses payload formats to express different simulcast encodings. This assumes the underlying payload format can express the desired encodings in its a=fmtp parameters. VP8 can express max-fs (roughly resolution) and max-fr (frame rate), which covers most simulcast use cases. However, you may want to consider adding max-br (bit rate) if you want to express simulcasting VP8 at different bit rates (for the same or different resolutions and frame rates).

Thanks for the alert to mmusic-simulcast!

I've protested vehemently about the (ab)use of (codec-specific) a=fmtp parameters to express (codec-independent) quality distinctions in the past. I'll go protest again.

Harald


Regards,
Mo
 



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 VP8 Video
        Authors         : Patrik Westin
                          Henrik F Lundin
                          Michael Glover
                          Justin Uberti
                          Frank Galligan
Filename        : draft-ietf-payload-vp8-14.txt
Pages           : 25
Date            : 2015-03-03

Abstract:
   This memo describes an RTP payload format for the VP8 video codec.
   The payload format has wide applicability, as it supports
   applications from low bit-rate peer-to-peer usage, to high bit-rate
   video conferences.


The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:


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:

_______________________________________________
payload mailing list



_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload



-- 
Surveillance is pervasive. Go Dark.
--------------010402050701020407000404-- From nobody Mon Mar 9 14:38:44 2015 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 F2BBF1ABD3D for ; Mon, 9 Mar 2015 14:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.119 X-Spam-Level: * X-Spam-Status: No, score=1.119 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_OUTLOOK_TAGS=0.052, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 gFmGEVEdJPER for ; Mon, 9 Mar 2015 14:38:42 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DF71AC41E for ; Mon, 9 Mar 2015 14:38:41 -0700 (PDT) Received: by wghk14 with SMTP id k14so24630895wgh.3 for ; Mon, 09 Mar 2015 14:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=1inVmcaDv7b1JZ4AyA+XCTeaJxOSE6z9rvp/ir/tJPs=; b=aDT2USOcJS+4CoC650Sxa2A5a0+XhJYraydLXC9/AwvGJ3k+VVaa2S4rRs/BkpI5I1 oi3exlApTCjNkTWd4qDsP8f76TI0r9Holu8qupgG65OCtU7BzdOWaFHj7C+gpyWNfhou FebXbjo/XhUfidfBjxHQBaMoGnlI4I88rGPKe3oa4LwqoEVEKAsVDLs+nsV9jwNQD6pV CHn3n9KzRL7ew0IbUO3O6bEoMcY5Hknj6zuvrnc9PEP3iGsNGL3NhlwaH1GWRLAIUQpG NYUGfa9I1jYIWHKOPLeNlQrO3Cz3n4IP6aSEOCgn9EU0yZ6KWeAR+xGFkzxBp4W1Iyrl NWiw== X-Received: by 10.194.63.16 with SMTP id c16mr62934629wjs.117.1425937120509; Mon, 09 Mar 2015 14:38:40 -0700 (PDT) Received: from RoniE (bzq-109-66-126-128.red.bezeqint.net. [109.66.126.128]) by mx.google.com with ESMTPSA id a13sm29964590wjx.30.2015.03.09.14.38.38 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Mar 2015 14:38:39 -0700 (PDT) From: "Roni Even" To: Date: Mon, 9 Mar 2015 23:38:36 +0200 Message-ID: <089501d05ab1$67de0860$379a1920$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0896_01D05AC2.2B672680" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBasWTM3g0i51BYSgSNk/lmK8qqwQ== Content-Language: en-us Archived-At: Subject: [payload] Agenda for Payload session in Dallas 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, 09 Mar 2015 21:38:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0896_01D05AC2.2B672680 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0897_01D05AC2.2B672680" ------=_NextPart_001_0897_01D05AC2.2B672680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Here is the initial agenda. Comments Roni Even ------=_NextPart_001_0897_01D05AC2.2B672680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Here is the = initial agenda.

Comments

Roni = Even

 

------=_NextPart_001_0897_01D05AC2.2B672680-- ------=_NextPart_000_0896_01D05AC2.2B672680 Content-Type: text/plain; name="p1503.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="p1503.txt" Audio/Video Transport Payoads (Payload) Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CHAIRS: Ali Begen Roni Even AGENDA Tuesday, 25 March 2015 at 15:20-16:20 (Continental) --------------------------------------------------- 15:20 Payload Status Update (Chairs, 10) 15:30 RTP Payload for SMPTE ST 291 Ancillary Data (Thomas Edwards, 10) draft-edwards-payload-rtp-ancillary-01 15:40 RTP Payload Format for Non-Interleaved and Interleaved Parity = FEC(Ali Begen, 15) draft-singh-payload-rtp-1d2d-parity-scheme-00 15:55 End ------=_NextPart_000_0896_01D05AC2.2B672680 Content-Type: text/html; name="p1503.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="p1503.html" Audio/Video Transport Payoads (Payload) Working Group = Agenda

Audio/Video Transport Payoads (Payload) = Working Group Agenda

Chairs: Ali Begen , Roni Even =

Tuesday, 25 March 2015 at 15:20-16:20 (Continental)

15:20 Payload Status UpdateChairs
15:30 RTP Payload for SMPTE ST 291 Ancillary DataThomas Edwards
= draft-edwards-payload-rtp-ancillary-01
15:40 RTP Payload Format for Non-Interleaved and = Interleaved Parity FECAli Begen
draft-singh-payload-rtp-1d2d-parity-scheme-00
15:55 End
------=_NextPart_000_0896_01D05AC2.2B672680-- From nobody Mon Mar 9 15:22:11 2015 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 821301ACD9F for ; Mon, 9 Mar 2015 15:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 7sI6-WCoXUb3 for ; Mon, 9 Mar 2015 15:22:02 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE3D1A016B for ; Mon, 9 Mar 2015 15:21:57 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t29MKJlE003389 for ; Mon, 9 Mar 2015 18:21:57 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1syu3xhajf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 09 Mar 2015 18:21:56 -0400 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; Mon, 9 Mar 2015 17:21:55 -0500 From: Jonathan Lennox To: "payload@ietf.org" Thread-Topic: I-D Action: draft-uberti-payload-vp9-01.txt Thread-Index: AQHQWrbEKD8Is6196kGH3TkGJwufKJ0VDUqA Date: Mon, 9 Mar 2015 22:21:55 +0000 Message-ID: <0BFA66B7-E5E9-441B-B71B-CA998AFA7023@vidyo.com> References: <20150309221603.15161.22874.idtracker@ietfa.amsl.com> In-Reply-To: <20150309221603.15161.22874.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.116.135.94] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E143A324ADE844A943AA7F1D5A42954@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=2015-03-09_05:2015-03-09,2015-03-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-1503090225 Archived-At: Subject: Re: [payload] I-D Action: draft-uberti-payload-vp9-01.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, 09 Mar 2015 22:22:04 -0000 FYI. This version of the document restructures the VP9 payload headers a f= air bit, improving the scalability mechanisms (and their reliability). Com= ments are welcome. On Mar 9, 2015, at 6:16 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : RTP Payload Format for VP9 Video > Authors : Justin Uberti > Stefan Holmer > Magnus Flodman > Jonathan Lennox > Danny Hong > Filename : draft-uberti-payload-vp9-01.txt > Pages : 20 > Date : 2015-03-09 >=20 > Abstract: > This memo describes an RTP payload format for the VP9 video codec. > The payload format has wide applicability, as it supports > applications from low bit-rate peer-to-peer usage, to high bit-rate > video conferences. It includes provisions for temporal and spatial > scalability. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-uberti-payload-vp9/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-uberti-payload-vp9-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-uberti-payload-vp9-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From nobody Tue Mar 10 00:13:47 2015 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 AD3521B2A01 for ; Tue, 10 Mar 2015 00:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.51 X-Spam-Level: X-Spam-Status: No, score=-13.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=1, HTML_MESSAGE=0.001, 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 x8aQ5bKkPgpm for ; Tue, 10 Mar 2015 00:13:42 -0700 (PDT) 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 96DB21B2A03 for ; Tue, 10 Mar 2015 00:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21078; q=dns/txt; s=iport; t=1425971622; x=1427181222; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LaKZny2IfjQlIZnO+vYjiK8yvrdgQEvqPJQ+viBfyZA=; b=GYPVHrA5/REpOIGoEtt+KsHacyYF85GwEGZUSz51W67ONX+HYZsilhkb Bf7zpOsUF0RPbp0/xke5KlXAysRuv8Bkg00HXs/TVG0n3evGtAU3ghJdW a35Q+qjflB2dtjkBFwwfZkn4sPf1KFVuwqt2s6xy/0LF0MAVyI+EQWGmF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQCymP5U/4QNJK1cgkNDUloEyGQCgTBNAQEBAQEBfIQPAQEBBC1MEAIBCBEEAQEoBzIUCQgCBA4FiC/CUwEBAQEBAQEBAQEBAQEBAQEBAQEBAReKGH+EC2MGAYQtBY4NggKFfoNVgRqDKI8yI4ICHIFQb4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,373,1422921600"; d="scan'208,217";a="130483182" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 10 Mar 2015 07:13:41 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t2A7DfYO016751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 07:13:41 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.142]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 02:13:41 -0500 From: "Mo Zanaty (mzanaty)" To: "Wang, Ye-Kui" Thread-Topic: DON in H.265 RTP draft Thread-Index: AQHQWwG8WftsR3eOk0aPxRR8CNj8fg== Date: Tue, 10 Mar 2015 07:13:40 +0000 Message-ID: References: <022732c119ee429294f122a2eb25db9f@NASANEXM01H.na.qualcomm.com> In-Reply-To: <022732c119ee429294f122a2eb25db9f@NASANEXM01H.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [64.100.32.216] Content-Type: multipart/alternative; boundary="_000_D123F56A47F4Emzanatyciscocom_" MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] DON in H.265 RTP draft 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, 10 Mar 2015 07:13:45 -0000 --_000_D123F56A47F4Emzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi YK, see Mo: inline. Regards, Mo On 3/6/15, 1:04 AM, Wang, Ye-Kui > wrote: Hi Mo, See my comments inline below. BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Mo Zanaty (mza= naty) Sent: Thursday, March 05, 2015 7:09 PM To: draft-ietf-payload-rtp-h265@tools.ietf.org Cc: payload@ietf.org Subject: [payload] DON in H.265 RTP draft Hi, Based on implementation experience with DON in draft-ietf-payload-rtp-h265-= 07, here are some suggested changes in the draft to simplify implementation= s and improve robustness. DON (Decoding Order Number) DON is only necessary when using interleaved transmission (for error resili= ence) or reordered frames (for coding efficiency), if willing to incur the = additional latency and complexity of these techniques. These techniques are= not used in many (probably most) systems, so DON should not be required in= those cases. [YK] No, DON is needed when either interleaved transmission or multi-stream= transmission (MRST/MRMT), otherwise DON is not needed. Reordered pictures = for improve coding efficiency is not a reason for DON. Mo: DON is not needed for MRST/MRMT unless reordered frames are used. See m= st-mode=3DNI-T in H.264 SVC RFC 6190. The same applies to MRST/MRMT in H.26= 5. H.264 did not force the complexity of DON for the very common cases of n= o reordered frames, so H.265 should likewise not force such complexity. However, the current draft requires DON when tx-mode is MRST or MRMT (or sp= rop-max-don-diff>0). This causes unnecessary complexity, RTP packet overhea= d, and potential for RTP packet parsing failure due to conditional DON fiel= ds whose presence depends on subtle SDP rules. If implementations interpret= these subtle SDP rules differently or improperly, RTP packet parsing compl= etely fails, which is undesirably fragile. [YK] Could you please clarify what is the unnecessary complexity and RTP pa= cket overhead? Also, when tx-mode is present, the value is clear, and when = not present, the default value is specified. This rule is simple and clear.= Could you please provide an example use case where a problem can occur? Mo: DON is unnecessary complexity and packet overhead. Existing RTP header = fields already provide decode order without introducing an artificial, redu= ndant DON. It was introduced in H.264 RFC 3984 for the interleaved mode, wh= ich was never widely deployed. It was retained in H.264 SVC RFC 6190 for th= e interleaved mode and MST modes with reordered frames. It should be retain= ed in H.265 for the same (rare) cases, but not forced in unnecessary (and v= ery common) cases. It is also fragile for RTP packet layout to depend on su= btle SDP rules. As stated above, a severe problem can occur if implementati= ons have different views of whether DON should be present or not, due to di= fferent SDP implementations or even transient renegotiation. RTP packet par= sing completely fails because one side thinks payloads start at offset N wh= ile the other thinks N+2 due to DON conditionally present based on SDP rule= s. The suggested change is to revert to the original design in the individual = 00 draft (and RFC 6190), which uses separate explicit payload structures fo= r RTP packets without DON (FU-A, STAP-A) and with DON (FU-B, STAP-B). Recei= vers must still support DON, but senders only use it when necessary, i.e. i= nterleaved transmission or reordered frames. This has several benefits. a. RTP packet parsing is more robust since RTP packets are self-describing = with no dependency on subtle SDP rules. b. RTP packet overhead is reduced in cases where DON is unnecessary, includ= ing many/most MRST and MRMT cases. c. Aligns better with H.264 so those implementations can more easily add H.= 265. The only drawback is this requires 2 extra NAL unit types (51, 52), but tha= t is acceptable since the space is doubled in H.265 (64 vs. 32 in H.264). [YK] If you do that, then you would also need to specify different packetiz= ation modes, and which payload structures are allowed in which packetizatio= n mode, and you would also need to specify different modes of de-packetizat= ion. Basically, the complexity would be similarly to the sum of RFC 6184 an= d RFC 6190. That makes it significantly more complicated than what we have = now. Note that we intentionally avoided all these to simply the design and = this was welcomed by the group. Mo: I very much welcomed the simpler design of no different packetization m= odes negotiated in SDP. Thanks for that. I do not suggest we change that. I= suggest what I stated above. =93Receivers must still support DON, but send= ers only use it when necessary.=94 If there is agreement on this suggested change, I will propose specific tex= t changes. Although conceptually simple, it does impact a non-trivial amoun= t of text, mostly repeated. [YK] I thus certainly disagree to go back. Note that in the individual 00 d= raft a lot of details were not included yet. Feel free to try to do the tex= t changes, and if you make it working and complete you would agree that thi= ngs would become much more complicated than what we have now. Mo: Ok, I will do the text changes and report back. Regards, Mo --_000_D123F56A47F4Emzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <35735E87E6129B46A24E86FC3FBA2419@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi YK, see Mo: inline.
Regards,
Mo

On 3/6/15, 1:04 AM, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> wrote:

Hi Mo,

 

See my comments inline below.<= /o:p>

 

BR, YK

 

From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty)
Sent: Thursday, March 05, 2015 7:09 PM
To: dr= aft-ietf-payload-rtp-h265@tools.ietf.org
Cc: payload@ietf.org
Subject: [payload] DON in H.265 RTP draft

 

Hi,

Based on implementation experience with DON in dr= aft-ietf-payload-rtp-h265-07, here are some suggested changes in the draft = to simplify implementations and improve robustness.

 

DON (Decoding Order Number)

 

DON is only necessary when using interleaved tran= smission (for error resilience) or reordered frames (for coding efficiency)= , if willing to incur the additional latency and complexity of these techniques. These techniques are not used = in many (probably most) systems, so DON should not be required in those cas= es. 

 

[YK] No, DON is needed when either = interleaved transmission or multi-stream transmission (MRST/MRMT), otherwis= e DON is not needed. Reordered pictures for improve coding efficiency is not a reason for DON.<= /p>


Mo: DON is not needed for MRST/MRMT unless reordered frames are used. = See mst-mode=3DNI-T in H.264 SVC RFC 6190. The same applies to MRST/MRMT in= H.265. H.264 did not force the complexity of DON for the very common cases= of no reordered frames, so H.265 should likewise not force such complexity.
 

However, the current draft requires DON when tx-m= ode is MRST or MRMT (or sprop-max-don-diff>0). This causes unnecessary c= omplexity, RTP packet overhead, and potential for RTP packet parsing failure due to conditional DON fields whose presenc= e depends on subtle SDP rules. If implementations interpret these subtle SD= P rules differently or improperly, RTP packet parsing completely fails, whi= ch is undesirably fragile.

 

[YK] Could you please clarify what = is the unnecessary complexity and RTP packet overhead? Also, when tx-mode i= s present, the value is clear, and when not present, the default value is specified. This rule is simple and clear= . Could you please provide an example use case where a problem can occur?

Mo: DON is unnecessary complexity and packet overhead. Existing RTP he= ader fields already provide decode order without introducing an artificial,= redundant DON. It was introduced in H.264 RFC 3984 for the interleaved mod= e, which was never widely deployed. It was retained in H.264 SVC RFC 6190 for the interleaved mode and MST mod= es with reordered frames. It should be retained in H.265 for the same (rare= ) cases, but not forced in unnecessary (and very common) cases. It is also = fragile for RTP packet layout to depend on subtle SDP rules. As stated above, a severe problem can occur if= implementations have different views of whether DON should be present or n= ot, due to different SDP implementations or even transient renegotiation. R= TP packet parsing completely fails because one side thinks payloads start at offset N while the other thinks = N+2 due to DON conditionally present based on SDP rules.


The suggested change is to revert to the original= design in the individual 00 draft (and RFC 6190), which uses separate expl= icit payload structures for RTP packets without DON (FU-A, STAP-A) and with DON (FU-B, STAP-B). Receivers must sti= ll support DON, but senders only use it when necessary, i.e. interleaved tr= ansmission or reordered frames. This has several benefits.

 

a. RTP packet parsing is more robust since RTP pa= ckets are self-describing with no dependency on subtle SDP rules.

b. RTP packet overhead is reduced in cases where = DON is unnecessary, including many/most MRST and MRMT cases.

c. Aligns better with H.264 so those implementati= ons can more easily add H.265.

 

The only drawback is this requires 2 extra NAL un= it types (51, 52), but that is acceptable since the space is doubled in H.2= 65 (64 vs. 32 in H.264).

 

[YK] If you do that, then you would= also need to specify different packetization modes, and which payload stru= ctures are allowed in which packetization mode, and you would also need to specify different modes of de-packetizati= on. Basically, the complexity would be similarly to the sum of RFC 6184 and= RFC 6190. That makes it significantly more complicated than what we have n= ow. Note that we intentionally avoided all these to simply the design and this was welcomed by the group. =


Mo: I very much welcomed the simpler design of no different packetizat= ion modes negotiated in SDP. Thanks for that. I do not suggest we change th= at. I suggest what I stated above. =93Receivers must still support DON, but= senders only use it when necessary.=94
 

If there is agreement on this suggested change, I= will propose specific text changes. Although conceptually simple, it does = impact a non-trivial amount of text, mostly repeated.

 

[YK] I thus certainly disagree to g= o back. Note that in the individual 00 draft a lot of details were not incl= uded yet. Feel free to try to do the text changes, and if you make it working and complete you would agree that= things would become much more complicated than what we have now. <= o:p>

 
Mo: Ok, I will do the text changes and report back.

Regards,

Mo

 

 

 --_000_D123F56A47F4Emzanatyciscocom_-- From nobody Tue Mar 10 02:15:30 2015 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 59B6E1A8025 for ; Tue, 10 Mar 2015 02:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 7VVjNzBmUDDi for ; Tue, 10 Mar 2015 02:15:25 -0700 (PDT) Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by ietfa.amsl.com (Postfix) with ESMTP id 02C2E1A7023 for ; Tue, 10 Mar 2015 02:15:24 -0700 (PDT) X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0 Received: from maclaptop002.ic.tu-berlin.de (maclaptop002.ic.tu-berlin.de [130.149.228.68]) by mailgw.hhi.fraunhofer.de (Postfix) with ESMTP id 89C221868026; Tue, 10 Mar 2015 10:15:22 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_FAA25248-67E2-471D-B111-3D817F827A52" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yago Sanchez In-Reply-To: Date: Tue, 10 Mar 2015 10:15:22 +0100 Message-Id: <4F832FEC-8E5B-4CEA-9226-2196B7577105@hhi.fraunhofer.de> References: <022732c119ee429294f122a2eb25db9f@NASANEXM01H.na.qualcomm.com> To: "Mo Zanaty (mzanaty)" X-Mailer: Apple Mail (2.1878.6) X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-7.5.0.1018-21388.005 X-TM-AS-Result: No--26.199-11.0-31-10 X-imss-scan-details: No--26.199-11.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-MatchedRID: 8HTFlOrbAtFNlZ1zEcyAY8OvQCMFyZ9GM/Xrz6lKsoK5fo1ci85gu2zk k6oK3QRZ0Q2PKuAVSm5NFasL5HC7Woe/o1zWuGFvo4427PDKC0bomPrNi98UBFyPhb2isyDdwB8 gzNQ+eE6q6tEztROAzpt8iFB3MT28WXg0GghHbMV1fPeXvwXdiSuLad+EL08L7a71bENFnTPBZD Kfh0ReHFw18DZCicJZlxMyXwVrpHHxlOJuQNHlfce31VQ+6yRGTSwzXz9D+2VrRM6wvXgDaQi9c mFBBPB+1Fc61VCGvh1E0i0oADaqdSGaZK3jr5wElVHM/F6YkvRd7K6NvtpeBI/F+sB2dG/UG2Mk geeC0TE/8uFnLFtcs3LFiWVZ7Y0SqjvsBy5CHDsm6fyHG/axoYlHblw+bcjbe/eKgB30qtLxjoV +pkxvcnw10tPQMExMohiMqDdk/5Cyf+8sXPWRX2lHv4vQHqYTNNuh+5zmS6+HwGEm+CpYGTZrX/ 5uUOKSfXKBhOx5I6ltkLdMmnpDYinixsypv8PSsaPcs3T4TL3WCMDdlOQB59qqof+gfD6RxFSiA fKtJUOWbx6HPi0ddeyuNAyFOU0OnXtKf+ShGJjH40/wT2pAd8tcv4yLqGWeRfmFzyKgHb6W1/3T tIf0zqp3muhLqOMEudZcHG6m0rLvkJu04PYxt+w8wbnnSw8bttKJDdalq/XEh+IOisxbgcYc1Hx cXCBPW3Y9suZif5uWJcbpNaIEAPs6AFvEdeZfHPCema1j/6t8yGO3dvk8/QJ1vk7thYuGUdfEKc 10rU4vcgUibwrcmlebGpjHs5mWo27w8ee4WC+eAiCmPx4NwGmRqNBHmBveeVl+oyOKCVeh5DOWG PdqWSIQ5mZ5SqHPTAr2kT6w3Q3rd275136uNY7EQaRrhyfuNOtHKLH3V8nC82cf8q2reg== X-IMSS-DKIM-White-List: No Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] DON in H.265 RTP draft 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, 10 Mar 2015 09:15:29 -0000 --Apple-Mail=_FAA25248-67E2-471D-B111-3D817F827A52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Mo,=20 The reason for forcing to use DON for MRST and MRMT is actually to = reduce the implementation complexity. We could have followed the design = in RFC 6190 by having four transmission modes NI-T, NI-TC, NI-C and I-C = but it was agreed from the beginning that such a thing should be = avoided.=20 You are right when you say that the same principle of NI-T could be used = without requiring the presence of the DON field, but this would lead for = sure to the same result we had in RFC 6190, four modes. NI-TC was found = very useful back then to solve issues of time stamp based (NI-T) = decoding order recovery under loss events. Note additionally that the NI-T case requires the dependent RTP = (enhancement layes) streams to contain data for all sampling instances = that exist in their dependee RTP streams (base layer or lower layers), = e.g. by using the empty NAL units described in RFC 6190, which also = incur some overhead. Only if the decoding order is equal to the = presentation order (that is what I interpret from your comment about = frame reordering) this requirement would not be necessary. This is = something we would need to signal additionally, adding dependency on = subtle SDP rules similar to the ones you mention. In any case, I think that your proposal now introduces more problems = than benefits. The design we chose at the beginning was concretely to = avoid all this potential problems that would require specific solutions = making the design much more complicated only to save a couple of bytes = required to add the DON field. Therefore, I am here with Ye-Kui and = would prefer to keep the design as it is now. Best regards, Yago On 10 Mar 2015, at 08:13, Mo Zanaty (mzanaty) wrote: > Hi YK, see Mo: inline. > Regards, > Mo >=20 > On 3/6/15, 1:04 AM, Wang, Ye-Kui wrote: >=20 > Hi Mo, > =20 > See my comments inline below. > =20 > BR, YK > =20 > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Mo Zanaty = (mzanaty) > Sent: Thursday, March 05, 2015 7:09 PM > To: draft-ietf-payload-rtp-h265@tools.ietf.org > Cc: payload@ietf.org > Subject: [payload] DON in H.265 RTP draft > =20 > Hi, > Based on implementation experience with DON in = draft-ietf-payload-rtp-h265-07, here are some suggested changes in the = draft to simplify implementations and improve robustness. > =20 > DON (Decoding Order Number) > =20 > DON is only necessary when using interleaved transmission (for error = resilience) or reordered frames (for coding efficiency), if willing to = incur the additional latency and complexity of these techniques. These = techniques are not used in many (probably most) systems, so DON should = not be required in those cases.=20 > =20 > [YK] No, DON is needed when either interleaved transmission or = multi-stream transmission (MRST/MRMT), otherwise DON is not needed. = Reordered pictures for improve coding efficiency is not a reason for = DON. >=20 > Mo: DON is not needed for MRST/MRMT unless reordered frames are used. = See mst-mode=3DNI-T in H.264 SVC RFC 6190. The same applies to MRST/MRMT = in H.265. H.264 did not force the complexity of DON for the very common = cases of no reordered frames, so H.265 should likewise not force such = complexity. > =20 > However, the current draft requires DON when tx-mode is MRST or MRMT = (or sprop-max-don-diff>0). This causes unnecessary complexity, RTP = packet overhead, and potential for RTP packet parsing failure due to = conditional DON fields whose presence depends on subtle SDP rules. If = implementations interpret these subtle SDP rules differently or = improperly, RTP packet parsing completely fails, which is undesirably = fragile. > =20 > [YK] Could you please clarify what is the unnecessary complexity and = RTP packet overhead? Also, when tx-mode is present, the value is clear, = and when not present, the default value is specified. This rule is = simple and clear. Could you please provide an example use case where a = problem can occur? >=20 > Mo: DON is unnecessary complexity and packet overhead. Existing RTP = header fields already provide decode order without introducing an = artificial, redundant DON. It was introduced in H.264 RFC 3984 for the = interleaved mode, which was never widely deployed. It was retained in = H.264 SVC RFC 6190 for the interleaved mode and MST modes with reordered = frames. It should be retained in H.265 for the same (rare) cases, but = not forced in unnecessary (and very common) cases. It is also fragile = for RTP packet layout to depend on subtle SDP rules. As stated above, a = severe problem can occur if implementations have different views of = whether DON should be present or not, due to different SDP = implementations or even transient renegotiation. RTP packet parsing = completely fails because one side thinks payloads start at offset N = while the other thinks N+2 due to DON conditionally present based on SDP = rules. >=20 > The suggested change is to revert to the original design in the = individual 00 draft (and RFC 6190), which uses separate explicit payload = structures for RTP packets without DON (FU-A, STAP-A) and with DON = (FU-B, STAP-B). Receivers must still support DON, but senders only use = it when necessary, i.e. interleaved transmission or reordered frames. = This has several benefits. > =20 > a. RTP packet parsing is more robust since RTP packets are = self-describing with no dependency on subtle SDP rules. > b. RTP packet overhead is reduced in cases where DON is unnecessary, = including many/most MRST and MRMT cases. > c. Aligns better with H.264 so those implementations can more easily = add H.265. > =20 > The only drawback is this requires 2 extra NAL unit types (51, 52), = but that is acceptable since the space is doubled in H.265 (64 vs. 32 in = H.264). > =20 > [YK] If you do that, then you would also need to specify different = packetization modes, and which payload structures are allowed in which = packetization mode, and you would also need to specify different modes = of de-packetization. Basically, the complexity would be similarly to the = sum of RFC 6184 and RFC 6190. That makes it significantly more = complicated than what we have now. Note that we intentionally avoided = all these to simply the design and this was welcomed by the group. >=20 > Mo: I very much welcomed the simpler design of no different = packetization modes negotiated in SDP. Thanks for that. I do not suggest = we change that. I suggest what I stated above. =93Receivers must still = support DON, but senders only use it when necessary.=94 > =20 > If there is agreement on this suggested change, I will propose = specific text changes. Although conceptually simple, it does impact a = non-trivial amount of text, mostly repeated. > =20 > [YK] I thus certainly disagree to go back. Note that in the individual = 00 draft a lot of details were not included yet. Feel free to try to do = the text changes, and if you make it working and complete you would = agree that things would become much more complicated than what we have = now. > =20 > Mo: Ok, I will do the text changes and report back. >=20 > Regards, > Mo > =20 > =20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --Apple-Mail=_FAA25248-67E2-471D-B111-3D817F827A52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Mo, 

The reason for forcing to use DON for MRST = and MRMT is actually to reduce the implementation complexity. We could = have followed the design in RFC 6190 by having four transmission modes = NI-T, NI-TC, NI-C and I-C but it was agreed from the beginning that such = a thing should be avoided. 

You are right = when you say that the same principle of NI-T could be used without = requiring the presence of the DON field, but this would lead for sure to = the same result we had in RFC 6190, four modes. NI-TC was found very = useful back then to solve issues of time stamp based (NI-T) decoding = order recovery under loss events.

Note = additionally that the NI-T case requires the dependent RTP (enhancement = layes) streams to contain data for all sampling instances that exist in = their dependee RTP streams (base layer or lower layers), e.g. by using = the empty NAL units described in RFC 6190, which also incur some = overhead. Only if the decoding order is equal to the presentation order = (that is what I interpret from your comment about frame reordering) this = requirement would not be necessary. This is something we would need to = signal additionally, adding dependency on subtle SDP rules similar to = the ones you mention.

In any case, I think that = your proposal now introduces more problems than benefits. The design we = chose at the beginning was concretely to avoid all this potential = problems that would require specific solutions making the design much = more complicated only to save a couple of bytes required to add the DON = field. Therefore, I am here with Ye-Kui and would prefer to keep the = design as it is now.

Best = regards,
Yago


On = 10 Mar 2015, at 08:13, Mo Zanaty (mzanaty) <mzanaty@cisco.com> = wrote:

Hi YK, see Mo: = inline.
Regards,
Mo

On 3/6/15, 1:04 AM, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> = wrote:

Hi Mo,
 
See my comments inline = below.
 
BR, YK
 
From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Mo Zanaty = (mzanaty)
Sent: Thursday, March 05, 2015 = 7:09 PM
To: draft-ietf-payload-rtp-h265@tools.ietf.org
Cc: payload@ietf.org
Subject: [payload] DON in H.265 RTP = draft
 
Hi,
Based on implementation experience with DON in = draft-ietf-payload-rtp-h265-07, here are some suggested changes in the = draft to simplify implementations and improve = robustness.
 
DON (Decoding Order = Number)
 
DON is only necessary when using interleaved transmission = (for error resilience) or reordered frames (for coding efficiency), if = willing to incur the additional latency and complexity of these = techniques. These techniques are not used in many (probably most) = systems, so DON should not be required in those = cases. 
 
[YK] No, DON is needed when either interleaved = transmission or multi-stream transmission (MRST/MRMT), otherwise DON is = not needed. Reordered pictures for improve coding efficiency is not a = reason for DON.
<= br>
Mo: DON is not needed for MRST/MRMT unless reordered = frames are used. See mst-mode=3DNI-T in H.264 SVC RFC 6190. The same = applies to MRST/MRMT in H.265. H.264 did not force the complexity of DON = for the very common cases of no reordered frames, so H.265 should = likewise not force such complexity.
 
However, the = current draft requires DON when tx-mode is MRST or MRMT (or = sprop-max-don-diff>0). This causes unnecessary complexity, RTP packet = overhead, and potential for RTP packet parsing failure due to = conditional DON fields whose presence depends on subtle SDP rules. If = implementations interpret these subtle SDP rules differently or = improperly, RTP packet parsing completely fails, which is undesirably = fragile.
 
[YK] Could you please clarify what is the unnecessary = complexity and RTP packet overhead? Also, when tx-mode is present, the = value is clear, and when not present, the default value is specified. = This rule is simple and clear. Could you please provide an example use = case where a problem can = occur?

Mo: DON is unnecessary complexity and packet overhead. Existing RTP = header fields already provide decode order without introducing an = artificial, redundant DON. It was introduced in H.264 RFC 3984 for the = interleaved mode, which was never widely deployed. It was retained in = H.264 SVC RFC 6190 for the interleaved mode and MST modes with reordered = frames. It should be retained in H.265 for the same (rare) cases, but = not forced in unnecessary (and very common) cases. It is also fragile = for RTP packet layout to depend on subtle SDP rules. As stated above, a = severe problem can occur if implementations have different views of = whether DON should be present or not, due to different SDP = implementations or even transient renegotiation. RTP packet parsing = completely fails because one side thinks payloads start at offset N = while the other thinks N+2 due to DON conditionally present based on SDP = rules.

The suggested = change is to revert to the original design in the individual 00 draft = (and RFC 6190), which uses separate explicit payload structures for RTP = packets without DON (FU-A, STAP-A) and with DON (FU-B, STAP-B). = Receivers must still support DON, but senders only use it when = necessary, i.e. interleaved transmission or reordered frames. This has = several benefits.
 
a. RTP packet = parsing is more robust since RTP packets are self-describing with no = dependency on subtle SDP rules.
b. RTP packet overhead is reduced in cases where DON is = unnecessary, including many/most MRST and MRMT = cases.
c. Aligns = better with H.264 so those implementations can more easily add = H.265.
 
The only = drawback is this requires 2 extra NAL unit types (51, 52), but that is = acceptable since the space is doubled in H.265 (64 vs. 32 in = H.264).
 
[YK] If you do that, then you would also need to = specify different packetization modes, and which payload structures are = allowed in which packetization mode, and you would also need to specify = different modes of de-packetization. Basically, the complexity would be = similarly to the sum of RFC 6184 and RFC 6190. That makes it = significantly more complicated than what we have now. Note that we = intentionally avoided all these to simply the design and this was = welcomed by the group.
<= br>
Mo: I very much welcomed the simpler design of no = different packetization modes negotiated in SDP. Thanks for that. I do = not suggest we change that. I suggest what I stated above. =93Receivers = must still support DON, but senders only use it when = necessary.=94
 
If there is = agreement on this suggested change, I will propose specific text = changes. Although conceptually simple, it does impact a non-trivial = amount of text, mostly repeated.
 
[YK] I thus certainly disagree to go back. Note that = in the individual 00 draft a lot of details were not included yet. Feel = free to try to do the text changes, and if you make it working and = complete you would agree that things would become much more complicated = than what we have now.
 
Mo: = Ok, I will do the text changes and report = back.

Regards,
Mo
 
 
___________= ____________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload

= --Apple-Mail=_FAA25248-67E2-471D-B111-3D817F827A52-- From nobody Tue Mar 10 10:37:49 2015 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 A2CEF1A6FCB for ; Tue, 10 Mar 2015 10:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.51 X-Spam-Level: X-Spam-Status: No, score=-13.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=1, HTML_MESSAGE=0.001, 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 7NJCtoBgpFue for ; Tue, 10 Mar 2015 10:37:44 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ABC21A0122 for ; Tue, 10 Mar 2015 10:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29643; q=dns/txt; s=iport; t=1426009064; x=1427218664; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tWL3r41DM8TJ3hMYPMfeOhjsqYbMo7b1JM6ldw+eyls=; b=IdsNR4ZNeniBAVIfc2JvoIi85Yjokf57WOVWP0bF+q/LbyCMhQkv+lnQ 0UOC5DrcdBb3pY45OZq54RqtgfesQMbYSb3bsMdNZlzEu9ec4MPcx8Ln4 Pc8vjZCfer9/UfXzvQA18dneMzsR8scSkcfpQwNQUUtBdFMP0TlMfq9mu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARBQCiKv9U/40NJK1cgkNDUloEwx0BCYUnSQKBNE0BAQEBAQF8hA8BAQEEAQEBawsQAgEIEQQBASEHBycLFAkIAgQOBRuIFA3EQQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEihh/hAtfBAYBhC0Fjg2CAoV+g1WBGoMoi3CDQiOBfwMcgVBvAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,375,1422921600"; d="scan'208,217";a="130675793" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 10 Mar 2015 17:37:43 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2AHbgVp018300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 17:37:43 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.142]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 12:37:42 -0500 From: "Mo Zanaty (mzanaty)" To: Yago Sanchez Thread-Topic: [payload] DON in H.265 RTP draft Thread-Index: AQHQW1jpOW1X4iZyAUWWzYxv6w2Sag== Date: Tue, 10 Mar 2015 17:37:42 +0000 Message-ID: References: <022732c119ee429294f122a2eb25db9f@NASANEXM01H.na.qualcomm.com> <4F832FEC-8E5B-4CEA-9226-2196B7577105@hhi.fraunhofer.de> In-Reply-To: <4F832FEC-8E5B-4CEA-9226-2196B7577105@hhi.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.150.30.49] Content-Type: multipart/alternative; boundary="_000_D12477B9480BFmzanatyciscocom_" MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] DON in H.265 RTP draft 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, 10 Mar 2015 17:37:47 -0000 --_000_D12477B9480BFmzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Yago, I fully agree with reducing complexity by eliminating SDP negotiation of di= fferent packetization modes for different transmission modes. I applaud the= authors for those efforts, and strongly support retaining them. My suggest= ion is further complexity reduction, but perhaps I need to provide more det= ails to convey this. I will look into the specific text changes as YK sugge= sted. If the result is simpler, I will share it. If not, I will abandon it,= and share that as well. Regards, Mo On 3/10/15, 5:15 AM, Yago Sanchez > wrote: Hi Mo, The reason for forcing to use DON for MRST and MRMT is actually to reduce t= he implementation complexity. We could have followed the design in RFC 6190= by having four transmission modes NI-T, NI-TC, NI-C and I-C but it was agr= eed from the beginning that such a thing should be avoided. You are right when you say that the same principle of NI-T could be used wi= thout requiring the presence of the DON field, but this would lead for sure= to the same result we had in RFC 6190, four modes. NI-TC was found very us= eful back then to solve issues of time stamp based (NI-T) decoding order re= covery under loss events. Note additionally that the NI-T case requires the dependent RTP (enhancemen= t layes) streams to contain data for all sampling instances that exist in t= heir dependee RTP streams (base layer or lower layers), e.g. by using the e= mpty NAL units described in RFC 6190, which also incur some overhead. Only = if the decoding order is equal to the presentation order (that is what I in= terpret from your comment about frame reordering) this requirement would no= t be necessary. This is something we would need to signal additionally, add= ing dependency on subtle SDP rules similar to the ones you mention. In any case, I think that your proposal now introduces more problems than b= enefits. The design we chose at the beginning was concretely to avoid all t= his potential problems that would require specific solutions making the des= ign much more complicated only to save a couple of bytes required to add th= e DON field. Therefore, I am here with Ye-Kui and would prefer to keep the = design as it is now. Best regards, Yago On 10 Mar 2015, at 08:13, Mo Zanaty (mzanaty) > wrote: Hi YK, see Mo: inline. Regards, Mo On 3/6/15, 1:04 AM, Wang, Ye-Kui > wrote: Hi Mo, See my comments inline below. BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Mo Zanaty (mza= naty) Sent: Thursday, March 05, 2015 7:09 PM To: draft-ietf-payload-rtp-h265@tools.ietf.org Cc: payload@ietf.org Subject: [payload] DON in H.265 RTP draft Hi, Based on implementation experience with DON in draft-ietf-payload-rtp-h265-= 07, here are some suggested changes in the draft to simplify implementation= s and improve robustness. DON (Decoding Order Number) DON is only necessary when using interleaved transmission (for error resili= ence) or reordered frames (for coding efficiency), if willing to incur the = additional latency and complexity of these techniques. These techniques are= not used in many (probably most) systems, so DON should not be required in= those cases. [YK] No, DON is needed when either interleaved transmission or multi-stream= transmission (MRST/MRMT), otherwise DON is not needed. Reordered pictures = for improve coding efficiency is not a reason for DON. Mo: DON is not needed for MRST/MRMT unless reordered frames are used. See m= st-mode=3DNI-T in H.264 SVC RFC 6190. The same applies to MRST/MRMT in H.26= 5. H.264 did not force the complexity of DON for the very common cases of n= o reordered frames, so H.265 should likewise not force such complexity. However, the current draft requires DON when tx-mode is MRST or MRMT (or sp= rop-max-don-diff>0). This causes unnecessary complexity, RTP packet overhea= d, and potential for RTP packet parsing failure due to conditional DON fiel= ds whose presence depends on subtle SDP rules. If implementations interpret= these subtle SDP rules differently or improperly, RTP packet parsing compl= etely fails, which is undesirably fragile. [YK] Could you please clarify what is the unnecessary complexity and RTP pa= cket overhead? Also, when tx-mode is present, the value is clear, and when = not present, the default value is specified. This rule is simple and clear.= Could you please provide an example use case where a problem can occur? Mo: DON is unnecessary complexity and packet overhead. Existing RTP header = fields already provide decode order without introducing an artificial, redu= ndant DON. It was introduced in H.264 RFC 3984 for the interleaved mode, wh= ich was never widely deployed. It was retained in H.264 SVC RFC 6190 for th= e interleaved mode and MST modes with reordered frames. It should be retain= ed in H.265 for the same (rare) cases, but not forced in unnecessary (and v= ery common) cases. It is also fragile for RTP packet layout to depend on su= btle SDP rules. As stated above, a severe problem can occur if implementati= ons have different views of whether DON should be present or not, due to di= fferent SDP implementations or even transient renegotiation. RTP packet par= sing completely fails because one side thinks payloads start at offset N wh= ile the other thinks N+2 due to DON conditionally present based on SDP rule= s. The suggested change is to revert to the original design in the individual = 00 draft (and RFC 6190), which uses separate explicit payload structures fo= r RTP packets without DON (FU-A, STAP-A) and with DON (FU-B, STAP-B). Recei= vers must still support DON, but senders only use it when necessary, i.e. i= nterleaved transmission or reordered frames. This has several benefits. a. RTP packet parsing is more robust since RTP packets are self-describing = with no dependency on subtle SDP rules. b. RTP packet overhead is reduced in cases where DON is unnecessary, includ= ing many/most MRST and MRMT cases. c. Aligns better with H.264 so those implementations can more easily add H.= 265. The only drawback is this requires 2 extra NAL unit types (51, 52), but tha= t is acceptable since the space is doubled in H.265 (64 vs. 32 in H.264). [YK] If you do that, then you would also need to specify different packetiz= ation modes, and which payload structures are allowed in which packetizatio= n mode, and you would also need to specify different modes of de-packetizat= ion. Basically, the complexity would be similarly to the sum of RFC 6184 an= d RFC 6190. That makes it significantly more complicated than what we have = now. Note that we intentionally avoided all these to simply the design and = this was welcomed by the group. Mo: I very much welcomed the simpler design of no different packetization m= odes negotiated in SDP. Thanks for that. I do not suggest we change that. I= suggest what I stated above. =93Receivers must still support DON, but send= ers only use it when necessary.=94 If there is agreement on this suggested change, I will propose specific tex= t changes. Although conceptually simple, it does impact a non-trivial amoun= t of text, mostly repeated. [YK] I thus certainly disagree to go back. Note that in the individual 00 d= raft a lot of details were not included yet. Feel free to try to do the tex= t changes, and if you make it working and complete you would agree that thi= ngs would become much more complicated than what we have now. Mo: Ok, I will do the text changes and report back. Regards, Mo _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_D12477B9480BFmzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Yago,

I fully agree with reducing complexity by eliminating SDP negotiation = of different packetization modes for different transmission modes. I applau= d the authors for those efforts, and strongly support retaining them. My su= ggestion is further complexity reduction, but perhaps I need to provide more details to convey this. I will look int= o the specific text changes as YK suggested. If the result is simpler, I wi= ll share it. If not, I will abandon it, and share that as well.

Regards,
Mo

On 3/10/15, 5:15 AM, Yago Sanchez <yago.sanchez@hhi.fraunhofer.de> wrote:

Hi Mo, 

The reason for forcing to use DON for MRST and MRMT is actually to red= uce the implementation complexity. We could have followed the design in RFC= 6190 by having four transmission modes NI-T, NI-TC, NI-C and I-C but it wa= s agreed from the beginning that such a thing should be avoided. 

You are right when you say that the same principle of NI-T could be us= ed without requiring the presence of the DON field, but this would lead for= sure to the same result we had in RFC 6190, four modes. NI-TC was found ve= ry useful back then to solve issues of time stamp based (NI-T) decoding order recovery under loss events.

Note additionally that the NI-T case requires the dependent RTP (enhan= cement layes) streams to contain data for all sampling instances that exist= in their dependee RTP streams (base layer or lower layers), e.g. by using = the empty NAL units described in RFC 6190, which also incur some overhead. Only if the decoding order is eq= ual to the presentation order (that is what I interpret from your comment a= bout frame reordering) this requirement would not be necessary. This is som= ething we would need to signal additionally, adding dependency on subtle SDP rules similar to the ones you mention.

In any case, I think that your proposal now introduces more problems t= han benefits. The design we chose at the beginning was concretely to avoid = all this potential problems that would require specific solutions making th= e design much more complicated only to save a couple of bytes required to add the DON field. Therefore, I am h= ere with Ye-Kui and would prefer to keep the design as it is now.

Best regards,
Yago


On 10 Mar 2015, at 08:13, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:

Hi YK, see Mo: inline.
Regards,
Mo

On 3/6/15, 1:04 AM, Wang, Ye-Kui <y= ekuiw@qti.qualcomm.com> wrote:

Hi Mo,
 
See my comments inline below.
 
BR, YK
 
From:=  payload [mailto:payload-bounces@ietf.org] On Behalf Of Mo Zanaty = (mzanaty)
Sent: Thursday, Ma= rch 05, 2015 7:09 PM
To: draft-ietf-payload-rtp-h265@tools.ietf= .org
Cc: payload@ietf.org
Subject: [payload]= DON in H.265 RTP draft
 
Hi,
Based on im= plementation experience with DON in draft-ietf-payload-rtp-h265-07, here ar= e some suggested changes in the draft to simplify implementations and impro= ve robustness.
 =
DON (Decodi= ng Order Number)
 =
DON is only= necessary when using interleaved transmission (for error resilience) or re= ordered frames (for coding efficiency), if willing to incur the additional = latency and complexity of these techniques. These techniques are not used in many (probably most) systems, so DON shou= ld not be required in those cases. 
&nb= sp;
[YK] No, DON is needed when either interleaved transmissio= n or multi-stream transmission (MRST/MRMT), otherwise DON is not needed. Re= ordered pictures for improve coding efficiency is not a reason for DON.

Mo: DON is not needed for MRST/MRMT unless reordered frames are used. = See mst-mode=3DNI-T in H.264 SVC RFC 6190. The same applies to MRST/MRMT in= H.265. H.264 did not force the complexity of DON for the very common cases= of no reordered frames, so H.265 should likewise not force such complexity.
 
However, th= e current draft requires DON when tx-mode is MRST or MRMT (or sprop-max-don= -diff>0). This causes unnecessary complexity, RTP packet overhead, and p= otential for RTP packet parsing failure due to conditional DON fields whose presence depends on subtle SDP rules. = If implementations interpret these subtle SDP rules differently or improper= ly, RTP packet parsing completely fails, which is undesirably fragile.=
 
[YK] Could you please clarify what is the unnecessary comp= lexity and RTP packet overhead? Also, when tx-mode is present, the value is= clear, and when not present, the default value is specified. This rule is simple and clear. Could you pleas= e provide an example use case where a problem can occur?<= /div>

Mo: DON is unnecessary complexity and packet overhead. Existing RTP he= ader fields already provide decode order without introducing an artificial,= redundant DON. It was introduced in H.264 RFC 3984 for the interleaved mod= e, which was never widely deployed. It was retained in H.264 SVC RFC 6190 for the interleaved mode and MST mod= es with reordered frames. It should be retained in H.265 for the same (rare= ) cases, but not forced in unnecessary (and very common) cases. It is also = fragile for RTP packet layout to depend on subtle SDP rules. As stated above, a severe problem can occur if= implementations have different views of whether DON should be present or n= ot, due to different SDP implementations or even transient renegotiation. R= TP packet parsing completely fails because one side thinks payloads start at offset N while the other thinks = N+2 due to DON conditionally present based on SDP rules.

The suggest= ed change is to revert to the original design in the individual 00 draft (a= nd RFC 6190), which uses separate explicit payload structures for RTP packe= ts without DON (FU-A, STAP-A) and with DON (FU-B, STAP-B). Receivers must still support DON, but senders onl= y use it when necessary, i.e. interleaved transmission or reordered frames.= This has several benefits.
 
a. RTP pack= et parsing is more robust since RTP packets are self-describing with no dep= endency on subtle SDP rules.
b. RTP pack= et overhead is reduced in cases where DON is unnecessary, including many/mo= st MRST and MRMT cases.
c. Aligns b= etter with H.264 so those implementations can more easily add H.265.
 
The only dr= awback is this requires 2 extra NAL unit types (51, 52), but that is accept= able since the space is doubled in H.265 (64 vs. 32 in H.264).
 
[YK] If you do that, then you would also need to specify d= ifferent packetization modes, and which payload structures are allowed in w= hich packetization mode, and you would also need to specify different modes of de-packetization. Basically, the c= omplexity would be similarly to the sum of RFC 6184 and RFC 6190. That make= s it significantly more complicated than what we have now. Note that we int= entionally avoided all these to simply the design and this was welcomed by the group.

Mo: I very much welcomed the simpler design of no different packetizat= ion modes negotiated in SDP. Thanks for that. I do not suggest we change th= at. I suggest what I stated above. =93Receivers must still support DON, but= senders only use it when necessary.=94
 
If there is= agreement on this suggested change, I will propose specific text changes. = Although conceptually simple, it does impact a non-trivial amount of text, = mostly repeated.
 
[YK] I thus certainly disagree to go back. Note that in th= e individual 00 draft a lot of details were not included yet. Feel free to = try to do the text changes, and if you make it working and complete you would agree that things would become = much more complicated than what we have now.
 
Mo: Ok, I will do the text changes and report back.

Regards,
Mo
 
 
_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman= /listinfo/payload

--_000_D12477B9480BFmzanatyciscocom_-- From nobody Thu Mar 19 04:14:53 2015 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 452251A897F for ; Thu, 19 Mar 2015 04:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 luUoLyXUJfhx for ; Thu, 19 Mar 2015 04:14:46 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325361A897D for ; Thu, 19 Mar 2015 04:14:46 -0700 (PDT) Received: by qgh62 with SMTP id 62so61601439qgh.1 for ; Thu, 19 Mar 2015 04:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=iWXsuZmf5ZVCYFNQlIXH7m/iwEvxM2ipn0bkyf3ZpzU=; b=C+7W3DajkDM0b0dvku8czfuMOekf58q0KdUTNedfRiq4Tj1w6yfzyfB4W2JjOCwhEP Wq8zTQNa6rrH2PNLxxtBWJ7tYE6djuDxOYLg2AiCY1ieFc7zMsRf3ErXh3hGKNc0K6ip Ipf0kg8S8SABw+R0PSubE66qDe6zhc1cOKCAGIzJazD3t81SPdek+iDmwdrBSYkWU2jr hC5qziZTCnO1nbKLv32R1CCot/IHpIpGFH3joq1WA+QTH5xQvMm0rdrmnbkp/CtPOnIF ZFkFBFG8Ty/9jFtKsQ4mFbIW0XP77iafC8c2SbFVoMoGcq8w6YP0/cZKKl0HfpgJ0Urr NjAQ== X-Received: by 10.140.150.149 with SMTP id 143mr98570836qhw.4.1426763685477; Thu, 19 Mar 2015 04:14:45 -0700 (PDT) Received: from RoniE ([50.94.102.106]) by mx.google.com with ESMTPSA id f125sm576886qhe.47.2015.03.19.04.14.43 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Mar 2015 04:14:44 -0700 (PDT) From: "Roni Even" To: "'Harald Alvestrand'" , References: <20150303205231.10208.20421.idtracker@ietfa.amsl.com> <54F994BA.1050402@alvestrand.no> In-Reply-To: <54F994BA.1050402@alvestrand.no> Date: Thu, 19 Mar 2015 13:14:41 +0200 Message-ID: <007601d06235$e6ac88c0$b4059a40$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01D06246.AA36DF60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF3mL87SwkyJrV0iBXK4vqR1/R+EgHBojHmAnCTKcKds6eioA== Content-Language: en-us Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-14.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: Thu, 19 Mar 2015 11:14:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0077_01D06246.AA36DF60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Harald, The problem is that you cannot describe values per payload type number using current SDP attributes the bit rate is for the whole m-line. For example if using a=ssrc it is not mapped to a payload type number BTW: this is one point we made in the application id document. Roni From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: 06 March, 2015 1:51 PM To: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-14.txt On 03/05/2015 08:25 PM, Mo Zanaty (mzanaty) wrote: Hi, The simulcast draft (draft-ietf-mmusic-sdp-simulcast) uses payload formats to express different simulcast encodings. This assumes the underlying payload format can express the desired encodings in its a=fmtp parameters. VP8 can express max-fs (roughly resolution) and max-fr (frame rate), which covers most simulcast use cases. However, you may want to consider adding max-br (bit rate) if you want to express simulcasting VP8 at different bit rates (for the same or different resolutions and frame rates). Thanks for the alert to mmusic-simulcast! I've protested vehemently about the (ab)use of (codec-specific) a=fmtp parameters to express (codec-independent) quality distinctions in the past. I'll go protest again. Harald Regards, Mo On 3/3/15, 3:52 PM, internet-drafts@ietf.org wrote: 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 VP8 Video Authors : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-14.txt Pages : 25 Date : 2015-03-03 Abstract: This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-vp8-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-14 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/ _______________________________________________ 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 -- Surveillance is pervasive. Go Dark. ------=_NextPart_000_0077_01D06246.AA36DF60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Harald,

The problem is that you cannot describe values per payload type = number using current SDP attributes the bit rate is for the whole = m-line. For example if using a=3Dssrc it is not mapped to a payload type = number

BTW: this is one point we made in the application id = document.

Roni

 

From: payload [mailto:payload-bounces@ietf.org] On Behalf Of = Harald Alvestrand
Sent: 06 March, 2015 1:51 = PM
To: payload@ietf.org
Subject: Re: [payload] I-D = Action: = draft-ietf-payload-vp8-14.txt

 

On = 03/05/2015 08:25 PM, Mo Zanaty (mzanaty) = wrote:

Hi,

 

The simulcast draft (draft-ietf-mmusic-sdp-simulcast) = uses payload formats to express different simulcast encodings. This = assumes the underlying payload format can express the desired encodings = in its a=3Dfmtp parameters. VP8 can express max-fs (roughly resolution) = and max-fr (frame rate), which covers most simulcast use cases. However, = you may want to consider adding max-br (bit rate) if you want to express = simulcasting VP8 at different bit rates (for the same or different = resolutions and frame rates).


Thanks for the alert to = mmusic-simulcast!

I've protested vehemently about the (ab)use of = (codec-specific) a=3Dfmtp parameters to express (codec-independent) = quality distinctions in the past. I'll go protest = again.

Harald


 

Regards,

Mo

 

 

On 3/3/15, 3:52 PM, internet-drafts@ietf.org = <internet-drafts@ietf.org>= wrote:

 

 

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&n= bsp;          : RTP Payload = Format for VP8 Video

        Authors=          : Patrik = Westin

         &= nbsp;           &n= bsp;    Henrik F Lundin

         &= nbsp;           &n= bsp;    Michael Glover

         &= nbsp;           &n= bsp;    Justin Uberti

         &= nbsp;           &n= bsp;    Frank Galligan

Filename        = ;: draft-ietf-payload-vp8-14.txt

Pages        &n= bsp;  : 25

Date        &nb= sp;   : 2015-03-03

 

Abstract:

   This memo describes an RTP payload format = for the VP8 video codec.

   The payload format has wide = applicability, as it supports

   applications from low bit-rate = peer-to-peer usage, to high bit-rate

   video = conferences.

 

 

The IETF datatracker status page for this draft = is:

https:/= /datatracker.ietf.org/doc/draft-ietf-payload-vp8/

 

There's also a htmlized version available = at:

 

A diff from the previous version is available = at:

 

 

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:

 

_______________________________________________

payload mailing = list

payload@ietf.org

 




_______________________=
________________________
payload mailing =
list
payload@ietf.org
https://www.ietf.o= rg/mailman/listinfo/payload




-- =

Surveillance is pervasive. Go =
Dark.
------=_NextPart_000_0077_01D06246.AA36DF60-- From nobody Thu Mar 19 14:18:14 2015 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 704491A8891 for ; Thu, 19 Mar 2015 14:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_OUTLOOK_TAGS=0.052, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 sBefSZoaUgX2 for ; Thu, 19 Mar 2015 14:18:12 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8E51A1DE1 for ; Thu, 19 Mar 2015 14:18:12 -0700 (PDT) Received: by qcto4 with SMTP id o4so78252138qct.3 for ; Thu, 19 Mar 2015 14:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=t90gWxv0onhD63MCN4nqjQjdo0QZ3sGHSr92bZlXirM=; b=TT9LbBcAKsZBUkWrSM+FxOMHrBDn+vu2/o/iaHoR17tjbthq9EAAzcsVmtAcn5HBtE 8/l3ovARJCtqjXOR259mz0TeyMwFRBSeSLbL9/LmCBFHRAzqpzzz4vdx4sU7QsFtYd+9 CtS0+Il/7C6hjV993gf9VTDySicCUvn8C5W/6oue8TjcagpFXs8dBWncGnKE3Y+YtyAe vRF1q/IrfAHEjBbrctpvJF1n/crTd0hd1bFGrtXWKi7C/kBO03FYRShb3DxQYSIW2Zfv Cdb1TuGsptTPUsBAdAjvUrp1EVtQyRLGdzGrpSyy/78l+yn2Za6cEDs+MAJN5Q0iZFd3 LF9w== X-Received: by 10.55.31.143 with SMTP id n15mr124275188qkh.70.1426799891335; Thu, 19 Mar 2015 14:18:11 -0700 (PDT) Received: from RoniE ([50.94.102.94]) by mx.google.com with ESMTPSA id 8sm1636669qhr.32.2015.03.19.14.18.08 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Mar 2015 14:18:10 -0700 (PDT) From: "Roni Even" To: Date: Thu, 19 Mar 2015 23:18:04 +0200 Message-ID: <005a01d0628a$33088670$99199350$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_005B_01D0629A.F691CBA0" X-Mailer: Microsoft Outlook 14.0 thread-index: AdBiihjLIMdmzSOcSo+ihN7ieTvEAA== Content-Language: en-us Archived-At: Subject: [payload] Updated agenda for payload session in Dallas 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, 19 Mar 2015 21:18:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005B_01D0629A.F691CBA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_005C_01D0629A.F691CBA0" ------=_NextPart_001_005C_01D0629A.F691CBA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is an update to the agenda Roni Even Payload WG co-chair ------=_NextPart_001_005C_01D0629A.F691CBA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is an = update to the agenda

Roni = Even

Payload WG = co-chair

------=_NextPart_001_005C_01D0629A.F691CBA0-- ------=_NextPart_000_005B_01D0629A.F691CBA0 Content-Type: text/plain; name="p1503.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="p1503.txt" Audio/Video Transport Payoads (Payload) Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CHAIRS: Ali Begen Roni Even AGENDA Tuesday, 25 March 2015 at 15:20-16:20 (Continental) --------------------------------------------------- 15:20 Payload Status Update (Chairs, 10) 15:30 RTP Payload for SMPTE ST 291 Ancillary Data (Thomas Edwards, 10) draft-edwards-payload-rtp-ancillary-01 15:40 RTP Payload Format for Non-Interleaved and Interleaved Parity = FEC(Varun Singh , 15) draft-singh-payload-rtp-1d2d-parity-scheme-00 15:55 RTP Payload Format for VP9 Video (Jonathan Lennox, 15) draft-uberti-payload-vp9-01 16:10 End ------=_NextPart_000_005B_01D0629A.F691CBA0 Content-Type: text/html; name="p1503.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="p1503.html" Audio/Video Transport Payoads (Payload) Working Group = Agenda

Audio/Video Transport Payoads (Payload) = Working Group Agenda

Chairs: Ali Begen , Roni Even =

Tuesday, 25 March 2015 at 15:20-16:20 (Continental)

15:20 Payload Status UpdateChairs
15:30 RTP Payload for SMPTE ST 291 Ancillary DataThomas Edwards
= draft-edwards-payload-rtp-ancillary-01
15:40 RTP Payload Format for Non-Interleaved and = Interleaved Parity FECVarun Singh=20
draft-singh-payload-rtp-1d2d-parity-scheme-00
15:55 RTP Payload Format for VP9 VideoJonathan Lennox
draft-ubert= i-payload-vp9-01
16:10 End
------=_NextPart_000_005B_01D0629A.F691CBA0-- From nobody Thu Mar 19 14:35:01 2015 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 473181A88B8 for ; Thu, 19 Mar 2015 14:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 xt3mFuufsEBu for ; Thu, 19 Mar 2015 14:34:58 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E2A1A1B76 for ; Thu, 19 Mar 2015 14:34:58 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2A21322E25F for ; Thu, 19 Mar 2015 17:34:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Cullen Jennings In-Reply-To: <20150303205231.10208.20421.idtracker@ietfa.amsl.com> Date: Thu, 19 Mar 2015 15:34:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <624F9FD9-A4E0-4191-B9BD-67A9BFA21169@iii.ca> References: <20150303205231.10208.20421.idtracker@ietfa.amsl.com> To: payload@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [payload] Comment on draft-ietf-payload-vp8-14.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: Thu, 19 Mar 2015 21:35:00 -0000 One small thing ... the References need to be sorted into Normative and = Informative. > On Mar 3, 2015, at 1:52 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : RTP Payload Format for VP8 Video > Authors : Patrik Westin > Henrik F Lundin > Michael Glover > Justin Uberti > Frank Galligan > Filename : draft-ietf-payload-vp8-14.txt > Pages : 25 > Date : 2015-03-03 >=20 > Abstract: > This memo describes an RTP payload format for the VP8 video codec. > The payload format has wide applicability, as it supports > applications from low bit-rate peer-to-peer usage, to high bit-rate > video conferences. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-payload-vp8-14 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-14 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From nobody Thu Mar 19 15:23:06 2015 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 3847C1B2AF8 for ; Thu, 19 Mar 2015 15:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_OUTLOOK_TAGS=0.052, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 gg3HRF01UKpk for ; Thu, 19 Mar 2015 15:23:02 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED90C1A90F6 for ; Thu, 19 Mar 2015 15:23:01 -0700 (PDT) Received: by qcto4 with SMTP id o4so79556015qct.3 for ; Thu, 19 Mar 2015 15:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=H8EG5tNZBaW1SSGB5aTMawyoqDYFffj7rR5MSsRd1B0=; b=Pk7yvRhOIKrlDU0TVHQPw4XjJDcp1RzTRTvffP4Re/fOGA1lt5XBsNtGFVllR2hj3p qtEA+5JdoXkC9dtfduOz+RveNwAw5dGXzOPj5G3YHncrmdjoAqnXccDICTjRfC8VBoC/ ltGKlNkgmOmKpbhB1W6g5JAF+iNVQygzSEznYRlqw3/u//H9w4uMPwg7CZ9xs0NCnF8f /+N9gdTMJ80e1CPR50phO/fVwbMCPUklW+mnlrp27MXRBuAOV1jRelSK1Ct16QxoVX4S 2VfVOL75elImNOEkZm8ZXlsxDjFOLWhDGxZlX3SNG97qoakbhLlOQCN6tKUXMKwiidR8 p1xQ== X-Received: by 10.140.144.73 with SMTP id 70mr100099247qhq.34.1426803781229; Thu, 19 Mar 2015 15:23:01 -0700 (PDT) Received: from RoniE ([50.94.102.94]) by mx.google.com with ESMTPSA id 142sm1760804qhg.16.2015.03.19.15.22.59 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Mar 2015 15:23:00 -0700 (PDT) From: "Roni Even" To: Date: Fri, 20 Mar 2015 00:22:58 +0200 Message-ID: <007001d06293$41e25190$c5a6f4b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0071_01D062A4.056B96C0" X-Mailer: Microsoft Outlook 14.0 thread-index: AdBikyU/owArDLyVTmC9QBHI+S9F1g== Content-Language: en-us Archived-At: Subject: [payload] another update to payload agenda 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, 19 Mar 2015 22:23:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0071_01D062A4.056B96C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0072_01D062A4.056B96C0" ------=_NextPart_001_0072_01D062A4.056B96C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Sorry for all the changes. Hope we are done now Thanks Roni ------=_NextPart_001_0072_01D062A4.056B96C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Sorry for all = the changes.

Hope we are done = now

Thanks

Roni

------=_NextPart_001_0072_01D062A4.056B96C0-- ------=_NextPart_000_0071_01D062A4.056B96C0 Content-Type: text/plain; name="p1503.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="p1503.txt" Audio/Video Transport Payoads (Payload) Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CHAIRS: Ali Begen Roni Even AGENDA Tuesday, 25 March 2015 at 15:20-16:20 (Continental) --------------------------------------------------- 15:20 Payload Status Update (Chairs, 10) 15:30 RTP Payload Format for MELPe Codec (Roni Even, 10) draft-demjanenko-payload-melpe-02 15:40 RTP Payload for SMPTE ST 291 Ancillary Data (Thomas Edwards, 10) draft-edwards-payload-rtp-ancillary-01 15:50 RTP Payload Format for Non-Interleaved and Interleaved Parity = FEC(Varun Singh , 15) draft-singh-payload-rtp-1d2d-parity-scheme-00 16:05 RTP Payload Format for VP9 Video (Jonathan Lennox, 15) draft-uberti-payload-vp9-01 16:20 End ------=_NextPart_000_0071_01D062A4.056B96C0 Content-Type: text/html; name="p1503.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="p1503.html" Audio/Video Transport Payoads (Payload) Working Group = Agenda

Audio/Video Transport Payoads (Payload) = Working Group Agenda

Chairs: Ali Begen , Roni Even =

Tuesday, 25 March 2015 at 15:20-16:20 (Continental)

15:20 Payload Status UpdateChairs
15:30 RTP Payload Format for MELPe CodecRoni Even
draft= -demjanenko-payload-melpe-02
15:40 RTP Payload for SMPTE ST 291 Ancillary DataThomas Edwards
= draft-edwards-payload-rtp-ancillary-01
15:50 RTP Payload Format for Non-Interleaved and = Interleaved Parity FECVarun Singh=20
draft-singh-payload-rtp-1d2d-parity-scheme-00
16:05 RTP Payload Format for VP9 VideoJonathan Lennox
draft-ubert= i-payload-vp9-01
16:20 End
------=_NextPart_000_0071_01D062A4.056B96C0-- From nobody Fri Mar 20 04:35:34 2015 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 44A371B2CDF for ; Fri, 20 Mar 2015 04:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, T_RP_MATCHES_RCVD=-0.01] 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 jhx_guzXFbPL for ; Fri, 20 Mar 2015 04:35:33 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE261A898B for ; Fri, 20 Mar 2015 04:35:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6F1F07C0858; Fri, 20 Mar 2015 12:35:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVj8Pwuz9vQI; Fri, 20 Mar 2015 12:35:31 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:29e6:9ab4:82a7:58a1]) by mork.alvestrand.no (Postfix) with ESMTPSA id 609F37C07C2; Fri, 20 Mar 2015 12:35:31 +0100 (CET) Message-ID: <550C0603.9060804@alvestrand.no> Date: Fri, 20 Mar 2015 12:35:31 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Roni Even , payload@ietf.org References: <20150303205231.10208.20421.idtracker@ietfa.amsl.com> <54F994BA.1050402@alvestrand.no> <007601d06235$e6ac88c0$b4059a40$@gmail.com> In-Reply-To: <007601d06235$e6ac88c0$b4059a40$@gmail.com> Content-Type: multipart/alternative; boundary="------------050305030809010903070500" Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-14.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: Fri, 20 Mar 2015 11:35:34 -0000 This is a multi-part message in MIME format. --------------050305030809010903070500 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 03/19/2015 12:14 PM, Roni Even wrote: > > Hi Harald, > > The problem is that you cannot describe values per payload type number > using current SDP attributes the bit rate is for the whole m-line. For > example if using a=ssrc it is not mapped to a payload type number > > BTW: this is one point we made in the application id document. > Yes, this is a problem that needs solving. Tying bitrates to payload types is also a Bad Idea; if we are ever to get reasonable handling of multiple SSRCs in the same media description with the same payload type, we need to tie them to some other identifier. But in the context of simulcast as described here, I guess that Bad Idea is already so deeply adopted that it can't be removed. But it still doesn't excuse the misfeature of trying to do external imposition of parameters on the a=fmtp line. I'll go be explicit on mmusic now. --------------050305030809010903070500 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

On 03/19/2015 12:14 PM, Roni Even wrote:

Hi Harald,

The problem is that you cannot describe values per payload type number using current SDP attributes the bit rate is for the whole m-line. For example if using a=ssrc it is not mapped to a payload type number

BTW: this is one point we made in the application id document.


Yes, this is a problem that needs solving.

Tying bitrates to payload types is also a Bad Idea; if we are ever to get reasonable handling of multiple SSRCs in the same media description with the same payload type, we need to tie them to some other identifier. But in the context of simulcast as described here, I guess that Bad Idea is already so deeply adopted that it can't be removed.

But it still doesn't excuse the misfeature of trying to do external imposition of parameters on the a=fmtp line.

I'll go be explicit on mmusic now.

--------------050305030809010903070500-- From nobody Fri Mar 20 13:50:14 2015 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 7067A1B30C5; Fri, 20 Mar 2015 13:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, 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 8XVRUlQmKfxz; Fri, 20 Mar 2015 13:50:09 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153601A9027; Fri, 20 Mar 2015 13:50:09 -0700 (PDT) Received: by qgh62 with SMTP id 62so103783901qgh.1; Fri, 20 Mar 2015 13:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=R4b1gXKfPa2VC/uFShQPxaWYNxxnrq9HKI4VdGsL/RA=; b=giExOx4TKEKhSMy7RF1IbV/aOokkD/z0moEqQEMhMnjIsHxxNy7NUgWeXed0ye3WC4 8GXEbnOk+6klmvpMsVzIDZb1TIaVL1FvXurey/wL59junbChZ8t0VcDYGmjxDhIqYWdx nvsXJe4ViLw8B54MgabOPURdoBnh230/6WwafZlA87KZby7uSnjTZ2qeA3hcpcLpRJ3p DNywOUY26k0C9I0aNMY8QbAqIN2kuqn4X/icAyGPUGzHcBJYbC1E4Q6U3R75n5aSatgY WKZHK1ybPUZIxmG1FvAsRQ5Opma7p5nFZbdQXqsTMGub+aEepPFSbhHBlQBtBeQA0h3L /KGg== X-Received: by 10.55.25.169 with SMTP id 41mr106358813qkz.105.1426884608359; Fri, 20 Mar 2015 13:50:08 -0700 (PDT) Received: from RoniE (ip-64-134-66-237.public.wayport.net. [64.134.66.237]) by mx.google.com with ESMTPSA id b66sm3776282qkb.38.2015.03.20.13.50.06 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 Mar 2015 13:50:07 -0700 (PDT) From: "Roni Even" To: "'Black, David'" , , "'Paul E. Jones'" , , , , References: In-Reply-To: Date: Fri, 20 Mar 2015 22:50:04 +0200 Message-ID: <00b201d0634f$72358260$56a08720$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEWFnT+JeFbkfrrcMco2eodWkWCYZ6acN5A Content-Language: en-us Archived-At: Cc: payload@ietf.org Subject: Re: [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: Fri, 20 Mar 2015 20:50:13 -0000 Hi David, Sorry for not commenting but I also saw Robert's email and would like to emphasis that RTP payloads document do not go into the internals of the codec payload. They just explain how to package the media payload and provide enough information for a receiver to extract the media payload. They must have a reference to the media payload that is publicly = available and for this document it is the ITU-T document. Thanks Roni Even Payload WG co-chair > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Black, = David > Sent: 24 December, 2014 7:42 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; > ops-dir@ietf.org > Cc: Black, David; payload@ietf.org > Subject: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 >=20 > 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. >=20 > The following issues are still open: >=20 > -- Major -- (these four are all now minor issues in -04) >=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 > 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. >=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 > This is mostly done in Section 3.3, but is a bit unclear: >=20 > 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). >=20 > 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" > is an encoded value - if so, here's some suggested text: >=20 > 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). >=20 > 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. >=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). > > > [... snip ...] > > > > 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: >=20 > 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. >=20 > A definition would help - somewhere before that first use of ptime, = define > "ptime" using the words from RFC 4566: >=20 > 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]. >=20 > > [D] Backwards compatibility. > > > > 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: > > > > 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. > > > > That's definitely wrong. Use of G.711.0 when only G.711 has been > > negotiated will fail to interoperate correctly. >=20 > That problematic sentence is still there - I suggest a minor change to remove > the word "negotiated": >=20 > 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. >=20 > Then the added sentence on negotiation being out of scope (end of paragraph > that begins with that problematic sentence) makes more sense. >=20 > -- Minor -- >=20 > > [F] Section 4.1: > > > > 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. > > > > Good start, but not sufficient - cite the "RTP profiles currently in > > use" and I would expect those citations to be normative references. >=20 > Not done. Just listing those profiles with RFC citations will = suffice. >=20 > > [G] Framing errors > > > > 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 > 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. >=20 > Thanks, > --David >=20 >=20 > > -----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 > > > > This is a combined Gen-ART and OPS-DIR review. Boilerplate for both > > follows ... > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at: > > > > . > > > > Please resolve these comments along with any other Last Call = comments > > you may receive. > > > > I have reviewed this document as part of the Operational = directorate's > > ongoing 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. > > > > 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 > > > > Summary: This draft is on the right track, but has open issues > > described in the review. > > > > 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. > > > > 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. > > > > 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. > > > > -- Major Issues (4): > > > > [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. > > > > [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. > > > > [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). > > > > 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?): > > > > 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. > > > > 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. > > > > This major issue [C] is independent of the relationship between this > > draft and the G.711.0 spec. > > > > [D] Backwards compatibility. > > > > 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: > > > > 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. > > > > That's definitely wrong. Use of G.711.0 when only G.711 has been > > negotiated will fail to interoperate correctly. > > > > A subsection of section 3 on negotiation and SDP usage would help = here. > > > > This major issue [D] is independent of the relationship between this > > draft and the G.711.0 spec. > > > > -- Minor issues (3): > > > > [E] Section 4.1: > > > > 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. > > > > I would change "will have" to "MUST have" and add the following sentence: > > > > The existing G.711 PT values of 0 and 8 MUST NOT be used for = G.711.0 > > content. > > > > 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 . > > > > [F] Section 4.1: > > > > 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. > > > > Good start, but not sufficient - cite the "RTP profiles currently in > > use" and I would expect those citations to be normative references. > > > > Would that be just RFC 3551 and RFC 4585 (both are already normative > > references), or are there more RTP profiles? > > > > [G] Framing errors > > > > 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. > > > > 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. > > > > -- Nits/editorial comments: > > > > Section 3.2: > > > > 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". > > > > 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. > > > > 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]. > > > > Expand WMOPS on first use, and check for other acronyms that need to > > be expanded on first use. > > > > Section 3.3: > > > > 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). > > > > "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. > > > > Section 6: > > > > 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. > > > > "that not" -> "that are not" > > > > Section 6.2: > > > > 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. > > > > 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. > > > > Section 11: Congestion Control > > > > 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". > > > > 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. > > > > idnits 2.13.01 didn't find anything to complain about ;-). > > > > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > > > 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. > > > > A.1.3. Has the migration path been discussed? > > > > No, see major issue [D] above. > > > > A.1.4 Have the Requirements on other protocols and functional > > components been discussed? > > > > Only in part - major issues [C] and [D] call out shortcomings in the > > discussion of SDP interactions. > > > > A.1.8 Are there fault or threshold conditions that should be = reported? > > > > 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]. > > > > A.2. Management Considerations > > > > I would expect that the media type registration (Section 5.1 of this > > draft) 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. > > > > A.3 Documentation > > > > By itself, this compressed payload format does not look like a = likely > > source of significant operational impacts on the Internet. > > > > The shepherd's writeup indicates that an implementation exists. > > > > 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-7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Fri Mar 20 15:46:19 2015 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 8ADC81A88A4; Fri, 20 Mar 2015 15:46:15 -0700 (PDT) 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 VH7BKrv3XJ8b; Fri, 20 Mar 2015 15:46:09 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 C46AB1A88CA; Fri, 20 Mar 2015 15:46:08 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t2KMk0ES025258 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 Mar 2015 18:46:01 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t2KMk0ES025258 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1426891561; bh=1WpGVW5aBZ39Y5lOvUUYvLZt+9U=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=RRStsM5Re9uXgIvRe+FFgNhk4ZfSFFV3QuHi/tgyVhR9SA9cNTs25QdRJxhg8q2Wc FORmJ4PkSVYLr4VDZJmc7VsaOAJ4gOI4w9L11GkJ1PX0o5QWliuKmX6jWqX8Vwe7ta ZsUNzcEfnQpYVwGg9/q7gEHw0dIutBdkhr6wq9Oo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t2KMk0ES025258 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd05.lss.emc.com (RSA Interceptor); Fri, 20 Mar 2015 18:45:40 -0400 Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com [128.222.70.107]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t2KMjixH031581 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Mar 2015 18:45:44 -0400 Received: from MXHUB204.corp.emc.com (10.253.68.30) by mxhub40.corp.emc.com (128.222.70.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 20 Mar 2015 18:45:44 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB204.corp.emc.com ([10.253.68.30]) with mapi id 14.03.0224.002; Fri, 20 Mar 2015 18:45:43 -0400 From: "Black, David" To: Roni Even , "mramalho@cisco.com" , "'Paul E. Jones'" , "harada.noboru@lab.ntt.co.jp" , "muthu.arul@gmail.com" , "lei.miao@huawei.com" , "ops-dir@ietf.org" Thread-Topic: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 Thread-Index: AdAfPFVGeZeAXS5RRlmbbcNFHVlO1BENKKYAAATmz2A= Date: Fri, 20 Mar 2015 22:45:43 +0000 Message-ID: References: <00b201d0634f$72358260$56a08720$@gmail.com> In-Reply-To: <00b201d0634f$72358260$56a08720$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.163] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "Black, David" , "payload@ietf.org" Subject: Re: [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: Fri, 20 Mar 2015 22:46:15 -0000 Roni, > Sorry for not commenting but I also saw Robert's email and would like to > emphasis that RTP payloads document do not go into the internals of the > codec payload. They just explain how to package the media payload and > provide enough information for a receiver to extract the media payload. > They must have a reference to the media payload that is publicly availabl= e > and for this document it is the ITU-T document. My concern is a bit different. I concur that the full details of the "internals of the codec payload" are not necessary in this draft, and=20 I don't believe my review has ever asked for that. OTOH, I believe that the scope of this draft should be consistent across encoding and decoding. For that reason, starting with the prefix code as an example, I believe that if this draft uses a data element to specify the decoding algorithm, then the encoding algorithm portion of this draft should specify or otherwise explain where that data element came from when the corresponding encoding was performed. For the prefix code example, the authors' proposal to add the following sentence (from Michael's email) appears to be sufficient to address this concern: As an aside, we note that the first octet of any G.711.0 frame will be the prefix code octet and information in this octet determines how many G.711 symbols are represented in the G.711.0 frame. My understanding from other emails is that typical payload drafts do not depend on values that are part of the codec payload - in contrast, this draft has such a dependency on at least the prefix code. That is not an inherent problem, but it does create a need to explain what's going on. I do not expect to have time to fully review Michael's response (to a revie= w that I originally sent back in December) until after the Dallas meeting wee= k. Thanks, --David > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Friday, March 20, 2015 4:50 PM > To: Black, David; mramalho@cisco.com; 'Paul E. Jones'; > harada.noboru@lab.ntt.co.jp; muthu.arul@gmail.com; lei.miao@huawei.com; o= ps- > dir@ietf.org > Cc: payload@ietf.org > Subject: RE: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 >=20 > Hi David, > Sorry for not commenting but I also saw Robert's email and would like to > emphasis that RTP payloads document do not go into the internals of the > codec payload. They just explain how to package the media payload and > provide enough information for a receiver to extract the media payload. > They must have a reference to the media payload that is publicly availabl= e > and for this document it is the ITU-T document. > Thanks > Roni Even > Payload WG co-chair >=20 > > -----Original Message----- > > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Black, Dav= id > > Sent: 24 December, 2014 7:42 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; > > ops-dir@ietf.org > > Cc: Black, David; payload@ietf.org > > Subject: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 > > > > The -04 version of this draft is an improvement, but does not resolve a= ll > 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 holdin= g > 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 ho= w > > > 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 t= he > "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 importan= t > > > 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 larg= er > > than 255. I'm guessing that the "Prefix Code" > > 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 affec= t > 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 an= d > > > imprecise (is SDP REQUIRED?, when is ptime REQUIRED, RECOMMENDED, or > > > recommended? - it's not obvious). > > > > > [... snip ...] > > > > > > I would suggest that a subsection be added, possibly at the end of > > > Section 3, to gather/summarize all of the relevant ptime discussion i= n > > > 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. > > > > Not done, although the sentence added (for [D]) on negotiation being ou= t > of > > scope helps. The first mention of "ptime" is in A4 in Section 3.2, wit= h > > 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, def= ine > > "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. > > > > > > 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 probl= em: > > > > > > G.711.0, being both lossless and stateless, may also be employed a= s a > > > lossless compression mechanism anywhere between end systems which > > > have negotiated use of G.711. > > > > > > 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: > > > > > > PT - The assignment of an RTP payload type for the format defin= ed > > > 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. > > > > > > 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 > > > > > > 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 shou= ld > 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 > > > > > > This is a combined Gen-ART and OPS-DIR review. Boilerplate for both > > > follows ... > > > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > > Gen-ART, please see the FAQ at: > > > > > > . > > > > > > Please resolve these comments along with any other Last Call comments > > > you may receive. > > > > > > I have reviewed this document as part of the Operational directorate'= s > > > ongoing 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. > > > > > > 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 > > > > > > Summary: This draft is on the right track, but has open issues > > > described in the review. > > > > > > 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 L= C > > > with IESG Evaluation can result in significant last-minute changes to > > > the draft when issues are discovered during IETF LC. > > > > > > 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. > > > > > > 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 t= o > > > completely understand what's going on. For this draft, I would expec= t > > > 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. > > > > > > -- Major Issues (4): > > > > > > [A] Section 4.2.3 specifies a detailed decoding algorithm covering ho= w > > > 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. > > > > > > [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 importan= t > > > to be hidden in step H5 of the decoding algorithm in Section 4.2.3. > > > > > > [C] The discussion of use of the SDP ptime parameter is spread out an= d > > > imprecise (is SDP REQUIRED?, when is ptime REQUIRED, RECOMMENDED, or > > > recommended? - it's not obvious). > > > > > > 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?): > > > > > > Similarly, if the number of > > > channels was not known, but the payload "ptime" was known, one cou= ld > > > infer (knowing the sampling rate) how many G.711 symbols each chan= nel > > > contained; then with this knowledge determine how many channels of > > > data were contained in the payload. > > > > > > I would suggest that a subsection be added, possibly at the end of > > > Section 3, to gather/summarize all of the relevant ptime discussion i= n > > > 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. > > > > > > This major issue [C] is independent of the relationship between this > > > draft and the G.711.0 spec. > > > > > > [D] Backwards compatibility. > > > > > > 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 probl= em: > > > > > > G.711.0, being both lossless and stateless, may also be employed a= s a > > > lossless compression mechanism anywhere between end systems which > > > have negotiated use of G.711. > > > > > > That's definitely wrong. Use of G.711.0 when only G.711 has been > > > negotiated will fail to interoperate correctly. > > > > > > A subsection of section 3 on negotiation and SDP usage would help her= e. > > > > > > This major issue [D] is independent of the relationship between this > > > draft and the G.711.0 spec. > > > > > > -- Minor issues (3): > > > > > > [E] Section 4.1: > > > > > > 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 contras= t > > > to most current uses of G.711 which typically use the static paylo= ad > > > assignment of PT =3D 0 (PCMU) or PT =3D 8 (PCMA) [RFC3551] even th= ough > > > the negotiation and use of dynamic payload types is allowed for > > > G.711. > > > > > > I would change "will have" to "MUST have" and add the following > sentence: > > > > > > The existing G.711 PT values of 0 and 8 MUST NOT be used for G.711= .0 > > > content. > > > > > > 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 . > > > > > > [F] Section 4.1: > > > > > > PT - The assignment of an RTP payload type for the format defin= ed > > > 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. > > > > > > Good start, but not sufficient - cite the "RTP profiles currently in > > > use" and I would expect those citations to be normative references. > > > > > > Would that be just RFC 3551 and RFC 4585 (both are already normative > > > references), or are there more RTP profiles? > > > > > > [G] Framing errors > > > > > > 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 shou= ld > help. > > > > > > 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. > > > > > > -- Nits/editorial comments: > > > > > > Section 3.2: > > > > > > A6 Bounded expansion: Since attribute A2 above requires G.711.0 t= o > > > be lossless for any payload, by definition there exists at > > > least one potential G.711 payload which must be > > > "uncompressible". > > > > > > 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. > > > > > > 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]. > > > > > > Expand WMOPS on first use, and check for other acronyms that need to > > > be expanded on first use. > > > > > > Section 3.3: > > > > > > 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 us= ed > > > (A-law or mu-law). > > > > > > "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. > > > > > > Section 6: > > > > > > 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. > > > > > > "that not" -> "that are not" > > > > > > Section 6.2: > > > > > > 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. > > > > > > 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. > > > > > > Section 11: Congestion Control > > > > > > This section is mis-named, as it basically (correctly) says that ther= e > > > is nothing useful that can be done in G.711.0 compression to respond > > > to congestion. I would retitle this to "Congestion Considerations". > > > > > > 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. > > > > > > idnits 2.13.01 didn't find anything to complain about ;-). > > > > > > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > > > > > 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. > > > > > > A.1.3. Has the migration path been discussed? > > > > > > No, see major issue [D] above. > > > > > > A.1.4 Have the Requirements on other protocols and functional > > > components been discussed? > > > > > > Only in part - major issues [C] and [D] call out shortcomings in the > > > discussion of SDP interactions. > > > > > > A.1.8 Are there fault or threshold conditions that should be report= ed? > > > > > > 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]. > > > > > > A.2. Management Considerations > > > > > > I would expect that the media type registration (Section 5.1 of this > > > draft) 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. > > > > > > A.3 Documentation > > > > > > By itself, this compressed payload format does not look like a likely > > > source of significant operational impacts on the Internet. > > > > > > The shepherd's writeup indicates that an implementation exists. > > > > > > 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) 2= 93-7786 > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload From nobody Sun Mar 22 18:20:34 2015 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 49E331A8730 for ; Sun, 22 Mar 2015 18:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 nknJCqzkX90Y for ; Sun, 22 Mar 2015 18:20:32 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39771A8732 for ; Sun, 22 Mar 2015 18:20:31 -0700 (PDT) Received: by wgdm6 with SMTP id m6so134077241wgd.2 for ; Sun, 22 Mar 2015 18:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=3I6uM4+R977olQRGJzeXbTQ83C/yWNTs8hHVNjDfjrc=; b=plsDc1C1fK/B1dQKrkr3QjcMfQEyZUUJ26VQe3zn1fByqU9xxhywJx61jmTU00TQol lf5GhY8guRa3RgxYDRGsxHs0okW5yv2HUOOgYzNXRMhryyEpGM1nKj2oVcaRR1GjIkez ZX9GjAxN7YwPTW2plhitIKjOewKTbDHNlvYNtxgXScEwHGmYfDwqpt3PAfkOQViRViQA mcO+Tnj/rIHG7RFYKDpxdGwOveyJ9pFqjM7akHH2JEeU16I4NkqYh+8I8qyylddLYJG1 l27AKV9zkePybf08MwnzSzQ++g8XbFCUhvrYy2UyKUo7xAWaivpu5k8Mb0Q2nZQtB1pL kLpQ== X-Received: by 10.180.216.38 with SMTP id on6mr15064874wic.15.1427073630517; Sun, 22 Mar 2015 18:20:30 -0700 (PDT) Received: from RoniE ([2001:67c:370:136:cdb9:c062:2f17:371a]) by mx.google.com with ESMTPSA id a6sm8805159wiy.17.2015.03.22.18.20.28 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Mar 2015 18:20:29 -0700 (PDT) From: "Roni Even" To: Date: Mon, 23 Mar 2015 03:20:26 +0200 Message-ID: <00f001d06507$8cf46df0$a6dd49d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F1_01D06518.507D8C10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBlB3+AlysnfwhFQ1miDJtECRheWg== Content-Language: en-us Archived-At: Cc: 'Jonathan Lennox' , Singh Varun Subject: [payload] Presentations for PAYLOAD session in Dallas 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, 23 Mar 2015 01:20:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F1_01D06518.507D8C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi guys, The Payload WG will meet on Wednesday, please send presentations by Tuesday evening so we can upload them before the session Thanks Roni Even ------=_NextPart_000_00F1_01D06518.507D8C10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = guys,

The Payload WG will meet on = Wednesday, please send presentations by Tuesday evening so we can upload = them before the session

Thanks

Roni = Even

 

------=_NextPart_000_00F1_01D06518.507D8C10-- From nobody Mon Mar 23 13:10:23 2015 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 DDD1C1B29B8; Mon, 23 Mar 2015 13:10:20 -0700 (PDT) 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 wwNzAZ_FdMeT; Mon, 23 Mar 2015 13:10:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FA21A03E1; Mon, 23 Mar 2015 13:10:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323201019.11216.30867.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 13:10:19 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-15.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, 23 Mar 2015 20:10:21 -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 VP8 Video Authors : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-15.txt Pages : 25 Date : 2015-03-23 Abstract: This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-vp8-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-15 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 Mar 23 13:14:35 2015 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 9A3C71B29AC for ; Mon, 23 Mar 2015 13:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 308-Kj5C1Xx4 for ; Mon, 23 Mar 2015 13:14:32 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187D71AD49B for ; Mon, 23 Mar 2015 13:14:32 -0700 (PDT) Received: by iedm5 with SMTP id m5so45125856ied.3 for ; Mon, 23 Mar 2015 13:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R6tcouC420ZlQ6r63D00YnU7XGuLbjtE33f7+grBboA=; b=UlS/dpM9jLRoXwHRTtkKvSzIrKtN+hx0P6U0+dGfG33awqgeCXYPdQUXRB0olX21Fj kkci3EBnRfT4pCsSSDwRkFL33pyBP2pVbL/bKGifcPkNwd9opQeE8irynYgM44XVjsg3 OsHvn7VAx7QgLF1bEzHknOuSRr4ZCrJpBvnh81x1veaGx+YZJ/vPJebaBbkUu/hGlSeJ HkMoIuia6A/i1/cgZiY0XrL9DdFuWtHcWJE9XMSjURMxR+DNlOCvcY4H5N0Iq4gngDNW jcnWjp9ONYA/ZzkrMVc1scC8Gk2PeUx4H2CAYDiXsOkgaR/QJ7AaoI66Q/PIspDxFLcy kt6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R6tcouC420ZlQ6r63D00YnU7XGuLbjtE33f7+grBboA=; b=dEAh6D54Id9ZbPuElg1fSH/dCL1nhMY3CSZ+18tUI4OAojx2/aXh91g8u0oICC412c P2f3MgrQE4/Iac0F9dNFe6jn0oXUJv4B9CJMR8Ywh2pYo/We3Bp47I3EtlZx8NXeFcqM vnGJwexn7PNtNSsZ4u5rlySSnOHdE3F7s2ZWrWooRjkDp1i9qGeU63KmASliw5F6/WDy gaPpx11MA367e74ay0W1zrnCV69BKkpTy4umDNhUA7uFMQXcs9ZaJ50Y+ps84nKDbCiS naf/TfErSaFsBeWU8vypEZTmsnRlgGR949o33XOnlcfaDqoikrUu6BeVof7rX0H6PJWm 8OKA== X-Gm-Message-State: ALoCoQm8OijP2BYgUIIQ6qHqNIBnA2oC+NW9zUaQo/B8gmY94tTZrVnqORznUjbFtvbmqwcwNUPi MIME-Version: 1.0 X-Received: by 10.50.107.7 with SMTP id gy7mr17039445igb.49.1427141671464; Mon, 23 Mar 2015 13:14:31 -0700 (PDT) Received: by 10.64.149.7 with HTTP; Mon, 23 Mar 2015 13:14:31 -0700 (PDT) In-Reply-To: <624F9FD9-A4E0-4191-B9BD-67A9BFA21169@iii.ca> References: <20150303205231.10208.20421.idtracker@ietfa.amsl.com> <624F9FD9-A4E0-4191-B9BD-67A9BFA21169@iii.ca> Date: Mon, 23 Mar 2015 21:14:31 +0100 Message-ID: From: Henrik Lundin To: Cullen Jennings Content-Type: multipart/alternative; boundary=e89a8ffbae415f55300511fa50dd Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] Comment on draft-ietf-payload-vp8-14.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, 23 Mar 2015 20:14:33 -0000 --e89a8ffbae415f55300511fa50dd Content-Type: text/plain; charset=UTF-8 Done in https://tools.ietf.org/html/draft-ietf-payload-vp8-15. Thanks! /Henrik On Thu, Mar 19, 2015 at 10:34 PM, Cullen Jennings wrote: > > One small thing ... the References need to be sorted into Normative and > Informative. > > > > On Mar 3, 2015, at 1:52 PM, internet-drafts@ietf.org wrote: > > > > > > 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 VP8 Video > > Authors : Patrik Westin > > Henrik F Lundin > > Michael Glover > > Justin Uberti > > Frank Galligan > > Filename : draft-ietf-payload-vp8-14.txt > > Pages : 25 > > Date : 2015-03-03 > > > > Abstract: > > This memo describes an RTP payload format for the VP8 video codec. > > The payload format has wide applicability, as it supports > > applications from low bit-rate peer-to-peer usage, to high bit-rate > > video conferences. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-payload-vp8-14 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-14 > > > > > > 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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --e89a8ffbae415f55300511fa50dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Done in=C2=A0https://tools.ietf.org/html/draft-ietf-payload-vp8-15<= /a>.

Thanks!
/Henrik


On Thu, Mar 19, 2015 at 10:= 34 PM, Cullen Jennings <fluffy@iii.ca> wrote:

One small thing ... the References need to be sorted into Normative and Inf= ormative.


> On Mar 3, 2015, at 1:52 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: RTP Payload Format for VP8 Video
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Patrik Westin
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Henrik F Lundin
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Michael Glover
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Justin Uberti
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Frank Galligan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-payload-vp8-14.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 25
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-03-03
>
> Abstract:
>=C2=A0 =C2=A0This memo describes an RTP payload format for the VP8 vide= o codec.
>=C2=A0 =C2=A0The payload format has wide applicability, as it supports<= br> >=C2=A0 =C2=A0applications from low bit-rate peer-to-peer usage, to high= bit-rate
>=C2=A0 =C2=A0video conferences.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ie= tf-payload-vp8/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-payload= -vp8-14
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddr= aft-ietf-payload-vp8-14
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce= @ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-anno= unce
> Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

_______________________________________________
payload mailing list
payload@ietf.org https://www.ietf.org/mailman/listinfo/payload



--
Henrik Lundin=C2=A0|=C2=A0WebRTC Software Eng=C2=A0|=C2=A0hlundin@google.com=C2= =A0|=C2=A0+46 70 646 13= 41

--e89a8ffbae415f55300511fa50dd-- From nobody Mon Mar 23 13:56:28 2015 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 9FBD51AD481 for ; Mon, 23 Mar 2015 13:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, 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 8Sx4Wz93vTur for ; Mon, 23 Mar 2015 13:56:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC201A1A92 for ; Mon, 23 Mar 2015 13:56:23 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-56-55107df5d9c5 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BA.0E.01716.5FD70155; Mon, 23 Mar 2015 21:56:21 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.210.2; Mon, 23 Mar 2015 21:56:20 +0100 Message-ID: <55107DEE.1090908@ericsson.com> Date: Mon, 23 Mar 2015 15:56:14 -0500 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "payload@ietf.org" , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgluLIzCtJLcpLzFFi42KZGfG3RvdrrUCowd6nGhbft19mtbh08SyT A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJVx9uoqpoLvsRVN184wNzBu9exi5OSQEDCR mDn7JCOELSZx4d56ti5GLg4hgSOMEj/OvmSGcJYzSnT/W8cOUsUroC2xb8UMMJtFQFVi6sMW sG42AQuJmz8a2UBsUYFgiZ/tu5kg6gUlTs58wgJiiwikSLQtbmUGsYUF7CT+r7oGZHNwMAto SqzfpQ8SZhaQl2jeOhusRAhoVUNTB+sERr5ZSCbNQuiYhaRjASPzKkbR4tTi4tx0I2O91KLM 5OLi/Dy9vNSSTYzAIDu45bfuDsbVrx0PMQpwMCrx8G5o5A8VYk0sK67MPcQozcGiJM5rZ3wo REggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj5byqExuvXLjIO5Pj1qOntY/NGs4eOnOmUt9J zKj5bfKJrWa7fD4lOq5w7Ne9/vEqb+xan7UzzAv7Fqxfw7h9f8y7womKno+i/sg0fV+pGfQ1 2j+UqW/tgbJMticxlg8P7XR57ZjitrV0wfMZp9rMD79UD8xVMbJOrlzrfkN/V2rul+PBirsn KLEUZyQaajEXFScCANZtfqUTAgAA Archived-At: Subject: [payload] Comments on draft-ietf-payload-flexible-fec-scheme-00 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, 23 Mar 2015 20:56:27 -0000 Hi, I have reviewed this draft and have some comments. 1. Associating the repair flow with the source flow. This FEC scheme has a one to one correspondence between source and repair flows. Further the repair flow might be in the same RTP session or in a separate RTP session with the source flow. For both these cases one need to correctly associate them. This draft fails to properly address how this association is accomplished. So what I find in associating the flows are the following: o Synchronization Source (SSRC): The SSRC value SHALL be randomly assigned as suggested by [RFC3550]. This allows the sender to multiplex the source and repair flows on the same port, or multiplex multiple repair flows on a single port. The repair flows SHOULD use the RTCP CNAME field to associate themselves with the source flow. Using the same CNAME for the source and repair flow looks right, especially for repair flows originating on the same endpoint. Using it on separate hosts has some issues with providing relevant SR packets when it comes to the clock. This do matter as the RTP TS relation to the senders NTP timestamp value is relevant when judging the block timestamps. However, the point I really like to make is that one can't use CNAME to map a repair flow to the source flow. As an endpoint is quite likely to have multiple source flows in the same RTP sessions. Thus, the other mechanism that is used to associate the repair and source flow is the SDP grouping framework using the FEC-FR semantics. However, are we really going to sole rely on this mechanism? To me that is the wrong choice as it makes it difficult for usages where flows are dynamically generated and not pre-signalled in all cases. I understand that this might not be the focus for those who like to use this for WebRTC, as there the flows needs to be pre-signalled in all cases. But, there are other usages, especially in broadcasting and multicast where requiring to know the SSRCs and bind them together in signalling messages are impractical. I note that the previous XOR based FEC has had at least a working solution for this when using different RTP sessions, as they required to use same SSRC for the repair and source flow. Thus allowing association that way. I don't think this scheme should rely on this mechanism, instead look at how this otherwise can be accomplished so that it works both within a single session and between different sessions. One possibility could be to actually include the source flow SSRC in the FEC header. Another one is to rely on some source stream identifier that could be sent as SDES information. I note that MID is not usable as that represent a Media Description i.e. a media source, not a particular RTP Stream. 2. Abstract: Due to these changes, the new payload formats are not backward compatible with the earlier specifications, but endpoints that do not implement the scheme can still work by simply ignoring the FEC packets. I suggest to change "still work" to "still use the source packets". 3. Please consider to use RTP grouping taxonomy, source RTP stream and redundancy RTP stream. 4. Section 1: I think the introduction needs to be clear that this scheme is one to one between source and repair streams. 5. Section 1: I am missing a discussion of what the short comings where in these protocols mentioned in the abstract. Simply so that one can consider if this resolves these issues. 6. Section 4.2: It MUST be one higher than the sequence number in the previously transmitted repair packet. I am not particular happy about text that actually normatively restate the rules in RTP. I think a reference to what the behaviour is, rather than risking to redefine things. 7. Section 4.2: The timestamp for the repair flow should be recommended. This should be at least 1k Hz clock to get reasonable resolution in the RTCP handling. 8. Section 4.2: A common CNAME may be produced based on an algorithm that is known both to the RTP and FEC Source [RFC7022]. This usage is compliant with [RFC3550]. I really wonder if these sentences are needed at all. Isn't the point that if the repair stream generator is going to use the same CNAME, then it needs to use the same, but that does not need to be generated by the second entity, it can simply be copied from RTCP or signalling. Thus, I think this looks strange to mention here. 9. Section 4.2: If M=0, N=0, regular protection pattern code with the values of L and D are indicared in the SDP description. I don't quite understand why this included. For consistency, is it not simply better to always indicate the actual used values, rather than risking to have inconsistencies between sender and receiver about what was signalled. 10. Section 5: I don't understand why there needed to be two sets of media types for this. I fail to see the difference between the two media types, especially as both have a parameter: o ToP: Type of the protection applied by the sender: 0 for 1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC protection, and 2 for 2-D parity FEC protection. The ToP value of 3 is reserved for future uses. This parameter is the same for both media types. Thus, why not a single type and signal the configuration? Especially as you can indicate for non-interleaved you can configure it as interleaved one. 11. Section 5.1.1: Provisional registration? (standards tree only): Yes. I wonder about this. Is this provisional registered already? I find nothing at IANA. Is the plan to register them provisional? 12. Section 5.2.1: How is the repair-window parameter going to deal with codecs with variable rate or discontinuous transmission? When I worked with interleaving before, we have specified a time-window or other mechanisms rather than fixed packet or data amounts because they are problematic for anything not being constant bit-rate. So I think we needs to rethink how the interleaving can know when a block is complete. 13. Section 5.2.1: Any unknown option in the offer MUST be ignored and deleted from the answer. I think option/parameter 14. Section 5.2.1: I think this section needs to discuss the directionality. Is it the sender or the receiver that does configure the D and L values? How does that interact with the directionality attributes? 15. Section 5.2.2: o The payload format configuration parameters are all declarative and a participant MUST use the configuration that is provided for the session. Does that apply to the endpoint sending or receiving traffic? Also here there need to be directionality discussion. 16. Section 6.2: Due to this possible padding and mandatory FEC header, a repair packet has a larger size than the source packets it protects. This may cause problems if the resulting repair packet size exceeds the Maximum Transmission Unit (MTU) size of the path over which the repair flow is sent. I think this needs to be expanded. - Some more direct considerations for how much space is needed. - The fact that the repair packet will be longest of the input packets. I also think this could be moved into its own Section to make it clear that it is important. 17. Section 6.2: o Unsigned network-ordered 16-bit representation of the source packet length in bytes minus 12 (for the fixed RTP header), i.e., the sum of the lengths of all the following if present: the CSRC list, extension header, RTP payload and RTP padding (16 bits). Just a note, this precludes IP Jumbograms, but I think that is all fine. But, I think you can note the restriction that this will not support packets longer than 64K - repair stream overhead. 18. Section 6.2: o The next 16 bits are skipped. Please include the reason why they are skipped. 19. Section 6.2: The repair packet payload consists of the bits that are generated by applying the XOR operation on the payloads of the source RTP packets. SRTP do allow FEC to be applied on SRTP packet, in that case the next bits are not only the RTP payload, but also the SRTP fields. 20. Section 6.2: The repair packet payload consists of the bits that are generated by applying the XOR operation on the payloads of the source RTP packets. What about the CSRC list and the RTP header extension. That needs to be covered. 21. Section 6.3.1.3: When N = 0: p*_snb, p*_snb+1,..., p*_snb+(M-1), p*_snb+M When N > 0: p*_snb, p*_snb+(Mx1), p*_snb+(Mx2),..., p*_snb+(Mx(N-1)), p*_snb+(MxN) If I understand this correctly, then N=0 and N=1 is actually the same. Isn't actually non-interleaved N=1. Maybe easier to rewrite it that way. 22. Section 6.3.3: 4. Calculate the recovered bit string as the XOR of the bit strings generated from all source packets in T and the FEC bit string generated from the repair packet in T. "all source packets in T", I think this need to say: "all source packets available in T" 23. Section 7.2: I think this section should discuss why it uses two RTP streams, rather than just one. From a basic use case this could be done with one RTP stream for the repair packets. Even one single PT is that sets ToP to 2 and uses the mask. As each packet will be self indicating if it is a row or column it protects. 24. Section 9: The FEC order and SRTP may need a explicit pointer. 25. Section 9. XOR FEC is not without computational complexities. Thus, are there considerations for DoS the endpoint with Repair packets causing it to process a lot? 26. Section 9: Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, transport and signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable, using the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. Other mechanisms that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may exist. I think you should consider to use the text from the HOWTO instead of your own: RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] , and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses it is not an RTP payload formats responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in Options for Securing RTP Sessions [RFC7201]. The rest of the this security consideration discusses the security impacting properties of the payload format itself. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Mar 24 21:24:08 2015 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 918191ACD94 for ; Tue, 24 Mar 2015 21:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Bjn6FQwvlPtq for ; Tue, 24 Mar 2015 21:24:05 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178881ACD91 for ; Tue, 24 Mar 2015 21:24:05 -0700 (PDT) Received: by wixw10 with SMTP id w10so20806513wix.0 for ; Tue, 24 Mar 2015 21:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=XEsdaoCBaQoi+CNMlvV1DYtHnC0iHhqRlcClqOhPhNc=; b=Ekr0RsJUE6P0C3yvc3s/Kggd1hmMG56mq38amMSDzsPiFJL3noNPmowMOESc4/Ibja v/LicTH9yT+zGm9uN8+1yw1GZtikMUnw23hB3aWRJdhF+mU7PzWT2bnjZDpUTq6Q5gGB LeIa0yRbRE4cAp/2QZCx0JbMlqbyaEZKjeIwPwRdNV9Qt+HRX8ihJJ6ePBDm42aEhbYz KRsCR6UqCwTpmC2S42lZa2QqX0tigdytYF98t/pTt3u7qAfoZ9DF7lKPkoooT5kc9utM Rlrfuu6qyEqyOYNU2ToQaA1NGTKbiNEZ9TUyjm3e5gjtGSUt/Hj1nKVy6lrFEVls3SvJ FpiA== X-Received: by 10.194.2.43 with SMTP id 11mr14158330wjr.104.1427257443840; Tue, 24 Mar 2015 21:24:03 -0700 (PDT) Received: from RoniE ([2001:67c:370:136:f83e:db75:b566:696a]) by mx.google.com with ESMTPSA id n6sm1747492wjy.8.2015.03.24.21.24.01 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Mar 2015 21:24:03 -0700 (PDT) From: "Roni Even" To: Date: Wed, 25 Mar 2015 06:23:58 +0200 Message-ID: <00d901d066b3$859e0810$90da1830$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DA_01D066C4.49279B60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBmsWgRKdSfQ2i5QzWwMyEYVVAcvQ== Content-Language: en-us Archived-At: Subject: [payload] comments on draft-demjanenko-payload-melpe-02 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, 25 Mar 2015 04:24:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DA_01D066C4.49279B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I looked at the document and have some comments 1. The term MIME type is not used for RTP payload but we call it media subtype name , the media type is audio in your case 2. The term rate should probably be used for the clock rate and for what you call "rate" maybe use "bitrate" 3. I am not sure what is the meaning of rate=600,1200,2400 in the offer, is that the sender capability to switch dynamically between these three rates? 4. Are both sides need to use the same rate option (symmetric)? 5. What is the meaning of an answer rate=600,1200 to the above offer? Does it mean that both sides can switch only between 600 and 1200. 6. We prefer not to have the rate in the media subtype name so use only MELP and MELPE and for fixed rate use the rate parameter. 7. An RTP payload document must also have a congestion control section. You can look at https://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13 about how to write an RTP payload specification and also look at one of the latest RTP audio payloads like opus (https://tools.ietf.org/html/draft-ietf-payload-rtp-opus-08) for an example about the structure of an audio RTP payload and how to have the congestion control, security, IANA and SDP consideration sections Thanks Roni Even as individual ------=_NextPart_000_00DA_01D066C4.49279B60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I looked at the = document and have some comments

1.       = The term MIME type is not = used for RTP payload but we call it media subtype name , the media type = is audio in your case

2.       = The term rate should = probably be used for the clock rate and for what you call = “rate” maybe use “bitrate”

3.       = I am not sure what is the = meaning of rate=3D600,1200,2400 in the offer, is that the sender = capability to switch dynamically between these three = rates?

4.       = Are both sides need to = use the same rate option (symmetric)?

5.       = What is the meaning of an = answer rate=3D600,1200 to the above offer? Does it mean that both sides = can switch only between 600 and 1200.

6.       = We prefer not to have the = rate in the media subtype name so use only MELP and MELPE and for fixed = rate use the rate parameter.

7.       = An RTP payload document = must also have a congestion control section. You can look at http= s://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13 about how to = write an RTP payload specification and also look at one of the latest = RTP audio payloads like opus (https= ://tools.ietf.org/html/draft-ietf-payload-rtp-opus-08) for an = example about the structure of an audio RTP payload and how to have the = congestion control, security, IANA and SDP consideration = sections

 

Thanks

Roni Even as = individual

------=_NextPart_000_00DA_01D066C4.49279B60-- From nobody Wed Mar 25 05:49:58 2015 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 493C41A88F7 for ; Wed, 25 Mar 2015 05:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 HZEBlNkFmlcI for ; Wed, 25 Mar 2015 05:49:52 -0700 (PDT) Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) (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 B68581A897E for ; Wed, 25 Mar 2015 05:49:52 -0700 (PDT) Received: from dev1PC (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id C3777B40DE7; Wed, 25 Mar 2015 08:49:51 -0400 (EDT) From: "Victor Demjanenko, Ph.D." To: "'Roni Even'" , References: <00d901d066b3$859e0810$90da1830$@gmail.com> In-Reply-To: <00d901d066b3$859e0810$90da1830$@gmail.com> Date: Wed, 25 Mar 2015 08:49:15 -0400 Message-ID: <049301d066fa$1a8b2c50$4fa184f0$@Demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0494_01D066D8.93798C50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdBmsWgRKdSfQ2i5QzWwMyEYVVAcvQARdRsw Content-Language: en-us Archived-At: Subject: Re: [payload] comments on draft-demjanenko-payload-melpe-02 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, 25 Mar 2015 12:49:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0494_01D066D8.93798C50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Roni, Thanks for the comments/questions. I will answer them below with "v->" prefix. Regards, Victor From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, March 25, 2015 12:24 AM To: payload@ietf.org Subject: [payload] comments on draft-demjanenko-payload-melpe-02 Hi, I looked at the document and have some comments 1. The term MIME type is not used for RTP payload but we call it media subtype name , the media type is audio in your case v-> Unfortunately I am not (well) versed in what all the "MIME" language means. I had used a iLBC payload draft from a couple of years ago as my model. So what should I be changing? Should I look at the language used in the OPUS draft? 2. The term rate should probably be used for the clock rate and for what you call "rate" maybe use "bitrate" v-> Agreed. I did not know the best term to use. 3. I am not sure what is the meaning of rate=600,1200,2400 in the offer, is that the sender capability to switch dynamically between these three rates? v-> The offerer can send in all three rates and prefers to use 600. The next preference is for 1200. 4. Are both sides need to use the same rate option (symmetric)? v-> Yes. You are correct that we do not explicitly state this. 5. What is the meaning of an answer rate=600,1200 to the above offer? Does it mean that both sides can switch only between 600 and 1200. v-> Yes. And it means they will start at 600. 6. We prefer not to have the rate in the media subtype name so use only MELP and MELPE and for fixed rate use the rate parameter. v-> This was done for compatibility reasons. MELP2400, MELP1200 and MELP600 are used in systems that have already been deployed. 7. An RTP payload document must also have a congestion control section. You can look at https://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13 about how to write an RTP payload specification and also look at one of the latest RTP audio payloads like opus (https://tools.ietf.org/html/draft-ietf-payload-rtp-opus-08) for an example about the structure of an audio RTP payload and how to have the congestion control, security, IANA and SDP consideration sections v-> Thanks. I have looked at one of these howto documents already. I will refresh to these references as per your suggestion. Thanks Roni Even as individual ------=_NextPart_000_0494_01D066D8.93798C50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

Thanks for the = comments/questions.  I will answer them below with = “v->” prefix.

 

Regards,

 

Victor

 

From:= = payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni = Even
Sent: Wednesday, March 25, 2015 12:24 AM
To: = payload@ietf.org
Subject: [payload] comments on = draft-demjanenko-payload-melpe-02

 

Hi,

I looked at the = document and have some comments

1.       The = term MIME type is not used for RTP payload but we call it media subtype = name , the media type is audio in your case

v-> Unfortunately I = am not (well) versed in what all the “MIME” language = means.  I had used a iLBC payload draft from a couple of years ago = as my model.  So what should I be changing?  Should I look at = the language used in the OPUS draft?

2.       The = term rate should probably be used for the clock rate and for what you = call “rate” maybe use “bitrate”

v-> Agreed.  I = did not know the best term to use.

3.       I = am not sure what is the meaning of rate=3D600,1200,2400 in the offer, is = that the sender capability to switch dynamically between these three = rates?

v-> The offerer can send in all three rates = and prefers to use 600.  The next preference is for = 1200.

4.       Are = both sides need to use the same rate option = (symmetric)?

v-> Yes.  You are correct that we do not = explicitly state this.

5.       = What is the meaning of an answer rate=3D600,1200 = to the above offer? Does it mean that both sides can switch only between = 600 and 1200.

v-> Yes.  And it means they will start = at 600.

6.       We = prefer not to have the rate in the media subtype name so use only MELP = and MELPE and for fixed rate use the rate parameter.

v-> This was done for = compatibility reasons.  MELP2400, MELP1200 and MELP600 are used in = systems that have already been deployed. 

7.       An = RTP payload document must also have a congestion control section. You = can look at http= s://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13 about how to = write an RTP payload specification and also look at one of the latest = RTP audio payloads like opus (https= ://tools.ietf.org/html/draft-ietf-payload-rtp-opus-08) for an = example about the structure of an audio RTP payload and how to have the = congestion control, security, IANA and SDP consideration = sections

v-> Thanks.  I have looked at one of = these howto documents already.  I will refresh to these references = as per your suggestion.

 

Thanks

Roni Even as = individual

------=_NextPart_000_0494_01D066D8.93798C50-- From nobody Wed Mar 25 12:14:32 2015 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 286561B2B58; Wed, 25 Mar 2015 12:14:30 -0700 (PDT) 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 90B2d3DgxiYT; Wed, 25 Mar 2015 12:14:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2A31B2B54; Wed, 25 Mar 2015 12:14:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150325191425.7260.63626.idtracker@ietfa.amsl.com> Date: Wed, 25 Mar 2015 12:14:25 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-g7110-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: Wed, 25 Mar 2015 19:14:30 -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-05.txt Pages : 30 Date : 2015-03-25 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-g7110-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 Thu Mar 26 07:35:31 2015 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 60EB41A00DC for ; Thu, 26 Mar 2015 07:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 MKzt5z3jax5v for ; Thu, 26 Mar 2015 07:35:25 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4FA1A1A90 for ; Thu, 26 Mar 2015 07:34:53 -0700 (PDT) Received: by wgra20 with SMTP id a20so66280992wgr.3 for ; Thu, 26 Mar 2015 07:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=06J7w6wGSj4oUVwBhBoqlZNgEUGpxzCY5xNBOSBL0+k=; b=uNnlNLXp8rglZJAkx0uw82BGK7pp5CTSya+20aVrvFKm4LKP9BYhsIooeHvj0wwQG5 Wgag6hr0CzIVf2Xp9QzosDi0jxY8IakBzSD2jBGY/6f2XMUhSIZOV6sWtUigkginRh2b 5PYXj25vXIG5JfQyRUYAhI/Wvp6qt9KETvgQTSXqFebBBLwm/ggCj2P5KmLRlWR8Vsze p8TwXGL0ELt9ykBC/aTUd2G7fPr6WY5NjPtP1QnqbtLh+mNkrFxG1ZUUp4jOC1a7q2Aj 48wh2+BTdit9C1QouDrIvM5qQcAgL+VD/njlkZ3GtLU9wYjXFonDT9cMmVz+ufFoMGgU V8gw== X-Received: by 10.194.5.37 with SMTP id p5mr29282761wjp.20.1427380491731; Thu, 26 Mar 2015 07:34:51 -0700 (PDT) Received: from RoniE ([2001:67c:370:136:f4be:a22f:60cf:9b4a]) by mx.google.com with ESMTPSA id jy7sm25594859wid.22.2015.03.26.07.34.50 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Mar 2015 07:34:51 -0700 (PDT) From: "Roni Even" To: Date: Thu, 26 Mar 2015 16:34:47 +0200 Message-ID: <006401d067d2$03e9a020$0bbce060$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01D067E2.C772E550" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBn0VdCSd4CtnbKQu6ud8O5wb1kwA== Content-Language: en-us Archived-At: Subject: [payload] call for adoption of RTP Payload for SMPTE ST 291 Ancillary Data 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, 26 Mar 2015 14:35:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0065_01D067E2.C772E550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, At the IETF92 session there was support to work on RTP Payload for SMPTE ST 291 Ancillary Data. The WG chairs would like to confirm it on the mailing list. We would like to create a new milestone for this topic and adopt daft-edwards-payload-rtp-ancillary-01 as the initial document for the new milestone Please provide feedback on both topics (milestone and document adoption) on the mailing list till April 10th 2015 Thanks Roni Even Payload WG co-chair ------=_NextPart_000_0065_01D067E2.C772E550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

At the IETF92 = session there was support to work on RTP = Payload for SMPTE ST 291 Ancillary Data. The WG chairs would like to = confirm it on the mailing list.

We would like to create a = new milestone for this topic and adopt daft-edwards-payload-rtp-ancillary-01 as the initial = document for the new milestone

 

Please = provide feedback on both topics (milestone and document adoption) on the = mailing list till April 10th 2015

 

Thanks

Roni = Even

Payload WG co-chair

 

------=_NextPart_000_0065_01D067E2.C772E550-- From nobody Thu Mar 26 07:37:47 2015 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 B11C11A0007 for ; Thu, 26 Mar 2015 07:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, 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 g6lfIChVGSBy for ; Thu, 26 Mar 2015 07:37:34 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099C21A0110 for ; Thu, 26 Mar 2015 07:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7224; q=dns/txt; s=iport; t=1427380648; x=1428590248; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=SV+ZK8zXfTHEK4/q4pMQbbgyeF9sGGzWwyMd6rPBQsA=; b=Img9KN+Vq+3vwdP3VG4QGHU41S9AxTeCOwhQc6Jd++3GQC6tjwbbFLHw wf8LG/YXirnt+srKv42OKJGRZiGC0PRIK5IKMxC/J+Dg35QvZty+3oOJc C08sQ9L5M+tHUrySl7dw1Mq1hSlrEqq2uJ9N+XzaqzGuroWtkiOf7WPIY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQBgGRRV/5hdJa1cgkNDUloEgw7CHIV1AhyBO0wBAQEBAQF9hBQBAQEEHQYKQRsCAQgOAwMBAigDAgICMBQJCAIEARKILw2wZpoqAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLKIE9gyoNC4JoL4EWBZBQg2+GAIEbgzCPYiKCD4FfbwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.11,472,1422921600"; d="scan'208,217";a="406833189" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 26 Mar 2015 14:37:27 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t2QEbR6K017080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 14:37:27 GMT Received: from xmb-aln-x01.cisco.com ([169.254.2.35]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 09:37:27 -0500 From: "Ali C. Begen (abegen)" To: Roni Even , "payload@ietf.org" Thread-Topic: [payload] call for adoption of RTP Payload for SMPTE ST 291 Ancillary Data Thread-Index: AQHQZ9Jh6lAH/95GmEy3zRhcX60g2Q== Date: Thu, 26 Mar 2015 14:37:26 +0000 Message-ID: References: <006401d067d2$03e9a020$0bbce060$@gmail.com> In-Reply-To: <006401d067d2$03e9a020$0bbce060$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.1.150311 x-originating-ip: [10.89.12.113] Content-Type: multipart/alternative; boundary="_000_B905F4A7FAA64027B4FB986A525601A1ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [payload] call for adoption of RTP Payload for SMPTE ST 291 Ancillary Data 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, 26 Mar 2015 14:37:44 -0000 --_000_B905F4A7FAA64027B4FB986A525601A1ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRoaXMgZHJhZnQgdG8gYmUgYWRvcHRlZCBhbmQgYWRkZWQgdG8gdGhlIGNoYXJ0 ZXIuDQoNCi1hY2JlZ2VuLCBpbmRpdmlkdWFsbHkNCg0KRnJvbTogUm9uaSBFdmVuDQpEYXRlOiBU aHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgYXQgOTozNCBBTQ0KVG86ICJwYXlsb2FkQGlldGYub3Jn PG1haWx0bzpwYXlsb2FkQGlldGYub3JnPiINClN1YmplY3Q6IFtwYXlsb2FkXSBjYWxsIGZvciBh ZG9wdGlvbiBvZiBSVFAgUGF5bG9hZCBmb3IgU01QVEUgU1QgMjkxIEFuY2lsbGFyeSBEYXRhDQoN CkhpLA0KQXQgdGhlIElFVEY5MiBzZXNzaW9uIHRoZXJlIHdhcyBzdXBwb3J0IHRvIHdvcmsgb24g UlRQIFBheWxvYWQgZm9yIFNNUFRFIFNUIDI5MSBBbmNpbGxhcnkgRGF0YS4gVGhlIFdHIGNoYWly cyB3b3VsZCBsaWtlIHRvIGNvbmZpcm0gaXQgb24gdGhlIG1haWxpbmcgbGlzdC4NCldlIHdvdWxk IGxpa2UgdG8gY3JlYXRlIGEgbmV3IG1pbGVzdG9uZSBmb3IgdGhpcyB0b3BpYyBhbmQgYWRvcHQg ZGFmdC1lZHdhcmRzLXBheWxvYWQtcnRwLWFuY2lsbGFyeS0wMTxodHRwczovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LWVkd2FyZHMtcGF5bG9hZC1ydHAtYW5jaWxsYXJ5LTAxLnR4dD4gYXMgdGhl IGluaXRpYWwgZG9jdW1lbnQgZm9yIHRoZSBuZXcgbWlsZXN0b25lDQoNClBsZWFzZSBwcm92aWRl IGZlZWRiYWNrIG9uIGJvdGggdG9waWNzIChtaWxlc3RvbmUgYW5kIGRvY3VtZW50IGFkb3B0aW9u KSBvbiB0aGUgbWFpbGluZyBsaXN0IHRpbGwgQXByaWwgMTB0aCAyMDE1DQoNClRoYW5rcw0KUm9u aSBFdmVuDQpQYXlsb2FkIFdHIGNvLWNoYWlyDQoNCg== --_000_B905F4A7FAA64027B4FB986A525601A1ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4393E43566DD4C42AA68AF687E5FF081@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj5JIHN1cHBvcnQgdGhpcyBkcmFmdCB0byBiZSBhZG9wdGVkIGFuZCBhZGRlZCB0byB0aGUg Y2hhcnRlci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi1hY2JlZ2VuLCBpbmRpdmlk dWFsbHk8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJP TEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBm b250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRP TTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006 IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDog I2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9Q OiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5Sb25p IEV2ZW48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRo dXJzZGF5LCBNYXJjaCAyNiwgMjAxNSBhdCA5OjM0IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnBheWxvYWRAaWV0 Zi5vcmciPnBheWxvYWRAaWV0Zi5vcmc8L2E+JnF1b3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bcGF5bG9hZF0gY2FsbCBmb3IgYWRvcHRpb24g b2YgUlRQIFBheWxvYWQgZm9yIFNNUFRFIFNUIDI5MSBBbmNpbGxhcnkgRGF0YTxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJV VElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFE RElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3 b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEy L29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5h bWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1 bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGks PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCB0aGUgSUVURjkyIHNlc3Np b24gdGhlcmUgd2FzIHN1cHBvcnQgdG8gd29yayBvbiA8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pg0KUlRQIFBheWxvYWQgZm9yIFNNUFRFIFNUIDI5MSBBbmNpbGxhcnkgRGF0YS4gVGhlIFdHIGNo YWlycyB3b3VsZCBsaWtlIHRvIGNvbmZpcm0gaXQgb24gdGhlIG1haWxpbmcgbGlzdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPldlIHdvdWxkIGxpa2UgdG8gY3JlYXRlIGEgbmV3IG1pbGVzdG9uZSBmb3IgdGhpcyB0 b3BpYyBhbmQgYWRvcHQNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt ZWR3YXJkcy1wYXlsb2FkLXJ0cC1hbmNpbGxhcnktMDEudHh0Ij5kYWZ0LWVkd2FyZHMtcGF5bG9h ZC1ydHAtYW5jaWxsYXJ5LTAxPC9hPjwvc3Bhbj4gYXMgdGhlIGluaXRpYWwgZG9jdW1lbnQgZm9y IHRoZSBuZXcgbWlsZXN0b25lPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBwcm92aWRl IGZlZWRiYWNrIG9uIGJvdGggdG9waWNzIChtaWxlc3RvbmUgYW5kIGRvY3VtZW50IGFkb3B0aW9u KSBvbiB0aGUgbWFpbGluZyBsaXN0IHRpbGwgQXByaWwgMTA8c3VwPnRoPC9zdXA+IDIwMTU8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Sb25pIEV2ZW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBh eWxvYWQgV0cgY28tY2hhaXI8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_B905F4A7FAA64027B4FB986A525601A1ciscocom_-- From nobody Thu Mar 26 10:53:50 2015 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 7FFDE1A87B9 for ; Thu, 26 Mar 2015 10:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Xu95mEeM9lUo for ; Thu, 26 Mar 2015 10:53:48 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE831A8F4E for ; Thu, 26 Mar 2015 10:53:47 -0700 (PDT) Received: by wibbg6 with SMTP id bg6so74001978wib.0 for ; Thu, 26 Mar 2015 10:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=9H+JIE/IZf6z+DHZcI4kFLPRKfLK7yCdNtJq8rED0tA=; b=iMluzRjmmdF+1w3OFZVq6AsQaZQA+YAYy8dQ47K6ar6R53oKGZ08An5ZygxP2KOlq6 oxP5NE1r1HhyVOtD5AImdE4B+TkMi5A+lkRF0teKHEn0HYK4hx4tBC/aPyO7gi2dpGWI 6OTABw9Q38Fp7KYvMWfFdmM3j9oBMxdnLlV/fwhvHHppOQn5j021UhM1QckPQ9cWOtSl PuCjH7aIl8QnTv05A69LGPm988P5GiMAUvKpPLW2z93kPcIVpo1whAkba1SoQ0eCXSmS 09fA/G291+jT71q98Zb5esk0qtMKxdRl41uM1ZO4uRFVvjGF8BvPAOhehWY5rp5fXEXv Kppw== X-Received: by 10.195.12.35 with SMTP id en3mr29183080wjd.129.1427392426642; Thu, 26 Mar 2015 10:53:46 -0700 (PDT) Received: from RoniE ([2001:67c:370:136:f4be:a22f:60cf:9b4a]) by mx.google.com with ESMTPSA id ax10sm9369085wjc.26.2015.03.26.10.53.43 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Mar 2015 10:53:46 -0700 (PDT) From: "Roni Even" To: Date: Thu, 26 Mar 2015 19:53:29 +0200 Message-ID: <010d01d067ed$cc9d8610$65d89230$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010E_01D067FE.9026CB40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBn7cR52AX3AZTXSv+SES1FWYbjWA== Content-Language: en-us Archived-At: Subject: [payload] call for adoption of RTP Payload for VP9 video 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, 26 Mar 2015 17:53:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010E_01D067FE.9026CB40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, At the IETF92 session there was support to work on RTP Payload for VP9 video. The WG chairs would like to confirm it on the mailing list. We would like to create a new milestone for this topic and adopt draft-uberti-payload-vp9-01 as the initial document for the new milestone Please provide feedback on both topics (milestone and document adoption) on the mailing list till April 10th 2015 Thanks Roni Even Payload WG co-chair ------=_NextPart_000_010E_01D067FE.9026CB40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

At the IETF92 = session there was support to work on RTP = Payload for VP9 video. The WG chairs would like to confirm it on the = mailing list.

We would like to create a new milestone for this = topic and adopt draft-u= berti-payload-vp9-01  as the initial document for the = new milestone

 

Please provide feedback on both topics (milestone and = document adoption) on the mailing list till April 10th = 2015

 

Thanks

Roni = Even

Payload WG co-chair

 

 

------=_NextPart_000_010E_01D067FE.9026CB40-- From nobody Thu Mar 26 13:45:50 2015 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 6D67E1B2F02 for ; Thu, 26 Mar 2015 13:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 mAIFS7AkQOIf for ; Thu, 26 Mar 2015 13:45:41 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2AD1B2EFD for ; Thu, 26 Mar 2015 13:45:40 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so3186740igb.1 for ; Thu, 26 Mar 2015 13:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=fKR1HepCHGX7GpxayIiT833OGyB+n6cNut+Gf6xOn/s=; b=uXa0QNa0egpnZRorainc/CSvdvmhUB9fhJ3ax5E29fJhFvgYaNnN87s/PIaGCLUJ/J Mtdf+GzsOJtO0dEsCG24WrS5iDEBGQaHAtp7nP+VLg2ZFEZgfhX8UKxfKTC0jnzr8xpA erdSOjRxvy8kuFbasqyAbsogbI4VPvRQyG1nUDir52ci/J7xxHdZRIiclmKUdELTAtvg cCJTRaHii+0UOtOwPGffGCbZryW4d9twOx+cVg+8t2Qa5ZXOc4Pu2Mk3rlRs5Qr8WzUS OiKgtjwnEIUhkwInC2DqxmVhyP4xVB/Odn8j4Ej1vlnYNFr302/dHArC5nFwTh0CMLjH 76JQ== X-Received: by 10.50.147.99 with SMTP id tj3mr39668346igb.41.1427402739549; Thu, 26 Mar 2015 13:45:39 -0700 (PDT) MIME-Version: 1.0 References: <006401d067d2$03e9a020$0bbce060$@gmail.com> In-Reply-To: From: Varun Singh Date: Thu, 26 Mar 2015 20:45:39 +0000 Message-ID: To: payload@ietf.org Content-Type: multipart/alternative; boundary=089e013d05203e2210051237197e Archived-At: Subject: Re: [payload] call for adoption of RTP Payload for SMPTE ST 291 Ancillary Data 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, 26 Mar 2015 20:45:44 -0000 --089e013d05203e2210051237197e Content-Type: text/plain; charset=UTF-8 +1. I too support the adoption of the document. -Varun. On Thu 26 Mar, 2015 09:37 Ali C. Begen (abegen) wrote: > I support this draft to be adopted and added to the charter. > > -acbegen, individually > > From: Roni Even > Date: Thursday, March 26, 2015 at 9:34 AM > To: "payload@ietf.org" > Subject: [payload] call for adoption of RTP Payload for SMPTE ST 291 > Ancillary Data > > Hi, > > At the IETF92 session there was support to work on RTP Payload for SMPTE > ST 291 Ancillary Data. The WG chairs would like to confirm it on the > mailing list. > > We would like to create a new milestone for this topic and adopt > daft-edwards-payload-rtp-ancillary-01 > as > the initial document for the new milestone > > > > Please provide feedback on both topics (milestone and document adoption) > on the mailing list till April 10th 2015 > > > > Thanks > > Roni Even > > Payload WG co-chair > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --089e013d05203e2210051237197e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1. I too support the adoption of the document.

-Varun.


On Thu 26 Mar, 2015 09:37=C2=A0Ali C. Begen = (abegen) <abegen@cisco.com> w= rote:
I support this draft to be adopted and added to the charter.

-acbegen, individually

From: Roni Even
Date: Thursday, March 26, 2015 at 9= :34 AM
To: "payload@ietf.org"
Subject: [payload] call for adoptio= n of RTP Payload for SMPTE ST 291 Ancillary Data

Hi,

At the IETF92 session there was support to work on <= span style=3D"color:black"> RTP Payload for SMPTE ST 291 Ancillary Data. The WG chairs would like to co= nfirm it on the mailing list.

We would like to create = a new milestone for this topic and adopt daft-edwards-payload-rtp-ancillary-01 as= the initial document for the new milestone

=C2=A0

Please provide feedback on both topics (milestone an= d document adoption) on the mailing list till April 10th 2015=

=C2=A0

Thanks

Roni Even

Payload WG co-chair <= /u>

=C2=A0

_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload
--089e013d05203e2210051237197e-- From nobody Thu Mar 26 16:00:29 2015 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 380EF1A1ABF for ; Thu, 26 Mar 2015 16:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, 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 f6dnHcjkTED5 for ; Thu, 26 Mar 2015 16:00:25 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9E21A1A60 for ; Thu, 26 Mar 2015 16:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6624; q=dns/txt; s=iport; t=1427410825; x=1428620425; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=XBGlDyy5FFHFCbAZVANe0m0x5S2c+TbW/2ZjLZUph6U=; b=i65V9fQiEgzSR/ek7BST08l2vYYhPmKJtBNKnnsx3NGSMrOgB4IT1OFf 2rjerifquMUIEQZkgwljTMT3RhLg+mmQudsZQ0HG0hl2xzGnD4cYrRpYx X/McGMgd9JGNPTWKWBaZBS235EApN90W3OG4kbsPSFX9YrhVEQsTyMGNN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AtBQAJjxRV/4YNJK1cgkNDUloEgwzAHy+BT4V1AhyBKTgUAQEBAQEBAXyEFAEBAQQdBgpBGwIBCA4DAwECKAMCAgIwFAkIAQEEARKILw2xRZo5AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4shhGQYgmgvgRYFjkGCDoNuhX+BGzqCdo9eIoNubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.11,475,1422921600"; d="scan'208,217";a="135698885" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 26 Mar 2015 23:00:25 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2QN0ODk029534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 23:00:24 GMT Received: from xmb-aln-x01.cisco.com ([169.254.2.35]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 18:00:24 -0500 From: "Ali C. Begen (abegen)" To: Roni Even , "payload@ietf.org" Thread-Topic: [payload] call for adoption of RTP Payload for VP9 video Thread-Index: AdBn7cR52AX3AZTXSv+SES1FWYbjWAAKt9OA Date: Thu, 26 Mar 2015 23:00:23 +0000 Message-ID: References: <010d01d067ed$cc9d8610$65d89230$@gmail.com> In-Reply-To: <010d01d067ed$cc9d8610$65d89230$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.1.150311 x-originating-ip: [10.89.12.113] Content-Type: multipart/alternative; boundary="_000_C4016A9592D9468A87FFE58B7AF1BE46ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [payload] call for adoption of RTP Payload for VP9 video 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, 26 Mar 2015 23:00:27 -0000 --_000_C4016A9592D9468A87FFE58B7AF1BE46ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3IgYWRvcHRpb24uDQoNCi1hY2JlZ2VuLCBpbmRpdmlkdWFsbHkNCg0KRnJvbTogUm9u aSBFdmVuDQpEYXRlOiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgYXQgMTI6NTMgUE0NClRvOiAi cGF5bG9hZEBpZXRmLm9yZzxtYWlsdG86cGF5bG9hZEBpZXRmLm9yZz4iDQpTdWJqZWN0OiBbcGF5 bG9hZF0gY2FsbCBmb3IgYWRvcHRpb24gb2YgUlRQIFBheWxvYWQgZm9yIFZQOSB2aWRlbw0KDQpI aSwNCkF0IHRoZSBJRVRGOTIgc2Vzc2lvbiB0aGVyZSB3YXMgc3VwcG9ydCB0byB3b3JrIG9uIFJU UCBQYXlsb2FkIGZvciBWUDkgdmlkZW8uIFRoZSBXRyBjaGFpcnMgd291bGQgbGlrZSB0byBjb25m aXJtIGl0IG9uIHRoZSBtYWlsaW5nIGxpc3QuDQpXZSB3b3VsZCBsaWtlIHRvIGNyZWF0ZSBhIG5l dyBtaWxlc3RvbmUgZm9yIHRoaXMgdG9waWMgYW5kIGFkb3B0IGRyYWZ0LXViZXJ0aS1wYXlsb2Fk LXZwOS0wMTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtdWJlcnRpLXBheWxvYWQtdnA5 LTAxLnR4dD4gYXMgdGhlIGluaXRpYWwgZG9jdW1lbnQgZm9yIHRoZSBuZXcgbWlsZXN0b25lDQoN ClBsZWFzZSBwcm92aWRlIGZlZWRiYWNrIG9uIGJvdGggdG9waWNzIChtaWxlc3RvbmUgYW5kIGRv Y3VtZW50IGFkb3B0aW9uKSBvbiB0aGUgbWFpbGluZyBsaXN0IHRpbGwgQXByaWwgMTB0aCAyMDE1 DQoNClRoYW5rcw0KUm9uaSBFdmVuDQpQYXlsb2FkIFdHIGNvLWNoYWlyDQoNCg0K --_000_C4016A9592D9468A87FFE58B7AF1BE46ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <37C01B1D0D554846A1F73D67D12ECA28@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj5JIHN1cHBvciBhZG9wdGlvbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi1h Y2JlZ2VuLCBpbmRpdmlkdWFsbHk8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19T SUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFj azsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsg UEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBp bjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5v bmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZy b206IDwvc3Bhbj5Sb25pIEV2ZW48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ RGF0ZTogPC9zcGFuPlRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSBhdCAxMjo1MyBQTTxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1h aWx0bzpwYXlsb2FkQGlldGYub3JnIj5wYXlsb2FkQGlldGYub3JnPC9hPiZxdW90Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W3BheWxvYWRdIGNh bGwgZm9yIGFkb3B0aW9uIG9mIFJUUCBQYXlsb2FkIGZvciBWUDkgdmlkZW88YnI+DQo8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJ T05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJ Tkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29y ZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9v bW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1l PSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0p Ij4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCB0aGUgSUVURjkyIHNlc3Npb24gdGhl cmUgd2FzIHN1cHBvcnQgdG8gd29yayBvbiA8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPg0KUlRQ IFBheWxvYWQgZm9yIFZQOSB2aWRlby4gVGhlIFdHIGNoYWlycyB3b3VsZCBsaWtlIHRvIGNvbmZp cm0gaXQgb24gdGhlIG1haWxpbmcgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPldlIHdvdWxkIGxpa2UgdG8g Y3JlYXRlIGEgbmV3IG1pbGVzdG9uZSBmb3IgdGhpcyB0b3BpYyBhbmQgYWRvcHQNCjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC11YmVydGktcGF5bG9hZC12cDktMDEudHh0 Ij5kcmFmdC11YmVydGktcGF5bG9hZC12cDktMDE8L2E+PC9zcGFuPiZuYnNwO2FzIHRoZSBpbml0 aWFsIGRvY3VtZW50IGZvciB0aGUgbmV3IG1pbGVzdG9uZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QbGVhc2UgcHJvdmlkZSBmZWVkYmFjayBvbiBib3RoIHRvcGljcyAobWlsZXN0b25lIGFuZCBk b2N1bWVudCBhZG9wdGlvbikgb24gdGhlIG1haWxpbmcgbGlzdCB0aWxsIEFwcmlsIDEwPHN1cD50 aDwvc3VwPiAyMDE1PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9uaSBFdmVuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5QYXlsb2FkIFdHIGNvLWNoYWlyPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_C4016A9592D9468A87FFE58B7AF1BE46ciscocom_-- From nobody Thu Mar 26 20:18:31 2015 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 C5A281A6EFE for ; Thu, 26 Mar 2015 20:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_DR=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 zPvXzPwiUTnp for ; Thu, 26 Mar 2015 20:18:27 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 762001A1BF6 for ; Thu, 26 Mar 2015 20:18:27 -0700 (PDT) Received: by pacwe9 with SMTP id we9so82321515pac.1 for ; Thu, 26 Mar 2015 20:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AIwe+HqaQexjZqZf5QhxyusEPPWEKZCCM+YhI96Pwnc=; b=H7Bjl1uF3LTLaLKItmNNIFtGIjNCcJ+aJmq2A9j25pA+ElcalnXuzhVpU9aYEkZYAL dX98HSI9a6zrgLVjzbKSzy/Ff5svigJkibU5MUTj/UVAta+dTfwRucqpYXya0blysfch 2DRylIiTG6wMJZ/WCIU5QYVTutWdQdSScOnm5byqtvir7xJ70h7gOJIdmHTQMYQme2Vj k4o5pmuLp/1ippq1xdiqTBSGVgbBLgEo4XedfhCoITY/bphiGrqeL8xz3Vua4zsa4HwU RLthrS8RhREc3r4xzkeetLVY10U1CnEdOpDmF+Fux/TQZvKbBEcGVAQxqUsBqBrh70JP C2OA== X-Received: by 10.70.15.161 with SMTP id y1mr32203153pdc.9.1427426307131; Thu, 26 Mar 2015 20:18:27 -0700 (PDT) Received: from [10.160.208.129] ([183.90.37.137]) by mx.google.com with ESMTPSA id je11sm460364pbd.65.2015.03.26.20.18.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 20:18:26 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-836B2C44-98CB-46C7-BBD5-DE4BB50E333D Mime-Version: 1.0 (1.0) From: Dr Alex Gouaillard X-Mailer: iPhone Mail (12B440) In-Reply-To: <010d01d067ed$cc9d8610$65d89230$@gmail.com> Date: Fri, 27 Mar 2015 10:18:20 +0700 Content-Transfer-Encoding: 7bit Message-Id: <47872F30-7268-49E4-BBD5-AFD8BDE7C64F@gmail.com> References: <010d01d067ed$cc9d8610$65d89230$@gmail.com> To: Roni Even Archived-At: Cc: "" Subject: Re: [payload] call for adoption of RTP Payload for VP9 video 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, 27 Mar 2015 03:18:29 -0000 --Apple-Mail-836B2C44-98CB-46C7-BBD5-DE4BB50E333D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Both supported. Sent from my iPhone > On 27 Mar 2015, at 12:53 am, Roni Even wrote: >=20 > Hi, > At the IETF92 session there was support to work on RTP Payload for VP9 vid= eo. The WG chairs would like to confirm it on the mailing list. > We would like to create a new milestone for this topic and adopt draft-ube= rti-payload-vp9-01 as the initial document for the new milestone > =20 > Please provide feedback on both topics (milestone and document adoption) o= n the mailing list till April 10th 2015 > =20 > Thanks > Roni Even > Payload WG co-chair > =20 > =20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --Apple-Mail-836B2C44-98CB-46C7-BBD5-DE4BB50E333D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Both supported.

Sent from my iP= hone

On 27 Mar 2015, at 12:53 am, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi,

At the IETF92 session ther= e was support to work on RTP Payload for VP9 vid= eo. The WG chairs would like to confirm it on the mailing list.

We would like to= create a new milestone for this topic and adopt draft-uberti-payload-vp9-01  as the initial document for the new milestone

 

Please provide= feedback on both topics (milestone and document adoption) on the mailing li= st till April 10th 2015

 

Thanks

Roni Even

Payload WG co-chair

 

 

_____________________________= __________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mail= man/listinfo/payload
= --Apple-Mail-836B2C44-98CB-46C7-BBD5-DE4BB50E333D-- From nobody Thu Mar 26 20:54:59 2015 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 67F331A6EF2; Thu, 26 Mar 2015 20:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, 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 4RqNMOFtTtL3; Thu, 26 Mar 2015 20:54:52 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC481A1A8F; Thu, 26 Mar 2015 20:54:52 -0700 (PDT) Received: by wibg7 with SMTP id g7so12094638wib.1; Thu, 26 Mar 2015 20:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=PWIOVpzMmPgFRS1V+vjdXSTWjNcV2KROeOb5q9iQ72k=; b=HEAd64cslpqfTx5ceNMKBqoaxpEwVrR0T9dZM2hNJ8CsG4VHGO1VkJKjKeMLD9rmc/ ffMkUsF6/DbHL4nKYd3SjmBV10uKBCNNvE7K9fLFsy7NUOhVKTsw9YTsG7qwzyUnaiyA 01I+d7knMUa4v+S6CRHlmYRklT+LohFNkQ8WNwQxJ6EDO15qEdvOO5Q97RzEO/O8SIfR l8jDBJjSwoTYxtxRLTUdkC2Ct5AyX6pZFBLp6uCDNeG6GxqWBu/hKoeXbC9/FfVp0kmw eCr4ZzGbeWTWpMtsEH1TQ3/Td1LSt8Bbw4ZVRY0uX41DQvAwtafixX1BcSke6h7cgvw6 O5Ew== X-Received: by 10.180.85.97 with SMTP id g1mr52132785wiz.17.1427428491089; Thu, 26 Mar 2015 20:54:51 -0700 (PDT) Received: from RoniE ([2001:67c:370:136:a47f:ddb7:7761:fb04]) by mx.google.com with ESMTPSA id w3sm1604791wiz.5.2015.03.26.20.54.47 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Mar 2015 20:54:50 -0700 (PDT) From: "Roni Even" To: "'Black, David'" , , "'Paul E. Jones'" , , , , References: <00b201d0634f$72358260$56a08720$@gmail.com> In-Reply-To: Date: Fri, 27 Mar 2015 06:54:44 +0300 Message-ID: <01b801d06841$c5002b70$4f008250$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEWFnT+JeFbkfrrcMco2eodWkWCYQGjgEAPAaVFwXCeig+pwA== Content-Language: en-us Archived-At: Cc: payload@ietf.org Subject: Re: [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: Fri, 27 Mar 2015 03:54:57 -0000 Hi David, I am not sure why you say that there is dependency on the prefix code. RFC3550 says that the RTP packet length which is not part of the RTP = header will be known from the underlying protocol which is in this case UDP. Otherwise there is no dependency for an RTP receiver to extract the = payload from the RTP packet Roni > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: 21 March, 2015 12:46 AM > To: Roni Even; mramalho@cisco.com; 'Paul E. Jones'; > harada.noboru@lab.ntt.co.jp; muthu.arul@gmail.com; = lei.miao@huawei.com; > ops-dir@ietf.org > Cc: payload@ietf.org; Black, David > Subject: RE: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 >=20 > Roni, >=20 > > Sorry for not commenting but I also saw Robert's email and would = like > > to emphasis that RTP payloads document do not go into the internals = of > > the codec payload. They just explain how to package the media = payload > > and provide enough information for a receiver to extract the media payload. > > They must have a reference to the media payload that is publicly > > available and for this document it is the ITU-T document. >=20 > My concern is a bit different. I concur that the full details of the "internals of > the codec payload" are not necessary in this draft, and I don't = believe my > review has ever asked for that. >=20 > OTOH, I believe that the scope of this draft should be consistent = across > encoding and decoding. For that reason, starting with the prefix code = as an > example, I believe that if this draft uses a data element to specify = the decoding > algorithm, then the encoding algorithm portion of this draft should specify or > otherwise explain where that data element came from when the = corresponding > encoding was performed. For the prefix code example, the authors' proposal > to add the following sentence (from Michael's email) appears to be sufficient > to address this concern: >=20 > As an aside, we note that the first octet of any G.711.0 frame will > be the prefix code octet and information in this octet determines > how many G.711 symbols are represented in the G.711.0 frame. >=20 > My understanding from other emails is that typical payload drafts do = not > depend on values that are part of the codec payload - in contrast, = this draft has > such a dependency on at least the prefix code. That is not an = inherent problem, > but it does create a need to explain what's going on. >=20 > I do not expect to have time to fully review Michael's response (to a review > that I originally sent back in December) until after the Dallas = meeting week. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Friday, March 20, 2015 4:50 PM > > To: Black, David; mramalho@cisco.com; 'Paul E. Jones'; > > harada.noboru@lab.ntt.co.jp; muthu.arul@gmail.com; > > lei.miao@huawei.com; ops- dir@ietf.org > > Cc: payload@ietf.org > > Subject: RE: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 > > > > Hi David, > > Sorry for not commenting but I also saw Robert's email and would = like > > to emphasis that RTP payloads document do not go into the internals = of > > the codec payload. They just explain how to package the media = payload > > and provide enough information for a receiver to extract the media payload. > > They must have a reference to the media payload that is publicly > > available and for this document it is the ITU-T document. > > Thanks > > Roni Even > > Payload WG co-chair > > > > > -----Original Message----- > > > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of = Black, > > > David > > > Sent: 24 December, 2014 7:42 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; ops-dir@ietf.org > > > Cc: Black, David; payload@ietf.org > > > Subject: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 > > > > > > 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" > > > 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 ...] > > > > > > > > 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. > > > > > > 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. > > > > > > > > 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: > > > > > > > > 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. > > > > > > > > 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: > > > > > > > > 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. > > > > > > > > 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 > > > > > > > > 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 > > > > > > > > This is a combined Gen-ART and OPS-DIR review. Boilerplate for > > > > both follows ... > > > > > > > > I am the assigned Gen-ART reviewer for this draft. For = background > > > > on Gen-ART, please see the FAQ at: > > > > > > > > . > > > > > > > > Please resolve these comments along with any other Last Call > > > > comments you may receive. > > > > > > > > I have reviewed this document as part of the Operational > > > > directorate's ongoing 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. > > > > > > > > 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 > > > > > > > > Summary: This draft is on the right track, but has open issues > > > > described in the review. > > > > > > > > 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. > > > > > > > > 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. > > > > > > > > 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. > > > > > > > > -- Major Issues (4): > > > > > > > > [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. > > > > > > > > [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. > > > > > > > > [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). > > > > > > > > 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?): > > > > > > > > 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. > > > > > > > > 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. > > > > > > > > This major issue [C] is independent of the relationship between > > > > this draft and the G.711.0 spec. > > > > > > > > [D] Backwards compatibility. > > > > > > > > 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: > > > > > > > > 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. > > > > > > > > That's definitely wrong. Use of G.711.0 when only G.711 has = been > > > > negotiated will fail to interoperate correctly. > > > > > > > > A subsection of section 3 on negotiation and SDP usage would = help here. > > > > > > > > This major issue [D] is independent of the relationship between > > > > this draft and the G.711.0 spec. > > > > > > > > -- Minor issues (3): > > > > > > > > [E] Section 4.1: > > > > > > > > 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. > > > > > > > > I would change "will have" to "MUST have" and add the following > > sentence: > > > > > > > > The existing G.711 PT values of 0 and 8 MUST NOT be used for G.711.0 > > > > content. > > > > > > > > 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 . > > > > > > > > [F] Section 4.1: > > > > > > > > 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. > > > > > > > > Good start, but not sufficient - cite the "RTP profiles = currently > > > > in use" and I would expect those citations to be normative references. > > > > > > > > Would that be just RFC 3551 and RFC 4585 (both are already > > > > normative references), or are there more RTP profiles? > > > > > > > > [G] Framing errors > > > > > > > > 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. > > > > > > > > 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. > > > > > > > > -- Nits/editorial comments: > > > > > > > > Section 3.2: > > > > > > > > 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". > > > > > > > > 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. > > > > > > > > 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]. > > > > > > > > Expand WMOPS on first use, and check for other acronyms that = need > > > > to be expanded on first use. > > > > > > > > Section 3.3: > > > > > > > > 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). > > > > > > > > "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. > > > > > > > > Section 6: > > > > > > > > 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. > > > > > > > > "that not" -> "that are not" > > > > > > > > Section 6.2: > > > > > > > > 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. > > > > > > > > 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. > > > > > > > > Section 11: Congestion Control > > > > > > > > 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". > > > > > > > > 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. > > > > > > > > idnits 2.13.01 didn't find anything to complain about ;-). > > > > > > > > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > > > > > > > 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. > > > > > > > > A.1.3. Has the migration path been discussed? > > > > > > > > No, see major issue [D] above. > > > > > > > > A.1.4 Have the Requirements on other protocols and functional > > > > components been discussed? > > > > > > > > Only in part - major issues [C] and [D] call out shortcomings in > > > > the discussion of SDP interactions. > > > > > > > > A.1.8 Are there fault or threshold conditions that should be reported? > > > > > > > > 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]. > > > > > > > > A.2. Management Considerations > > > > > > > > I would expect that the media type registration (Section 5.1 of > > > > this > > > > draft) 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. > > > > > > > > A.3 Documentation > > > > > > > > By itself, this compressed payload format does not look like a > > > > likely source of significant operational impacts on the = Internet. > > > > > > > > The shepherd's writeup indicates that an implementation exists. > > > > > > > > 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-7786 > > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) = 394-7754 > > > > ---------------------------------------------------- > > > > > > _______________________________________________ > > > payload mailing list > > > payload@ietf.org > > > https://www.ietf.org/mailman/listinfo/payload From nobody Fri Mar 27 06:23:34 2015 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 A6E221ACE2F; Fri, 27 Mar 2015 06:23:31 -0700 (PDT) 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 eEi97KWjrhmi; Fri, 27 Mar 2015 06:23:26 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 256C71ACE13; Fri, 27 Mar 2015 06:20:19 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t2RDK7Ca006232 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Mar 2015 09:20:12 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t2RDK7Ca006232 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1427462412; bh=EFFnqRLpYFYnfpdE+JykLmRLyNs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=UNUDqlDzlFlrKv+ch8Hek1cIiHcYWszv8eBq3ETZ0+y0nqqAkb1bsKr9pJlHaEO+6 LksOgb0BuJ6GKBNQZ9879+vmRIWsT9fcGtXnHYvIhP2oGSjCEbSzG0boiGisJNq8pC aYS0ego7FJ3bRWzUBmvBkNfctQF+G83AW7NHyyQI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t2RDK7Ca006232 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd56.lss.emc.com (RSA Interceptor); Fri, 27 Mar 2015 09:19:43 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t2RDJumr032175 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 09:19:57 -0400 Received: from MXHUB201.corp.emc.com (10.253.68.27) by mxhub01.corp.emc.com (10.254.141.103) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 27 Mar 2015 09:19:56 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB201.corp.emc.com ([10.253.68.27]) with mapi id 14.03.0224.002; Fri, 27 Mar 2015 09:19:56 -0400 From: "Black, David" To: Roni Even , "mramalho@cisco.com" , "'Paul E. Jones'" , "harada.noboru@lab.ntt.co.jp" , "muthu.arul@gmail.com" , "lei.miao@huawei.com" , "ops-dir@ietf.org" Thread-Topic: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 Thread-Index: AdAfPFVGeZeAXS5RRlmbbcNFHVlO1BENKKYAAATmz2ABN62hAAALN4pw Date: Fri, 27 Mar 2015 13:19:55 +0000 Message-ID: References: <00b201d0634f$72358260$56a08720$@gmail.com> <01b801d06841$c5002b70$4f008250$@gmail.com> In-Reply-To: <01b801d06841$c5002b70$4f008250$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.47.246] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "Black, David" , "payload@ietf.org" Subject: Re: [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: Fri, 27 Mar 2015 13:23:31 -0000 > I am not sure why you say that there is dependency on the prefix code. The draft specifies use of the G.7110.0 prefix code in encoding and decodin= g. Here's an example from the decoding steps specified in Section 4.2.3: H5 Process an individual G.711.0 frame (produce G.711 samples in the output frame): Pass the internal buffer to the G.711.0 decoder. The G.711.0 decoder will read the first octet (called the "prefix code" octet in ITU-T Rec. G.711.0 [G.711.0]) to determine the number of source G.711 samples M are contained in this G.711.0 frame. The G.711.0 decoder will produce exactly M G.711 source symbols. If the preferred approach is not to use anything from the G.7110.0 payload then the encapsulation format would need to change to include a frame length indicator that's outside the G.7110.0 payload data. That would be an incompatible change to what this draft currently specifies (and probably duplicative wrt the prefix code in the frame). Thanks, --David > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Thursday, March 26, 2015 11:55 PM > To: Black, David; mramalho@cisco.com; 'Paul E. Jones'; > harada.noboru@lab.ntt.co.jp; muthu.arul@gmail.com; lei.miao@huawei.com; o= ps- > dir@ietf.org > Cc: payload@ietf.org > Subject: RE: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 >=20 > Hi David, > I am not sure why you say that there is dependency on the prefix code. > RFC3550 says that the RTP packet length which is not part of the RTP head= er > will be known from the underlying protocol which is in this case UDP. > Otherwise there is no dependency for an RTP receiver to extract the paylo= ad > from the RTP packet >=20 > Roni >=20 > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: 21 March, 2015 12:46 AM > > To: Roni Even; mramalho@cisco.com; 'Paul E. Jones'; > > harada.noboru@lab.ntt.co.jp; muthu.arul@gmail.com; lei.miao@huawei.com; > > ops-dir@ietf.org > > Cc: payload@ietf.org; Black, David > > Subject: RE: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 > > > > Roni, > > > > > Sorry for not commenting but I also saw Robert's email and would like > > > to emphasis that RTP payloads document do not go into the internals o= f > > > the codec payload. They just explain how to package the media payload > > > and provide enough information for a receiver to extract the media > payload. > > > They must have a reference to the media payload that is publicly > > > available and for this document it is the ITU-T document. > > > > My concern is a bit different. I concur that the full details of the > "internals of > > the codec payload" are not necessary in this draft, and I don't believe= my > > review has ever asked for that. > > > > OTOH, I believe that the scope of this draft should be consistent acros= s > > encoding and decoding. For that reason, starting with the prefix code = as > an > > example, I believe that if this draft uses a data element to specify th= e > decoding > > algorithm, then the encoding algorithm portion of this draft should > specify or > > otherwise explain where that data element came from when the correspond= ing > > encoding was performed. For the prefix code example, the authors' > proposal > > to add the following sentence (from Michael's email) appears to be > sufficient > > to address this concern: > > > > As an aside, we note that the first octet of any G.711.0 frame will > > be the prefix code octet and information in this octet determines > > how many G.711 symbols are represented in the G.711.0 frame. > > > > My understanding from other emails is that typical payload drafts do no= t > > depend on values that are part of the codec payload - in contrast, this > draft has > > such a dependency on at least the prefix code. That is not an inherent > problem, > > but it does create a need to explain what's going on. > > > > I do not expect to have time to fully review Michael's response (to a > review > > that I originally sent back in December) until after the Dallas meeting > week. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, March 20, 2015 4:50 PM > > > To: Black, David; mramalho@cisco.com; 'Paul E. Jones'; > > > harada.noboru@lab.ntt.co.jp; muthu.arul@gmail.com; > > > lei.miao@huawei.com; ops- dir@ietf.org > > > Cc: payload@ietf.org > > > Subject: RE: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 > > > > > > Hi David, > > > Sorry for not commenting but I also saw Robert's email and would like > > > to emphasis that RTP payloads document do not go into the internals o= f > > > the codec payload. They just explain how to package the media payload > > > and provide enough information for a receiver to extract the media > payload. > > > They must have a reference to the media payload that is publicly > > > available and for this document it is the ITU-T document. > > > Thanks > > > Roni Even > > > Payload WG co-chair > > > > > > > -----Original Message----- > > > > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Black, > > > > David > > > > Sent: 24 December, 2014 7:42 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; ops-dir@ietf.org > > > > Cc: Black, David; payload@ietf.org > > > > Subject: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 > > > > > > > > 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. Thi= s > > > > 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 coverin= g > > > > > how > > > > > G.711.0 decompression interacts with received RTP G.711.0 payload= s. > > > > > 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 ver= y > > > > > difficult to figure out what's going on when G.711.0 frames are > > > > > concatenated. A specific example is that the concept of a "prefi= x > > > > > 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 fram= e. > > > > The Prefix Code value of 0x00 is used to denote zero G.711 sourc= e > > > > 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 canno= t > > > 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" > > > > 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 fram= e. > > > > 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 fram= e > > > > (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 ou= t > > > > > and imprecise (is SDP REQUIRED?, when is ptime REQUIRED, > > > > > RECOMMENDED, or recommended? - it's not obvious). > > > > > > > > > [... snip ...] > > > > > > > > > > I would suggest that a subsection be added, possibly at the end o= f > > > > > 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. > > > > > > > > Not done, although the sentence added (for [D]) on negotiation bein= g > > > > 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. > > > > > > > > > > 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: > > > > > > > > > > G.711.0, being both lossless and stateless, may also be employ= ed > as a > > > > > lossless compression mechanism anywhere between end systems wh= ich > > > > > have negotiated use of G.711. > > > > > > > > > > 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 betwe= en > > > > 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 betwe= en > > > > 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: > > > > > > > > > > PT - The assignment of an RTP payload type for the format > defined > > > > > in this memo is outside the scope of this document. The RT= P > > > > > profiles in use currently mandate binding the payload type > > > > > dynamically for this payload format. > > > > > > > > > > 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 > > > > > > > > > > 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 Cod= e" > > > > 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-0= 3 > > > > > > > > > > This is a combined Gen-ART and OPS-DIR review. Boilerplate for > > > > > both follows ... > > > > > > > > > > I am the assigned Gen-ART reviewer for this draft. For background > > > > > on Gen-ART, please see the FAQ at: > > > > > > > > > > . > > > > > > > > > > Please resolve these comments along with any other Last Call > > > > > comments you may receive. > > > > > > > > > > I have reviewed this document as part of the Operational > > > > > directorate's ongoing 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. > > > > > > > > > > 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 > > > > > > > > > > Summary: This draft is on the right track, but has open issues > > > > > described in the review. > > > > > > > > > > Process note: This is the second draft that I've reviewed recentl= y > > > > > 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-minut= e > > > > > changes to the draft when issues are discovered during IETF LC. > > > > > > > > > > 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. > > > > > > > > > > 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 effectivel= y > > > > > an Annex to G.711.0 should be stated. Otherwise, those two major > issues > > need attention. > > > > > > > > > > -- Major Issues (4): > > > > > > > > > > [A] Section 4.2.3 specifies a detailed decoding algorithm coverin= g > > > > > how > > > > > G.711.0 decompression interacts with received RTP G.711.0 payload= s. > > > > > 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. > > > > > > > > > > [B] The G.711.0 frame format is not specified here, making it ver= y > > > > > difficult to figure out what's going on when G.711.0 frames are > > > > > concatenated. A specific example is that the concept of a "prefi= x > > > > > 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. > > > > > > > > > > [C] The discussion of use of the SDP ptime parameter is spread ou= t > > > > > and imprecise (is SDP REQUIRED?, when is ptime REQUIRED, > > > > > RECOMMENDED, or recommended? - it's not obvious). > > > > > > > > > > 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?): > > > > > > > > > > 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 channel= s > of > > > > > data were contained in the payload. > > > > > > > > > > I would suggest that a subsection be added, possibly at the end o= f > > > > > 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. > > > > > > > > > > This major issue [C] is independent of the relationship between > > > > > this draft and the G.711.0 spec. > > > > > > > > > > [D] Backwards compatibility. > > > > > > > > > > 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: > > > > > > > > > > G.711.0, being both lossless and stateless, may also be employ= ed > as a > > > > > lossless compression mechanism anywhere between end systems wh= ich > > > > > have negotiated use of G.711. > > > > > > > > > > That's definitely wrong. Use of G.711.0 when only G.711 has been > > > > > negotiated will fail to interoperate correctly. > > > > > > > > > > A subsection of section 3 on negotiation and SDP usage would help > here. > > > > > > > > > > This major issue [D] is independent of the relationship between > > > > > this draft and the G.711.0 spec. > > > > > > > > > > -- Minor issues (3): > > > > > > > > > > [E] Section 4.1: > > > > > > > > > > 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] eve= n > though > > > > > the negotiation and use of dynamic payload types is allowed fo= r > > > > > G.711. > > > > > > > > > > I would change "will have" to "MUST have" and add the following > > > sentence: > > > > > > > > > > The existing G.711 PT values of 0 and 8 MUST NOT be used for > G.711.0 > > > > > content. > > > > > > > > > > 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 . > > > > > > > > > > [F] Section 4.1: > > > > > > > > > > PT - The assignment of an RTP payload type for the format > defined > > > > > in this memo is outside the scope of this document. The RT= P > > > > > profiles in use currently mandate binding the payload type > > > > > dynamically for this payload format. > > > > > > > > > > Good start, but not sufficient - cite the "RTP profiles currently > > > > > in use" and I would expect those citations to be normative > references. > > > > > > > > > > Would that be just RFC 3551 and RFC 4585 (both are already > > > > > normative references), or are there more RTP profiles? > > > > > > > > > > [G] Framing errors > > > > > > > > > > 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. > > > > > > > > > > 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 th= e > > > > > 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. > > > > > > > > > > -- Nits/editorial comments: > > > > > > > > > > Section 3.2: > > > > > > > > > > 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". > > > > > > > > > > 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. > > > > > > > > > > A8 Low Complexity: Less than 1.0 WMOPS average and low memory > > > > > footprint (~5k octets RAM, ~5.7k octets ROM and ~3.6 bas= ic > > > > > operations) [ICASSP] [G.711.0]. > > > > > > > > > > Expand WMOPS on first use, and check for other acronyms that need > > > > > to be expanded on first use. > > > > > > > > > > Section 3.3: > > > > > > > > > > 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 wa= s > > used > > > > > (A-law or mu-law). > > > > > > > > > > "companding law"? The term "compression law" is used elsewhere i= n > > > > > this draft, including two paragraphs earlier in this section - I > > > > > suggest using "compression law" consistently. > > > > > > > > > > Section 6: > > > > > > > > > > We note that something must be stored for any G.711.0 frames t= hat > not > > > > > received at the receiving endpoint, no matter what the cause. > > > > > > > > > > "that not" -> "that are not" > > > > > > > > > > Section 6.2: > > > > > > > > > > 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, mi= nus > > > > > one}), as analog inputs such as speech and music are zero-mean > and > > > > > are typically acoustically coupled to digital sampling systems= . > > > > > > > > > > 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 t= he > > analog input? > > > > > It might be simpler to delete the parenthesized text. > > > > > > > > > > Section 11: Congestion Control > > > > > > > > > > This section is mis-named, as it basically (correctly) says that > > > > > there is nothing useful that can be done in G.711.0 compression t= o > > > > > respond to congestion. I would retitle this to "Congestion > Considerations". > > > > > > > > > > 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. > > > > > > > > > > idnits 2.13.01 didn't find anything to complain about ;-). > > > > > > > > > > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > > > > > > > > > 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. > > > > > > > > > > A.1.3. Has the migration path been discussed? > > > > > > > > > > No, see major issue [D] above. > > > > > > > > > > A.1.4 Have the Requirements on other protocols and functional > > > > > components been discussed? > > > > > > > > > > Only in part - major issues [C] and [D] call out shortcomings in > > > > > the discussion of SDP interactions. > > > > > > > > > > A.1.8 Are there fault or threshold conditions that should be > reported? > > > > > > > > > > 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 is= sue > [G]. > > > > > > > > > > A.2. Management Considerations > > > > > > > > > > I would expect that the media type registration (Section 5.1 of > > > > > this > > > > > draft) results in this new G.711.0 media type being usable in any > > > > > relevant management model and/or framework that has some notion o= f > > > > media type. > > > > > > > > > > A.3 Documentation > > > > > > > > > > By itself, this compressed payload format does not look like a > > > > > likely source of significant operational impacts on the Internet. > > > > > > > > > > The shepherd's writeup indicates that an implementation exists. > > > > > > > > > > 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 (50= 8) 293-7786 > > > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-775= 4 > > > > > ---------------------------------------------------- > > > > > > > > _______________________________________________ > > > > payload mailing list > > > > payload@ietf.org > > > > https://www.ietf.org/mailman/listinfo/payload From nobody Fri Mar 27 07:05:20 2015 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 A0DBA1ACE80; Fri, 27 Mar 2015 07:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, 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 4hbIAj0YVHGu; Fri, 27 Mar 2015 07:05:05 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8601ACE6F; Fri, 27 Mar 2015 07:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4098; q=dns/txt; s=iport; t=1427465104; x=1428674704; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gck4DU+w4A2FbRJ/RHOxJd7JSIocCWgvjrYhbEsxNnc=; b=Et2Gh/0wgBtG8BNw07c+BctTO63bLct7SFBKy6U8H1U0bfjKq58I8VWM r0Zvl4WQ6ZFq59BXimb6HoGKFk9U3S1hd9+HC6ggYmyIJXDDEoeAi2d22 OK2Efl+l6yDqpBrGjO0oGKsrx3jH6fbbu+S1OHzoUPnmh6q1UEMG6pOki M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BACQCoYhVV/5JdJa1cgwaBLATDAYgwAoE3TAEBAQEBAX2EFAEBAQMBOj8FBwQCAQgRBAEBCxQJByERFAkIAQEEAQ0FCIgTAwkIxl0NhUMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyiCR4IAMQcGgxGBFgEEkFeGFIIPgmiGC4ZggmODSCKBfwMcgVBvAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,479,1422921600"; d="scan'208";a="135976645" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP; 27 Mar 2015 14:05:04 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t2RE53oT022028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 14:05:03 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.31]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 09:05:03 -0500 From: "Michael Ramalho (mramalho)" To: "Black, David" , Roni Even , "'Paul E. Jones'" , "harada.noboru@lab.ntt.co.jp" , "muthu.arul@gmail.com" , "lei.miao@huawei.com" , "ops-dir@ietf.org" Thread-Topic: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 Thread-Index: AdAfPFVGeZeAXS5RRlmbbcNFHVlO1BEPQRgAAAQJ/YABOIpyAAATvSKAAAo1KvA= Date: Fri, 27 Mar 2015 14:05:02 +0000 Message-ID: References: <00b201d0634f$72358260$56a08720$@gmail.com> <01b801d06841$c5002b70$4f008250$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.135.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" Subject: Re: [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: Fri, 27 Mar 2015 14:05:07 -0000 David, The answer is as follows: A G.711.0 frame can contain up to 320 source G.711 symbols. So the G.711.0 = decoder will (normally) have a return buffer of length 320 bytes to accommo= date the largest number of G.711 source symbols that a G.711.0 frame could = contain. The G.711.0 decoder is passed a buffer that contains one or more G.711.0 fr= ames in it. The G.711.0 decoder returns exactly M G.711 source symbols. To be more expl= icit, the decoder function returns both: 1) the number of G.711 source symb= ols (M) and 2) a buffer (that is usually sized to be 320 octets) that conta= ins the M symbols. The implementer of the payload format NEVER has to know details of the pref= ix code. The ITU-T specified decoder needs to know about the prefix code in= order to know how many G.711 source symbols to create (in this case M). The implementer needs to know: 1) M (which the decoder returns), and 2) the= G.711 source symbols (which the decoder returns). It is for this reason that the authors resisted adding too much information= on the prefix code. We did need to mention the prefix code because one code, 0x00, effectively = indicates a "null G.711.0 frame" and thus could be used for padding purpose= s in the RTP payload (before or after G.711.0 frames). We wanted to call th= at out for the benefit of understanding. The interested reader is encouraged to read the (freely available) G.711.0 = standard from the ITU-T site if they desire more details on what the prefix= code is and how it is used in the G.711.0 encoding/decoding process (just = like any other codec spec). One of my co-authors suggested putting in the p= refix code table in this draft - but I declined as it is fully specified in= the relevant SDO document. I hope this helps. We do very much appreciate your through review. Best, Michael Ramalho -----Original Message----- From: Black, David [mailto:david.black@emc.com]=20 Sent: Friday, March 27, 2015 8:20 AM To: Roni Even; Michael Ramalho (mramalho); 'Paul E. Jones'; harada.noboru@l= ab.ntt.co.jp; muthu.arul@gmail.com; lei.miao@huawei.com; ops-dir@ietf.org Cc: payload@ietf.org; Black, David Subject: RE: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 > I am not sure why you say that there is dependency on the prefix code. The draft specifies use of the G.7110.0 prefix code in encoding and decodin= g. Here's an example from the decoding steps specified in Section 4.2.3: H5 Process an individual G.711.0 frame (produce G.711 samples in the output frame): Pass the internal buffer to the G.711.0 decoder. The G.711.0 decoder will read the first octet (called the "prefix code" octet in ITU-T Rec. G.711.0 [G.711.0]) to determine the number of source G.711 samples M are contained in this G.711.0 frame. The G.711.0 decoder will produce exactly M G.711 source symbols. If the preferred approach is not to use anything from the G.7110.0 payload = then the encapsulation format would need to change to include a frame lengt= h indicator that's outside the G.7110.0 payload data. That would be an inc= ompatible change to what this draft currently specifies (and probably dupli= cative wrt the prefix code in the frame). Thanks, --David > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Thursday, March 26, 2015 11:55 PM > To: Black, David; mramalho@cisco.com; 'Paul E. Jones';=20 > harada.noboru@lab.ntt.co.jp; muthu.arul@gmail.com;=20 > lei.miao@huawei.com; ops- dir@ietf.org > Cc: payload@ietf.org > Subject: RE: [payload] OPS-Dir review of draft-ietf-payload-g7110-04 >=20 > Hi David, > I am not sure why you say that there is dependency on the prefix code. > RFC3550 says that the RTP packet length which is not part of the RTP=20 > header will be known from the underlying protocol which is in this case U= DP. > Otherwise there is no dependency for an RTP receiver to extract the=20 > payload from the RTP packet >=20 > Roni From nobody Fri Mar 27 07:08:42 2015 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 1F91E1ACDD7 for ; Fri, 27 Mar 2015 07:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=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 HG0kVwEzhfWh for ; Fri, 27 Mar 2015 07:08:39 -0700 (PDT) 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 E3A721ACDC0 for ; Fri, 27 Mar 2015 07:08:39 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTP id 47B2FF218E for ; Fri, 27 Mar 2015 07:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.corp.phx1.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C25wdGxlUmG for ; Fri, 27 Mar 2015 07:08:39 -0700 (PDT) Received: from [31.133.168.228] (dhcp-a8e4.meeting.ietf.org [31.133.168.228]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id E93B8F2183 for ; Fri, 27 Mar 2015 07:08:38 -0700 (PDT) Message-ID: <55156466.4080703@xiph.org> Date: Fri, 27 Mar 2015 07:08:38 -0700 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: <010d01d067ed$cc9d8610$65d89230$@gmail.com> <47872F30-7268-49E4-BBD5-AFD8BDE7C64F@gmail.com> In-Reply-To: <47872F30-7268-49E4-BBD5-AFD8BDE7C64F@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [payload] call for adoption of RTP Payload for VP9 video 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, 27 Mar 2015 14:08:42 -0000 Dr Alex Gouaillard wrote: > Both supported. +1 From nobody Sat Mar 28 15:31:33 2015 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 C8C4F1A8A4F for ; Sat, 28 Mar 2015 15:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 zjlk6pTXPWog for ; Sat, 28 Mar 2015 15:31:28 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD53C1A898D for ; Sat, 28 Mar 2015 15:31:28 -0700 (PDT) Received: by igcau2 with SMTP id au2so47280939igc.0 for ; Sat, 28 Mar 2015 15:31:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QHn445YVfHff15s1Rumy1xFJbT0VyJkOzfYcG92sUrI=; b=MDn/xZT2LCnyJLoZ4E5qDTTZ1sbjsjVPRDLLTXwfT0mjRqrxsyOZtPyM47kVj+nbXF Yml1R2ZRHIJLAQTWEqkoBxjm2DTxHTiuRRgTSyqw6NzVmbsSrVAj01cvGLM2/6Cf7RL+ wSxA3ZVHjLG/yJrfRgf9YFAZUwmjO3rzGjL4YLaaEYCgk9ahh7qssjVhunBxCeapVlVF 1EEP/mM0XJuGv4kSv7v/XukqGjTB3KVzVVq6fen/QOCgW/Q0PSDWrZD3hukKY3LIieLP VSTMO30W7ux/jITCHj6MvbshKEa5KqDaB8oYx6C83fG7xec+VwA5lKdKinvJS9c52mte 4ITg== X-Gm-Message-State: ALoCoQnFkgmETKwkQbqjk4S31yeWk5XDj4FHBw/yibWpwsVB3Sje0mWPCyltvqWjrNkEto7P71vm X-Received: by 10.107.8.67 with SMTP id 64mr37502298ioi.61.1427581887952; Sat, 28 Mar 2015 15:31:27 -0700 (PDT) Received: from panoramix.jmvalin.ca ([12.130.116.2]) by mx.google.com with ESMTPSA id q191sm1098816ioe.39.2015.03.28.15.31.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Mar 2015 15:31:27 -0700 (PDT) Message-ID: <55172BBB.8030406@mozilla.com> Date: Sat, 28 Mar 2015 18:31:23 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Timothy B. Terriberry" , "" References: <010d01d067ed$cc9d8610$65d89230$@gmail.com> <47872F30-7268-49E4-BBD5-AFD8BDE7C64F@gmail.com> <55156466.4080703@xiph.org> In-Reply-To: <55156466.4080703@xiph.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [payload] call for adoption of RTP Payload for VP9 video 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: Sat, 28 Mar 2015 22:31:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I support both. On 27/03/15 10:08 AM, Timothy B. Terriberry wrote: > Dr Alex Gouaillard wrote: >> Both supported. > > +1 > > _______________________________________________ payload mailing > list payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVFyu4AAoJEJ6/8sItn9q9K1sIALgoCDZ5r6l8IdwGjq9o1Yig gu9qVT1hdSuKEh61dumMpDu7XQyYCMV/N3mvwm8SQ2+4Yh/gREuvtjeFCbtcBIcP m01yYlJBzk281eoCbC2cmpmGOl+d3C2fjqZaYYepM40af/zhMPwEJnD/IUqaGlSo rgxZC3kodUHl71Sbhc5hEMnThmKIYXtazvWlRMXXwG5B+ofg23+Fh7tRQEHNhPmd Meci2Y7/B2wuS/Emf1C6sMWWD/1wTzntEtI0h4wWX3xd49sP3UHbem9h7KcpiZUm iM7eCo2dIqZlnzwkG9lN0IxUJOA9IkkgIITcZg0yYl85CzDRlo+Y4dQpoJGRivc= =Acwn -----END PGP SIGNATURE----- From nobody Tue Mar 31 19:31:47 2015 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 49BA01A19E9 for ; Tue, 31 Mar 2015 19:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, 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 XPqKWy_PsqZG for ; Tue, 31 Mar 2015 19:31:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29F91A066C for ; Tue, 31 Mar 2015 19:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4265; q=dns/txt; s=iport; t=1427855506; x=1429065106; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=8HqXfZXi3Y22n91n/zeElT1Cevzck+bXf4oitvHPDog=; b=YZ7HIsISHsPz37lM4qgHkSlYM9XMn+zCsOMAPW0U+7sB7hfdU4YJI1nq E46FrhNg5qDeoYgVUXVYNEzZJQlv9uc8l4YCQg72qZpI4LUBUzAYw6yE/ Xroq+Kp7Cfnb5hCXp2ETIX+0xR0cOHh56EdIZwuovssW6GtpPsO5szOqN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BbBgB8VxtV/40NJK1cgkNDUlwFxASCAIVzAoFFTAEBAQEBAX2EFQEBBB0QQRsCAQgECjEHIREUEQIEARKIGwMRDcgkDYVQAQEBAQEBAQECAQEBAQEBAQEaiymCR4I4hC0FkGKDcoQ2gU2BHTqCeIlBhisig25vAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208,217";a="405139232" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 01 Apr 2015 02:31:45 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t312Vj1Z015163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 02:31:45 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.214]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 21:31:44 -0500 From: "Mo Zanaty (mzanaty)" To: Roni Even , "payload@ietf.org" Thread-Topic: [payload] call for adoption of RTP Payload for VP9 video Thread-Index: AQHQbCP+cqUlAMF2g0KrlcL1tBvMBw== Date: Wed, 1 Apr 2015 02:31:44 +0000 Message-ID: References: <010d01d067ed$cc9d8610$65d89230$@gmail.com> In-Reply-To: <010d01d067ed$cc9d8610$65d89230$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [64.100.32.216] Content-Type: multipart/alternative; boundary="_000_D140D0A64B113mzanatyciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [payload] call for adoption of RTP Payload for VP9 video 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, 01 Apr 2015 02:31:47 -0000 --_000_D140D0A64B113mzanatyciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adopting the milestone and document. Mo On 3/26/15, 1:53 PM, Roni Even > wrote: Hi, At the IETF92 session there was support to work on RTP Payload for VP9 vide= o. The WG chairs would like to confirm it on the mailing list. We would like to create a new milestone for this topic and adopt draft-uber= ti-payload-vp9-01= as the initial document for the new milestone Please provide feedback on both topics (milestone and document adoption) on= the mailing list till April 10th 2015 Thanks Roni Even Payload WG co-chair --_000_D140D0A64B113mzanatyciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <01B9528456F49546B61FCFA683822B42@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I support adopting the milestone and document.

Mo

On 3/26/15, 1:53 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi,

At the IETF92 session there was support to work on <= span style=3D"color:black"> RTP Payload for VP9 video. The WG chairs would like to confirm it on the ma= iling list.

We would like to create = a new milestone for this topic and adopt draft-= uberti-payload-vp9-01 as the initial document for the new m= ilestone

 

Please provide feedback on both topics (milestone an= d document adoption) on the mailing list till April 10th 2015

 

Thanks

Roni Even

Payload WG co-chair

 

 

 --_000_D140D0A64B113mzanatyciscocom_--