From nobody Mon Apr 10 09:48:17 2017 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FF5124BFA; Mon, 10 Apr 2017 09:48:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avtext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149184288938.3160.5167126790858286299@ietfa.amsl.com> Date: Mon, 10 Apr 2017 09:48:09 -0700 Archived-At: Subject: [avtext] I-D Action: draft-ietf-avtext-lrr-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:48:09 -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 Extensions of the IETF. Title : The Layer Refresh Request (LRR) RTCP Feedback Message Authors : Jonathan Lennox Danny Hong Justin Uberti Stefan Holmer Magnus Flodman Filename : draft-ietf-avtext-lrr-04.txt Pages : 14 Date : 2017-04-10 Abstract: This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-lrr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-avtext-lrr-04 https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-lrr-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 10 18:01:58 2017 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7E21242F5; Mon, 10 Apr 2017 18:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lIBQ2h1bgmBK; Mon, 10 Apr 2017 18:01:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9627C127873; Mon, 10 Apr 2017 18:01:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKQ75239; Tue, 11 Apr 2017 01:01:51 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 11 Apr 2017 02:01:50 +0100 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.8]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 11 Apr 2017 09:01:42 +0800 From: "Huangyihong (Rachel)" To: "avt@ietf.org" , "avtext@ietf.org" Thread-Topic: [avtcore][avtext] WGLC for draft-ietf-avtext-lrr-04 Thread-Index: AdKyXy6C5yuvZ52QRpuGLK0PQ1UraA== Date: Tue, 11 Apr 2017 01:01:42 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05@nkgeml513-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.110] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58EC2B00.0017, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 451e18718710bf961dcbf11db739a259 Archived-At: Subject: [avtext] [avtcore] WGLC for draft-ietf-avtext-lrr-04 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 01:01:56 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05nkgeml513mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, It is agreed that draft-ietf-avtext-lrr-04 is stable enough for the next st= ep. Therefore, this email starts a working group last call for draft-ietf-a= vtext-lrr-04. This WGLC runs until April 28th. So please have a look at the= draft and send your comments to the avt list by then. Thanks. The draft is now available at https://datatracker.ietf.org/doc/html/draft-i= etf-avtext-lrr-04. BR, Rachel (co-chair) --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05nkgeml513mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG,

 

It is agreed that draft-ietf-av= text-lrr-04 is stable enough for the next step. Therefore, this email start= s a working group last call for draft-ietf-avtext-lrr-04. This WGLC runs un= til April 28th. So please have a look at the draft and send your comments to the avt list by then. T= hanks.

 

The draft is now available at <= a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-04"> https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-04.

 

BR,

Rachel (co-chair)

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05nkgeml513mbschi_-- From nobody Fri Apr 28 01:43:22 2017 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E11C129AF6; Fri, 28 Apr 2017 01:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 s54qjVglUsVH; Fri, 28 Apr 2017 01:43:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE38B12778D; Fri, 28 Apr 2017 01:40:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLX40314; Fri, 28 Apr 2017 08:39:59 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 28 Apr 2017 09:39:58 +0100 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.108]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Fri, 28 Apr 2017 16:39:53 +0800 From: "Huangyihong (Rachel)" To: "avt@ietf.org" , "avtext@ietf.org" Thread-Topic: [avtext] [avtcore] extended WGLC for draft-ietf-avtext-lrr-04 Thread-Index: AQHSv/sB7+55mJmzLE+Jf56bGerlRQ== Date: Fri, 28 Apr 2017 08:39:53 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C451A44@nkgeml513-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05@nkgeml513-mbs.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05@nkgeml513-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.110] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C451A44nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5902FFE0.0022, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.108, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b5c9c7d2e9792c7d41ff1807c69c2fa5 Archived-At: Subject: [avtext] [avtcore] extended WGLC for draft-ietf-avtext-lrr-04 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 08:43:21 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C451A44nkgeml513mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'll extend this WGLC for another week (until 5/5) as I didn't see any feed= back in the list. If you think this draft has no further issues and ready for the next step, = please don't be silent and express it in the list. We'll appreciate it. BR, Rachel (co-chair) From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Huangyihong (Rac= hel) Sent: Tuesday, April 11, 2017 9:02 AM To: avt@ietf.org; avtext@ietf.org Subject: [avtext] [avtcore] WGLC for draft-ietf-avtext-lrr-04 Hi WG, It is agreed that draft-ietf-avtext-lrr-04 is stable enough for the next st= ep. Therefore, this email starts a working group last call for draft-ietf-a= vtext-lrr-04. This WGLC runs until April 28th. So please have a look at the= draft and send your comments to the avt list by then. Thanks. The draft is now available at https://datatracker.ietf.org/doc/html/draft-i= etf-avtext-lrr-04. BR, Rachel (co-chair) --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C451A44nkgeml513mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

