[payload] RE: Payload WG notes - Please read

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Tue, 28 July 2015 06:59 UTC

Return-Path: <rachel.huang@huawei.com>
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 37EDB1A21C5 for <payload@ietfa.amsl.com>; Mon, 27 Jul 2015 23:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eEz11b3UO-9t for <payload@ietfa.amsl.com>; Mon, 27 Jul 2015 23:59:57 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5210A1A1DE1 for <payload@ietf.org>; Mon, 27 Jul 2015 23:59:57 -0700 (PDT)
Received: from 172.18.9.243 (EHLO lhreml402-hub.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGP15833; Tue, 28 Jul 2015 01:59:56 -0500 (CDT)
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 28 Jul 2015 07:58:58 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 28 Jul 2015 14:58:54 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: [payload] RE: Payload WG notes - Please read
Thread-Index: AQHQw88dRc8Bj1w5zkONpq1MAxj7sZ3wPKRg
Date: Tue, 28 Jul 2015 06:58:53 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB863AAF31@nkgeml501-mbs.china.huawei.com>
References: <E144AE8E-8DE7-44A7-88B1-00340DEC549D@cisco.com>
In-Reply-To: <E144AE8E-8DE7-44A7-88B1-00340DEC549D@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.144]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/payload/j-9f_IIfUGT6JLQSHh-7L5O8LXg>
Subject: [payload] RE: Payload WG notes - Please read
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2015 06:59:59 -0000

Sorry, didn't notice it until now^^.

Imed: Interleave an IDR, what’s the gain?
Rachel: Only applying interleaving on IDR frames helps to reduce the delay caused by interleaving, which is now considered by some ISPs who provide 4K IPTV services still on DSL access network.

BR,
Rachel

> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Ali C. Begen
> (abegen)
> Sent: Wednesday, July 22, 2015 12:06 AM
> To: payload@ietf.org
> Subject: [payload] Payload WG notes - Please read
> 
> 
> Please have a look and send any corrections to the chairs by July 28th.
> Presenters, please fill in the gaps denoted by a question mark.
> 
> Thanks.
> -acbegen
> 
> IETF 93 - Payload Notes
> Chairs: Roni Even, Ali Begen
> Note takers: Stephan Wenger, Mo Zanaty
> Jabber scribe: Jonathan Lennox
> 
> 
> Payload Status Update Chairs
> https://www.ietf.org/proceedings/93/slides/slides-93-payload-0.pdf
> 
> H265: SDP directorate review by Flemming Andreasen noted no overall
> grammar and no formal grammar for fmtp parameters. No interoperability
> issues, so no change needed, according to Stephan, Magnus Westerlund,
> others. Magnus:
> recommendation in how-to: when you have complex parameters, then you
> should include ABNF.  Otherwise not.
> Stephan: there is an ABNF in the draft for one complex parameter.
> 
> 
> VP9 RTP Payload Format (Magnus Flodman)
> draft-ietf-payload-vp9-00 <http://tools.ietf.org/id/draft-ietf-payload-vp9-00>
> https://www.ietf.org/proceedings/93/slides/slides-93-payload-3.pdf
> 
> Flexible and Non-Flexible GOF (Group of Frames) structure: Mo thinks this may
> be useful for other codecs, authors have no issues with reusing this.
> Stephan noted that other codecs (e.g. H.264/5) have other means to convey
> this within the payload itself not in payload headers.
> 
> 
> Flexible FEC RTP Payload Format (Varun Singh)
> draft-ietf-payload-flexible-fec-scheme-00
> <http://tools.ietf.org/id/draft-ietf-payload-flexible-fec-scheme-00>
> https://www.ietf.org/proceedings/93/slides/slides-93-payload-1.pdf
> 
> Bernard Aboba: How can a sender signal specific FEC patterns, like only protect
> the base layer of SRST RTP streams? Authors clarified that no static signaling
> (e.g. SDP) is necessary since the sender is free to pick dynamic patterns and all
> receivers must handle this.
> 
> Slide 8: open issue:
> Jonathan: putting SSRC into RTP payload is scary (layer violation)
> Mo: we are already in layer violation due to SN; could go Fecframe model
> Jonathan: ??? something about Perc,
> fec over encrypted payload
> 
> Magnus: Dislikes no support for jumbo packets > 4KB. Better to support 64KB
> packets and expand the FEC header. Stephan agrees with expansion.
> 
> Different opinions expressed on whether source flow SSRC(s) should be
> included in the FEC header, or other identifiers like MID or the newly proposed
> ESID/RSID. Also different views on signaling multiple source flows.
> Result: Need a side meeting to decide what source flow identifier is used to
> associate with a FEC repair flow and how to handle multiple source flows.
> Varun will lead and copy the list.
> 
> 
> MELPe Codec (Roni Even for Victor Demjanenko)
> draft-demjanenko-payload-melpe-03
> <http://tools.ietf.org/id/draft-demjanenko-payload-melpe-03>
> https://www.ietf.org/proceedings/93/slides/slides-93-payload-4.pdf
> 
> Stephan has read it and thinks it is a well written RTP payload format draft. No
> other reviewers, so chairs will ask the list to review.
> 
> 
> Interleaved RTP Payload Format (Rachel Huang)
> draft-huang-payload-rtp-interleave-00
> <http://tools.ietf.org/id/draft-huang-payload-rtp-interleave-00>
> https://www.ietf.org/proceedings/93/slides/slides-93-payload-2.pdf
> 
> Jonathan: Note that PT must be the same.
> Rachel: yes
> Jonathan: assumption aggregation never changes number of packets.
> Rachel: yes
> Jonathan: with more flexible sequence number mechanism, you could do better
> Rachel: yes
> Imed: Interleave an IDR, what’s the gain?
> Rachel: ???
> 
> 
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload