Re: [payload] Addressing comments on 2nd WGLC of draft-ietf-payload-rtp-ancillary-08

Thomas Edwards <Thomas.Edwards@fox.com> Wed, 03 May 2017 21:51 UTC

Return-Path: <Thomas.Edwards@fox.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4D91294BC for <payload@ietfa.amsl.com>; Wed, 3 May 2017 14:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxgroupinc.onmicrosoft.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 eR02uIvMLDlU for <payload@ietfa.amsl.com>; Wed, 3 May 2017 14:51:13 -0700 (PDT)
Received: from mx0a-00195501.pphosted.com (mx0a-00195501.pphosted.com [67.231.149.164]) (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 6D767129B43 for <payload@ietf.org>; Wed, 3 May 2017 14:49:17 -0700 (PDT)
Received: from pps.filterd (m0087374.ppops.net [127.0.0.1]) by mx0a-00195501.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v43Ll6uD025446 for <payload@ietf.org>; Wed, 3 May 2017 14:49:14 -0700
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0119.outbound.protection.outlook.com [207.46.163.119]) by mx0a-00195501.pphosted.com with ESMTP id 2a7h26shak-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <payload@ietf.org>; Wed, 03 May 2017 14:49:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=FoxGroupInc.onmicrosoft.com; s=selector1-fox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xh7MR3Bv+zB7IYaH8ZMGpLQBQUZ73SZkIiODctf8j8k=; b=Zkod0PQMkWT/vpWlYq8USYrHpwfZcEpnOHGKlAyMVXJSm7bV+pztt60CQ2WdPJ5gWLob1RaUra6J5AxCrVGeSzWDQf1i20DkHWWH2j6aeIwsQLBFY0Rs2NTwgsDiP319KLM1lPLaelu40iPAMFgF2y9BNeVp/A8vP4/bRtlmo4s=
Received: from CY4PR05MB3109.namprd05.prod.outlook.com (10.172.157.7) by CY4PR05MB3109.namprd05.prod.outlook.com (10.172.157.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Wed, 3 May 2017 21:49:11 +0000
Received: from CY4PR05MB3109.namprd05.prod.outlook.com ([10.172.157.7]) by CY4PR05MB3109.namprd05.prod.outlook.com ([10.172.157.7]) with mapi id 15.01.1075.010; Wed, 3 May 2017 21:49:11 +0000
From: Thomas Edwards <Thomas.Edwards@fox.com>
To: "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Addressing comments on 2nd WGLC of draft-ietf-payload-rtp-ancillary-08
Thread-Index: AQHSw6cKJHsTJYrHE0yJGid5ElJJq6HissNP///+xwA=
Date: Wed, 03 May 2017 21:49:11 +0000
Message-ID: <5963166F-3FCC-4B88-8F60-1CBF4F5CFC0C@fox.com>
References: <26ED0D58-E6D6-4DD7-9801-4556FF67AAC2@fox.com> <B1D49063AD5FBD4688F3EEDEC68B2017C38150C0@bgb01xud1011>
In-Reply-To: <B1D49063AD5FBD4688F3EEDEC68B2017C38150C0@bgb01xud1011>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1b.0.161010
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=fox.com;
x-originating-ip: [216.205.246.236]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR05MB3109; 7:tYwwNw5OOW1wZiT4R/Zw6kvXvLERwXbulexGh59OE9ivJ7pc8We+aC9u4XNP6mGT9P4ezYI7jtDNoeE7CRUn6UcUTRV8Qr8YOTVMBwVD+dGvcwvufAutQ8RYAQNYG7bYhxPMAAEIm3zuTEmAgIMQ17VujxKT555dQJ09d5EiX5bObX4s9LPzLx1jl7JQA8UCT8HbaeQVKoGGDjPSFUcess51dRsyMA0QZhG8DbtLraLgwkPdsDYjHen60bO8lF/unqWTnCsxCEFXoRvcQPGbUsRxA/ePTpkfVZGHcNvYtaqY30DQxxIesSj01cdxDWXSZRSt4XzULfj4PQOv+UZ1Lg==
x-ms-office365-filtering-correlation-id: 5a0bd7d5-cfe2-44c1-c2f1-08d4926e3c16
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY4PR05MB3109;
x-microsoft-antispam-prvs: <CY4PR05MB3109AECA558A348E7981A55094160@CY4PR05MB3109.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(127952516941037);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:CY4PR05MB3109; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3109;
x-forefront-prvs: 029651C7A1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39450400003)(39410400002)(39400400002)(39850400002)(24454002)(377454003)(25786009)(3660700001)(6512007)(6486002)(77096006)(66066001)(5640700003)(86362001)(53546009)(54356999)(5660300001)(50986999)(122556002)(76176999)(478600001)(229853002)(6506006)(53936002)(6246003)(99286003)(2950100002)(102836003)(6916009)(3846002)(110136004)(38730400002)(6116002)(2501003)(6436002)(82746002)(8936002)(8676002)(1730700003)(81166006)(83716003)(83506001)(3280700002)(2906002)(189998001)(33656002)(36756003)(7736002)(305945005)(2351001)(2900100001)(230783001)(4001350100001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3109; H:CY4PR05MB3109.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <F7A836F904D4C04E967880165D5BFF2C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: fox.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 21:49:11.6303 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3109
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_15:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705030380
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/Jp2vk9mIUSlwrDuv7FQPm5l89ac>
Subject: Re: [payload] Addressing comments on 2nd WGLC of draft-ietf-payload-rtp-ancillary-08
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 03 May 2017 21:51:15 -0000

Sorry, for some reason the C bit change did not get noted.

The original text from SMPTE ST 2038-2008 is:

“c_not_y_channel_flag: For HD, this flag, when set to ‘1’, indicates the ANC data corresponds to the color difference channel. When set to ‘0, this flag indicates the ANC data corresponds to the luminance channel. For SD, this flag shall be set to ‘0’.”

I think it is best to keep the description close to this proven data model, so I suggest that we simply change the first sentence of the C bit ANC data packet header field to read:

“For HD or UHD signals, this flag, when set to "1", indicates that the ANC data corresponds to the color-difference channel (C).”

Regarding the link number, I see your argument that it really should be carried in the ANC data packet header fields.  We have a few reserved bits now after Horizontal_Offset, so I guess we can use them.

To try to do this correctly, I think we should reference the SMPTE ST 352 use of bits b7 to b5 of byte 4 of the default payload identifier as a channel assignment field for channels 1-8.

This would result in a new ANC data packet payload header field:

“Channel Assignment: 4 bits

This field can indicate the channel number of a multi-channel link used to transport the ANC data packet.
If the first bit of this field is ‘0’, then this field provides no guidance regarding the channel placement of the ANC data packet.
If the first bit of this field is ‘1’, then the following bits MUST carry the channel identification information of section 5.5.1 of SMPTE ST 352 contained in byte 4 of the payload identifier.
The second bit of the channel assignment field carries bit b7 of byte 4 of the payload identifier, the third bit carries bit b6, and the fourth bit carries bit b5.”

With the addition of the Channel Assignment ANC data packet header field, I think it is appropriate to remove LinkNumber from the Media Type Definition.  In truth, looking through various multi-link SDI interfaces and their use of SMPTE ST 352, I’m not 100% sure the current definition of LinkNumber would always be clear & appropriate, but the bits in Byte 4 from SMPTE ST 352 will always be clear.

-Thomas

On 5/3/17, 7:55 AM, "John Fletcher" <John.Fletcher@bbc.co.uk> wrote:

    Regarding the C bit, I don't see any change.
    I suggest: "If the data corresponds to the color-difference data channel of the SDI interface, the C flag shall be set to "1".  If the data corresponds to the luma data channel of the SDI interface, or the interface does not have separate luma and color-difference data channels, or the data is not associated with an SDI interface, the C flag shall be set to "0"."
    
    And a further comment...
    The LinkNumber parameter cannot be used if there is data from more than one link in the RTP stream.  And a single number is inadequate for interfaces that mave multiple links and multiple data streams per link.  If it is a requirement to  reproduce link/data stream when going SDI->RTP->SDI then link number and data stream number need to be in the payload header for each ANC packet.
    
    John