I’= ;ll extend this WGLC for another week (until 5/5) as I didn’t see any= feedback in the list.

&n= bsp;

If you = think this draft has no further issues and ready for the next step, please = don’t be silent and express it in the list. We’ll appreciate it= .

&n= bsp;

BR,

Rachel = (co-chair)

&n= bsp;

From: avtext [mail= to:avtext-bounces@ietf.org] On Behalf Of Huangyihong (Rachel)
Sent: Tuesday, April 11, 2017 9:02 AM
To: avt@ietf.org; avtext@ietf.org
Subject: [avtext] [avtcore] WGLC for draft-ietf-avtext-lrr-04

 

Hi WG,

 

It is agreed that draft-ietf-av= text-lrr-04 is stable enough for the next step. Therefore, this email start= s a working group last call for draft-ietf-avtext-lrr-04. This WGLC runs un= til April 28th. So please have a look at the draft and send your comments to the avt list by then. T= hanks.

 

The draft is now available at <= a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-04"> https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-04.

 

BR,

Rachel (co-chair)

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C451A44nkgeml513mbschi_-- From nobody Sun Apr 30 07:52:03 2017 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2293129401; Sun, 30 Apr 2017 07:51:53 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JXzVdrutivmu; Sun, 30 Apr 2017 07:51:51 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::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 115FE1293E4; Sun, 30 Apr 2017 07:49:49 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id s22so24152077ybe.3; Sun, 30 Apr 2017 07:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iFYIM0QPWAZd2pL0QGL0GcOxmVRB5MaQhVtewod4xvo=; b=C/eNOHtel/MnnK45gjIecsi0G12jB0eSxJDFxtH4xom0bNkrxsvjtdsmNcWyJSfwge mwItTrqJcM6N9WtkUOZD8fLluWidxionnvgs1bBxE0MegKNCxOL8jLgTPZlpC9avZprZ NdEDnM+haCqSRJ2PgAWdAEIj5FPHXp57QQwTGyowO8VGcjD1lYUxwb+7DTs2oGd1ktkz 1ahRvfFIr5+AsNR7xe33ZMFHBrl1Xc/abwW7ws1gV8beao9hhEg1gmOR7soIjYz5rJs9 wEC6F2wUbYPBQADhkMtXu39kUTvaU99l1dFmNw2DLbgciTRNVSIS495Y8q6pplWBKb2Y Io0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iFYIM0QPWAZd2pL0QGL0GcOxmVRB5MaQhVtewod4xvo=; b=ndBSEw/oWgQfpobC4vOteIpZV7vWBJNCYCLE1ZswgYr2GBeJwWFkyrgsYhviMKII89 qFIxT9R1GRAAsMJzvU5Pq6AQ+BkuVhqshVjVGtINwP0CyPQbZyEDLP65shVkFw3XbsQg VtIZNIZcF/LfhV5bUygAdgKxxagVxBBDH4Pmf2FdJl//Z/1PhjbtPou400A4bm6x5uOY j37QMc8cyxu4EXO3+JOsQNBg3JEiKnlqHk/o+bygik3yMENTuBAHQOYy7PwoeVslujBD y03rIual5i15mafAgDpPxQBIr22jxZ6MN+l2D/iqT8yAbDSiF3MKeOHIeWeVt/gNpTFw 2glA== X-Gm-Message-State: AN3rC/5zPoWyrbQOzvMgWSb+NBjHjKOfbxfytDO83NqVLuqvR9Uye3ow 97fSIOWMz/iiQ2Xuap2Gx5P5+d5ZDA== X-Received: by 10.37.171.194 with SMTP id v60mr16719079ybi.100.1493563788198; Sun, 30 Apr 2017 07:49:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.46.18 with HTTP; Sun, 30 Apr 2017 07:49:47 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Date: Sun, 30 Apr 2017 16:49:47 +0200 Message-ID: To: "Mo Zanaty (mzanaty)" Cc: Jonathan Lennox , "avtext@ietf.org" , mmusic Content-Type: multipart/alternative; boundary=001a11487c560b8cfc054e636b4a Archived-At: Subject: Re: [avtext] [MMUSIC] framemarking: add frame size info X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 14:51:54 -0000 --001a11487c560b8cfc054e636b4a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the pointer Mo, I couldn't assist to the IETF in Chicago,so I appreciate so much your response ;). Best!! 2017-03-27 17:10 GMT+02:00 Mo Zanaty (mzanaty) : > Hi Miguel, > > This was discussed in IETF 97 during the AVTEXT session on Frame Marking. > See the slides and minutes. > https://datatracker.ietf.org/meeting/97/session/avtext > > The recommended and agreed solution was to use RID rather than add frame > size > in the Frame Marking header extension. > > Thanks, > Mo > > > From: mmusic on behalf of Miguel Par=C3=ADs D= =C3=ADaz < > mparisdiaz@gmail.com> > Date: Monday, March 27, 2017 at 3:43 AM > To: Jonathan Lennox > Cc: "avtext@ietf.org" , "mmusic@ietf.org" < > mmusic@ietf.org> > Subject: Re: [MMUSIC] [avtext] framemarking: add frame size info > > Hello again, > is there anybody considering this proposal, or nobody see the benefits? > > Kind regards!! > > 2016-11-10 15:18 GMT+01:00 Miguel Par=C3=ADs D=C3=ADaz : > >> Hello, >> in the new draft of sdp-simulcast an "RTP Aspect" section [1] has been >> added, which explains how the media is handled on RTP level. >> >> Specifically, In the Media-Switching Mixer section [2] the same thoughts >> I exposed are said: >> >> This section discusses the behavior in cases where the RTP middlebox >> behaves like the Media-Switching Mixer (Section 3.6.2 ) in RTP >> Topologies [RFC7667 ]. The fund= amental aspect here is that the media >> sources delivered from the middlebox will be the mixer's conceptual >> or functional ones. For example, one media source may be the main >> speaker in high resolution video, while a number of other media >> sources are thumbnails of each participant. >> >> The above results in that the RTP stream produced by the mixer is one >> that switches between a number of received incoming RTP streams for >> different media sources and in different simulcast versions. The >> mixer selects the media source to be sent as one of the RTP streams, >> and then selects among the available simulcast streams for the most >> appropriate one. The selection criteria include available bandwidth >> on the mixer to receiver path and restrictions based on the >> functional usage of the RTP stream delivered to the receiver. An >> example of the latter, is that it is unnecessary to forward a full HD >> video to a receiver if the display area is just a thumbnail. Thus, >> restrictions may exist to not allow some simulcast streams to be >> forwarded for some of the mixer's media sources. >> >> >> In our case to provide this feature, currently we have to depay the RTP >> packets, and apply different types of parses (depending on the codec) to >> read the frame size, which reduces the scalability of the system and hin= der >> the implementation a lot. >> Because of that, I think that having frame size (width and height) info >> in the Frame Marking RTP header extension is quite interesting to implem= ent >> this kind of use cases in a easy and efficient way (the same that an >> audio-level extension header is provided to avoid analysing it in the >> middlebox side). >> >> I am adding MMUSIC group in the thread, because I think that this also >> should be discussed in the context of the simulcast case. >> >> Best!! >> >> Refs >> [1] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast- >> 06#section-7.2 >> [2] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast- >> 06#section-7.2.1 >> >> >> 2016-08-30 12:37 GMT+02:00 Miguel Par=C3=ADs D=C3=ADaz : >> >>> I assume that the media distributor has the information from the SDP (i= t >>> performs the SDP negotiation which each "client"), but the point is tha= t >>> encoders may change the video size depending on the available bandwidth= , >>> the complexivity of the video source, etc., unless the sender forces th= e >>> encoders' configuration with a fix frame size... >>> >>> >>> 2016-08-26 19:07 GMT+02:00 Jonathan Lennox : >>> >>>> (As an individual.) >>>> >>>> In the latest version of simulcast the media distributor would need th= e >>>> RID values, not the PT values, but the idea is the same =E2=80=94 it n= eeds the SDP. >>>> >>>> Note that if the media distributor doesn=E2=80=99t have information fr= om the >>>> SDP it can=E2=80=99t reliably identify the frame marking header extens= ion at all, >>>> since header extension IDs are negotiated. So I=E2=80=99m not sure how= much benefit >>>> there is to putting the size in the header extension. >>>> >>>> That said, if we envision a scenario where encoders might be frequentl= y >>>> changing their video size (in response to available network bandwidth,= or >>>> the like), it might be useful for encoders to be able to indicate the >>>> current size they=E2=80=99re encoding without needing to send updated = SDP all the >>>> time. >>>> >>>> On Aug 26, 2016, at 12:52 PM, Paul E. Jones >>>> wrote: >>>> >>>> Miguel, >>>> >>>> You make the assumption that the media distributor will not see the >>>> SDP, I suppose. While certainly a valid model, I'll admit that I had >>>> personally assumed any media forwarding function would see the SDP (or= at >>>> least be told the PT values and any relevant flow information similar = to >>>> what RFC 6236 provides) and would thus know which PT values correspond= to >>>> what video resolutions if simulcast is employed. >>>> >>>> Paul >>>> >>>> ------ Original Message ------ >>>> From: "Miguel Par=C3=ADs D=C3=ADaz" >>>> To: avtext@ietf.org >>>> Sent: 8/25/2016 10:12:48 AM >>>> Subject: [avtext] framemarking: add frame size info >>>> >>>> Hello, >>>> it would be great having frame size (width and height) info in the >>>> Frame Marking RTP header extension [1]. >>>> >>>> Why? >>>> For example, in the case of using simulcast in an SFU, selecting the >>>> stream by the size would ease the application development and improve = the >>>> experience of the users. >>>> Application developers don't usually have deep knowledge about media >>>> like bitrate, etc., but they know which video size has to be rendered = in >>>> the GUI, which may depend on the client where the app is running: a mo= bile, >>>> a PC with a 13"=C2=B7 screen, a PC with 27" screen, etc. >>>> >>>> In this way and taking a videoconference app as example, if a >>>> participant select another participant to be rendered as main video, t= he >>>> app could ask the SFU to select the video quality that better matches = to >>>> 800x600 size. >>>> >>>> What do you think about this idea? >>>> >>>> Thanks and best regards!! >>>> >>>> Refs >>>> [1] https://tools.ietf.org/html/draft-ietf-avtext-framemarking-02 >>>> >>>> -- >>>> Miguel Par=C3=ADs D=C3=ADaz >>>> ------------------------------------------------------------ >>>> ------------ >>>> Computer/Software engineer. >>>> Researcher and architect in http://www.kurento.org >>>> http://twitter.com/mparisdiaz >>>> ------------------------------------------------------------ >>>> ------------ >>>> >>>> _______________________________________________ >>>> avtext mailing list >>>> avtext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avtext >>>> >>>> >>>> >>> >>> >>> -- >>> Miguel Par=C3=ADs D=C3=ADaz >>> -----------------------------------------------------------------------= - >>> Computer/Software engineer. >>> Researcher and architect in http://www.kurento.org >>> http://twitter.com/mparisdiaz >>> -----------------------------------------------------------------------= - >>> >> >> >> >> -- >> Miguel Par=C3=ADs D=C3=ADaz >> ------------------------------------------------------------------------ >> Computer/Software engineer. >> Researcher and architect in http://www.kurento.org >> http://twitter.com/mparisdiaz >> ------------------------------------------------------------------------ >> > > > > -- > Miguel Par=C3=ADs D=C3=ADaz > ------------------------------------------------------------------------ > Computer/Software engineer. > Researcher and architect in http://www.kurento.org > http://twitter.com/mparisdiaz > ------------------------------------------------------------------------ > --=20 Miguel Par=C3=ADs D=C3=ADaz ------------------------------------------------------------------------ Computer/Software engineer. Researcher and architect in http://www.kurento.org http://twitter.com/mparisdiaz ------------------------------------------------------------------------ --001a11487c560b8cfc054e636b4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the pointer Mo,
I couldn'= ;t assist to the IETF in Chicago,so I appreciate so much your response ;).<= br>
Best!!

