Re: [AVTCORE] Adding information to draft-ietf-avtext-framemarking non-scalable extension

"Mo Zanaty (mzanaty)" <mzanaty@cisco.com> Mon, 26 June 2017 19:11 UTC

Return-Path: <mzanaty@cisco.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FFC126C3D for <avt@ietfa.amsl.com>; Mon, 26 Jun 2017 12:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 dV4cX58cCAPd for <avt@ietfa.amsl.com>; Mon, 26 Jun 2017 12:11:45 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5051126B71 for <avt@ietf.org>; Mon, 26 Jun 2017 12:11:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8524; q=dns/txt; s=iport; t=1498504304; x=1499713904; h=from:to:subject:date:message-id:mime-version; bh=hR1VH+9iUM+OO4Nfk2g/mTacaw4lnve1oQTQqM4eSZ0=; b=GZd0SKPO99ey2+kbVuL00GHCv14aUhLLh34xewnbnsVFQHxUogri72Gr g2CyfsjD4oBzSK9gT9QbrRXmki7iR2Mew1q6vYLCkYK/PY/fIphXYz6VV GXAywPh/PrP2ckfDoJ0v3yf7bg7o6qhPh7xUIk8RhWtLt3miyMP0CuQ0n Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AAAQA7W1FZ/51dJa1dGgEBAQECAQEBAQgBAQEBgm88LWKBDQeNfpFikE+FK4IRgl6DRoJvPxgBAgEBAQEBAQFrKIUYAQYtOwoZAQgRAwECKDkUCQoEARKJSGSzEotZAQEBAQEFAQEBAQEjgyeDTIUFhEZEhVQFkQmNYAKTZZISlSABHzg/S3QVhVYcGYFNdoZ3gTKBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.39,397,1493683200"; d="scan'208,217";a="446096638"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2017 19:11:43 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v5QJBesT007463 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Jun 2017 19:11:40 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 26 Jun 2017 14:11:40 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Mon, 26 Jun 2017 14:11:40 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Roni Even <roni.even@huawei.com>, "avt@ietf.org" <avt@ietf.org>
Thread-Topic: [AVTCORE] Adding information to draft-ietf-avtext-framemarking non-scalable extension
Thread-Index: AQHS7rAKF2jlKp9cb0q1fDdcNPVwmA==
Date: Mon, 26 Jun 2017 19:11:40 +0000
Message-ID: <D576D192.6F8FE%mzanaty@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.3.170325
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.175.227]
Content-Type: multipart/alternative; boundary="_000_D576D1926F8FEmzanatyciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/wA0Nxco-1LD2Ww5LlZ0WW4DRCtE>
Subject: Re: [AVTCORE] Adding information to draft-ietf-avtext-framemarking non-scalable extension
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jun 2017 19:11:47 -0000

Hi Roni,

Low motion can be inferred from low bitrate. But I don't see how any low motion indicator is useful for discard decisions. If you discard the wrong packets, the distortion will be even more extreme for low motion/bitrate content, since the focus is concentrated on one or few regions of low motion which are very easy to corrupt with a single discarded packet. If you get lucky and discard the right packets (skip blocks of static regions), that is just plain luck with no help from frame marking.

Priority bits are arguably more useful for discard decisions. However, when multiple frames are truly discardable (e.g. they are never used as references), there is usually a temporal layer hierarchy that can be used to infer the priority from TID.

I would like to hear from others if there is any strong argument for including or excluding a low motion indication bit or priority bits.

Thanks,
Mo


From: avt <avt-bounces@ietf.org<mailto:avt-bounces@ietf.org>> on behalf of Roni Even <roni.even@huawei.com<mailto:roni.even@huawei.com>>
Date: Thursday, May 18, 2017 at 5:11 AM
To: "avt@ietf.org<mailto:avt@ietf.org>" <avt@ietf.org<mailto:avt@ietf.org>>
Subject: [AVTCORE] Adding information to draft-ietf-avtext-framemarking non-scalable extension

Hi,
The current support for non-scalable frame marking provide limited information for making good decisions about which packets to drop in congestion case. Currently there is only 1 bit for marking discardable packets.

I propose using three of the remaining  four bits (currently 0000) with the following semantics:

Low motion bit (M) - specifying that this stream or the current packets have low motion (example - a conference room meeting ), removing them will just reduce the frame rate with less artifacts comparing with a live video of a basketball game.
Priority (P) two bits - allowing to prioritize frames in a stream. For example if we have a sequence (IBBBBPBBB...) even though all B frames may be defined as discardable, they may have different relation to the other frames and by using priority we can make better discarding decisions.

The way it may work for example  is that when there is a need to discard packets  the middlebox will choose from the discardable packets the ones with low motion and low priority and continue dropping low motion and higher priority. The dropping policy should be implementation dependent.


Roni Even