IETF Logo Mail Archive

Re: [AVTCORE] [payload] RFC 6184 H.264 RPSI/SLI usage

Stephan Wenger <stewe@stewe.org> Wed, 20 January 2016 02:46 UTC

Return-Path: <stewe@stewe.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE911A026F; Tue, 19 Jan 2016 18:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 ameN-J0eqvXd; Tue, 19 Jan 2016 18:46:32 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436091A026E; Tue, 19 Jan 2016 18:46:32 -0800 (PST)
Received: from BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) by BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 02:46:28 +0000
Received: from BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) by BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) with mapi id 15.01.0365.024; Wed, 20 Jan 2016 02:46:28 +0000
From: Stephan Wenger <stewe@stewe.org>
To: "Coban, Muhammed" <mcoban@qti.qualcomm.com>, "payload@ietf.org" <payload@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Thread-Topic: [payload] [AVTCORE] RFC 6184 H.264 RPSI/SLI usage
Thread-Index: AdFSLISjC0AK+03WSKylXe5LQ8T2mQAvS9KA
Date: Wed, 20 Jan 2016 02:46:28 +0000
Message-ID: <E8AEA1B0-196A-4047-AB83-76EE7604C2F4@stewe.org>
References: <d019221a0db94127b1e1148c6401531f@nalasexr02e.na.qualcomm.com>
In-Reply-To: <d019221a0db94127b1e1148c6401531f@nalasexr02e.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.174.30.183]
x-microsoft-exchange-diagnostics: 1; BLUPR17MB0275; 5:UGarBCnT3LLtCD9pg9WvPiHbpstIHvLqh2u/B++N6Qb4ynEXKGXdT5JWCMdVL6xFUviiiaTYehlRsMMRetJiXLLoBkzobVOhdK61VgNToJtWMv/D0LGl9bM0VhUctnwPaoGWVv/EH9N9IgZn8VEO/Q==; 24:9HblEjhq78364RgFoG++39RhV4almaB3pPtU3zRY7LXcQiZMqpjnLBLSeL7YA43ZzTno2XD5cGQgCLMRARHFWXd95qEXX03zPyDiwZajwlo=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0275;
x-ms-office365-filtering-correlation-id: 309d996a-c248-4926-af7b-08d32143e5b8
x-microsoft-antispam-prvs: <BLUPR17MB0275C898D7727FDBB119464FAEC20@BLUPR17MB0275.namprd17.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR17MB0275; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0275;
x-forefront-prvs: 0827D7ACB9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(11100500001)(92566002)(77096005)(15975445007)(82746002)(87936001)(10400500002)(5004730100002)(2950100001)(83716003)(101416001)(66066001)(33656002)(19625215002)(106356001)(105586002)(19617315012)(99286002)(16236675004)(122556002)(54356999)(76176999)(50986999)(107886002)(40100003)(86362001)(5001960100002)(2906002)(2900100001)(97736004)(189998001)(5001770100001)(2201001)(2501003)(5002640100001)(81156007)(19580405001)(5008740100001)(19300405004)(6116002)(790700001)(19580395003)(586003)(102836003)(36756003)(1220700001)(3846002)(1096002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR17MB0275; H:BLUPR17MB0275.namprd17.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_E8AEA1B0196A4047AB8376EE7604C2F4steweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2016 02:46:28.4201 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0275
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/kdBn6y7EISE_bki_OxYZwxl-CSo>
Subject: Re: [AVTCORE] [payload] RFC 6184 H.264 RPSI/SLI usage
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 20 Jan 2016 02:46:35 -0000

Hi Muhammed,
The (codec-) native RPSI bit string of 4585 was meant to be exactly that—a codec-defined bit string.  H.263+ Annex N defines such a bit string in sections N.3.1 and N.4.  There is no equivalent for H.264, so conceptually RPSI cannot be used for H.264.  (Nor for H.265, VPx, …).  If people were interested in reference picture selection based on feedback, they would either create a mapping in the responsible video coding standard group, or use the H.271 route.
As you correctly remark, H.271 includes an RPSI-like equivalent for H.264. I know of one system (and there may have been more) that used the H.271 feedback message for H.264 over H.323/H.245.  I’m not aware of anyone using it over RTCP.  There was an effort underway to create an update for H.271 to support H.265; that effort died the death of lack of resources, but it could be restarted.  ITU-T Q1/16 would be the right group to do so.
As for SLI’s PictureID and H.264, again, there is no defined mapping.  frame_num would probably work in most cases, but to satisfy interop and standardization requirements, that would need to be documented (probably in an RFC updating 6184).
Do you guys have more than academic interest in any of these?  It’s not hard to define them, but would we spend our efforts for anything beyond creation of additional pages of standards (and patents :-)?
Stephan



From: payload <payload-bounces@ietf.org<mailto:payload-bounces@ietf.org>> on behalf of "Coban, Muhammed" <mcoban@qti.qualcomm.com<mailto:mcoban@qti.qualcomm.com>>
Date: Monday, January 18, 2016 at 12:28
To: "payload@ietf.org<mailto:payload@ietf.org>" <payload@ietf.org<mailto:payload@ietf.org>>, "avt@ietf.org<mailto:avt@ietf.org>" <avt@ietf.org<mailto:avt@ietf.org>>
Subject: [payload] [AVTCORE] RFC 6184 H.264 RPSI/SLI usage

Hi,

There seems to be no specification of Native RPSI bit string and PictureId field definitions for H.264  regarding RFC 4585 RPSI and SLI messages. RFC 6184 doesn’t specify anything for these fields for H.264. Only thing I can find is the RFC 5104 referencing H.271 specification that defines a message that is similar to RPSI for H.264, but I am not sure whether this is widely accepted/used.  What is used for H.264 specific fields for RPSI and SLI?

This issue was raised before, but had no replies on AVTCORE reflector.

https://www.ietf.org/mail-archive/web/avt/current/msg14709.html

Best regards,

Muhammed Coban

v2.23.0 | Report a Bug | By Email