2017-03-27 17:10 GMT+02:00 Mo Zanaty (mzanaty) <mzanaty@cisco.= com>:
Hi Miguel,

This was discussed in IETF 97 during the AVTEXT session on Frame Marki= ng.
See the slides and minutes.

The recommended and agreed solution was to use RID rather than add fra= me size
in the Frame Marking header extension.

Thanks,
Mo


From: mmusic <mmusic-bounces@ietf.org> = on behalf of Miguel Par=C3=ADs D=C3=ADaz <mparisdiaz@gmail.com>
Date: Monday, March 27, 2017 at 3:4= 3 AM
To: Jonathan Lennox <jonathan@vidyo.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "mmusic@ietf.org" <= ;mmusic@ietf.org&g= t;
Subject: Re: [MMUSIC] [avtext] fram= emarking: add frame size info

Hello again,
is there anybody considering this proposal, or nobody see the benefits?

Kind regards!!

2016-11-10 15:18 GMT+01:00 Miguel Par=C3=ADs D= =C3=ADaz <mparisdiaz@gm= ail.com>:
Hello,
in the new draft of sdp-simulcast an "RTP Aspect" section [1] has= been added, which explains how the media is handled on RTP level.

Specifically, In the Media-Switching Mixer section [2] the same thoughts I = exposed are said:
   =
This section discusses the behavior in cases where the RTP middlebox
   behaves like the Media-Switching Mixer (=
Section 3.6.2) in RTP
   Topologies [RFC7667].  The fundamental a=
spect here is that the media
   sources delivered from the middlebox will be the mixer's conceptual
   or functional ones.  For example, one media source may be the main
   speaker in high resolution video, while a number of other media
   sources are thumbnails of each participant.

   The above results in that the RTP stream produced by the mixer is one
   that switches between a number of received incoming RTP streams for
   different media sources and in different simulcast versions.  The
   mixer selects the media source to be sent as one of the RTP streams,
   and then selects among the available simulcast streams for the most
   appropriate one.  The selection criteria include available bandwidth
   on the mixer to receiver path and restrictions based on the
   functional usage of the RTP stream delivered to the receiver.  An
   example of the latter, is that it is unnecessary to forward a full HD
   video to a receiver if the display area is just a thumbnail.  Thus,
   restrictions may exist to not allow some simulcast streams to be
   forwarded for some of the mixer's media sources.

In our case to provide this feature, currently we have to depay the RT= P packets, and apply different types of parses (depending on the codec) to = read the frame size, which reduces the scalability of the system and hinder= the implementation a lot.
Because of that, I think that having frame size (width and height) inf= o in the Frame Marking RTP header extension is quite interesting to impleme= nt this kind of use cases in a easy and efficient way (the same that an aud= io-level extension header is provided to avoid analysing it in the middlebox side).

I am adding MMUSIC group in the thread, because I think that this also= should be discussed in the context of the simulcast case.

Best!!


2016-08-30 12:37 GMT+02:00 Miguel Par=C3=ADs D= =C3=ADaz <mparisdiaz@gm= ail.com>:
I assume that the media distributor has the information fr= om the SDP (it performs the SDP negotiation which each "client"),= but the point is that encoders may change the video size depending on the = available bandwidth, the complexivity of the video source, etc., unless the sender forces the encoders' configurati= on with a fix frame size...


2016-08-26 19:07 GMT+02:00 Jonathan Lennox <jonathan@vidyo.= com>:
(As an individual.)

In the latest version of simulcast the media distributor would need th= e RID values, not the PT values, but the idea is the same =E2=80=94 it need= s the SDP.

Note that if the media distributor doesn=E2=80=99t have information fr= om the SDP it can=E2=80=99t reliably identify the frame marking header exte= nsion at all, since header extension IDs are negotiated. So I=E2=80=99m not= sure how much benefit there is to putting the size in the header extension.

That said, if we envision a scenario where encoders might be frequentl= y changing their video size (in response to available network bandwidth, or= the like), it might be useful for encoders to be able to indicate the curr= ent size they=E2=80=99re encoding without needing to send updated SDP all the time.

On Aug 26, 2016, at 12:52 PM, Paul E. Jones <paulej@packetizer.com> wrote:
Miguel,

You make the assumption that the media distributor will not see the SDP, I = suppose.=C2=A0 While certainly a valid model, I'll admit that I had per= sonally assumed any media forwarding function would see the SDP (or at leas= t be told the PT values and any relevant flow information similar to what RFC 6236 provides) and would thus know wh= ich PT values correspond to what video resolutions if simulcast is employed= .

Paul

------ Original Message ------
From: "Miguel Par=C3=ADs D=C3=ADaz" <mparisdiaz@gmail.com>
Sent: 8/25/2016 10:12:48 AM
Subject: [avtext] framemarking: add frame size info

Hello,
it would be great having frame size (width and height) info in the Fra= me Marking RTP header extension [1].

Why?
For example, in the case of using simulcast in an SFU, selecting the s= tream by the size would ease the application development and improve the ex= perience of the users.
Application developers don't usually have deep knowledge about med= ia like bitrate, etc., but they know which video size has to be rendered in= the GUI, which may depend on the client where the app is running: a mobile= , a PC with a 13"=C2=B7 screen, a PC with 27" screen, etc.

In this way and taking a videoconference app as example, if a particip= ant select another participant to be rendered as main video, the app could = ask the SFU to select the video quality that better matches to 800x600 size= .

What do you think about this idea?

Thanks and best regards!!

Refs
[1]=C2=A0https://tools.ietf.org/html/dra= ft-ietf-avtext-framemarking-02

--=C2=A0
Miguel Par=C3=ADs D=C3=ADaz
-----------------------------------------------------------------= -------
Computer/Software engineer.
Researcher and architect in=C2=A0http://www.kurento.org
http://twitter.= com/mparisdiaz
-----------------------------------------------------------------= -------
_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext




--
Miguel Par=C3=ADs D=C3=ADaz
-----------------------------------------------------------------= -------
Computer/Software engineer.
Researcher and architect in http://www.kurento.org
http://twitter.= com/mparisdiaz
-----------------------------------------------------------------= -------



--
Miguel Par=C3=ADs D=C3=ADaz
-----------------------------------------------------------------= -------
Computer/Software engineer.
Researcher and architect in http://www.kurento.org
http://twitter.= com/mparisdiaz
-----------------------------------------------------------------= -------



--
Miguel Par=C3=ADs D=C3=ADaz
-----------------------------------------------------------------= -------
Computer/Software engineer.
Researcher and architect in http://www.kurento.org
http://twitter.= com/mparisdiaz
-----------------------------------------------------------------= -------



--
Miguel Par=C3= =ADs D=C3=ADaz
---------------------------------------------------------= ---------------
Computer/Software engineer.
Researcher and architect = in http://www.kurento.= org
http= ://twitter.com/mparisdiaz
------------------------------------------= ------------------------------
--001a11487c560b8cfc054e636b4a--