Re: [payload] Pos-Dir last call review for draft-ietf-payload-rtp-vc2hq-05
"Roni Even" <ron.even.tlv@gmail.com> Sat, 12 May 2018 05:22 UTC
Return-Path: <ron.even.tlv@gmail.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 9734012D86F;
Fri, 11 May 2018 22:22:19 -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, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_PASS=-0.001, URIBL_BLOCKED=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 05JJtji1oXe9; Fri, 11 May 2018 22:22:17 -0700 (PDT)
Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com
[IPv6:2a00:1450:400c:c0c::234])
(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 6E64E12D86D;
Fri, 11 May 2018 22:22:17 -0700 (PDT)
Received: by mail-wr0-x234.google.com with SMTP id o4-v6so7158231wrm.0;
Fri, 11 May 2018 22:22:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:references:in-reply-to:subject:date:message-id:mime-version
:content-transfer-encoding:content-language:thread-index;
bh=Q9H7Ro52NQHh2ySmN6+Pfi5/DIQSbyP8k5lfwNgB8vY=;
b=WcNI+Iar37fqgLANDKCo+TibHE/F+aYX7Za7ITtghALash5SutRH4zze7mXqn8LNbd
tmOAOJ/qeg9Sxm0X15guxFv/D5kuzDxhSei+6jbj/c5Lh0MZUQ62GpNusYnVdiUYAv3H
sXWDh+MmrOe4gN96l0ckIZR6l5IKKFSqlSD2vP5ggqcDaCNRtpJMJ4RYMbiJRtD7Feq5
APLu9m8+2nbRih16+ZXkzpzQMYhzgjNhGkAG6Q0Ap7e/yvnIaW+K2f0iWgU4l1wunGWf
UzLHvgOXFvTw2bHizyGEz4FzISZFh6nYyzpW60e4Wifcu1Hb1MMziWgfJU2d8czI0jCJ
C3ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:references:in-reply-to:subject:date
:message-id:mime-version:content-transfer-encoding:content-language
:thread-index;
bh=Q9H7Ro52NQHh2ySmN6+Pfi5/DIQSbyP8k5lfwNgB8vY=;
b=D+C1cif89kXSUTaJ1i9um2Gzwau7zIghUC1Yv1FgsUCCEfypWCeDBm9QAingwAnMjA
xSkLPDymQBcxcLK3XguFhJ8xENleObtiHWxgLqFPio230JW0ZAOr9L8hWuyRiAI3mn7P
91pDqwQ8UhLo0yeRUADggoUR/e/KoqFph2bEh2aCACUAUcgEMhZNxH1TYODsrwBVsJk0
QxKrcbaCH0R9Ml/esF+2tBgfRPAfP02Z2W4w6J7Zoylw4KxahEotxnOcwfZPQjTSk5M8
60zorJIRlpAs8/Rn8U7baKrKLfqkk4mqzkuhzSVfKDzy8hu9wRUuWvXYKbFuZS6S0JQg
rzMA==
X-Gm-Message-State: ALKqPwcbzIOSG4ij3d27Yc03heNdW3mk3vozFQInrIAIR7tnVNiPG2Bj
mWrLHOBJCuPuswBsWespJdUF9Q==
X-Google-Smtp-Source: AB8JxZql+czIvqo8ld2MToE1Ery2K0na9ehE9kX2/E6DVVTZ5BpwwHPrZmEcGAk+zpuy01yMUJIesQ==
X-Received: by 2002:adf:b979:: with SMTP id
b54-v6mr1166002wrg.265.1526102535826;
Fri, 11 May 2018 22:22:15 -0700 (PDT)
Received: from RoniPC (bzq-79-177-57-250.red.bezeqint.net. [79.177.57.250])
by smtp.gmail.com with ESMTPSA id m134-v6sm4402008wmg.13.2018.05.11.22.22.14
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Fri, 11 May 2018 22:22:14 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>, <ops-dir@ietf.org>,
<draft-ietf-payload-rtp-vc2hq.all@ietf.org>, <payload@ietf.org>
References: <88bea593-3697-9626-4f20-953f8f428f41@auckland.ac.nz>
In-Reply-To: <88bea593-3697-9626-4f20-953f8f428f41@auckland.ac.nz>
Date: Sat, 12 May 2018 08:19:52 +0300
Message-ID: <02f801d3e9b0$dc018780$94049680$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: he
Thread-Index: AQFYyCsWpNYasGf9eD1RsJwTGPgXKKUh0JQQ
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/_W3u2j3wcx_NVClgUYIYWeRI5zY>
Subject: Re: [payload] Pos-Dir last call review for
draft-ietf-payload-rtp-vc2hq-05
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: Sat, 12 May 2018 05:22:20 -0000
Hi,
Thanks for the review
About section 4.1. The pt number is negotiated in the signaling , for
example using SDP see section 6.2. This is how it works for all payload type
numbers who are dynamically allocated
m=video 30000 RTP/AVP 112
a=rtpmap:112 vc2/90000
a=fmtp:112 profile=HQ;version=3;level=0
the pt = 122 and it is mapped to vc2
Roni Even
> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Nevil
Brownlee
> Sent: Saturday, May 12, 2018 5:55 AM
> To: ops-dir@ietf.org; draft-ietf-payload-rtp-vc2hq.all@ietf.org;
> payload@ietf.org
> Subject: [payload] Pos-Dir last call review for
draft-ietf-payload-rtp-vc2hq-05
>
>
> Reviewer: Nevil Brownlee
> Review Result: Ready
>
> I have reviewed this document as part of the Operational directorate's
ongoing
> effort to review all IETF documents being processed by the IESG.
> These comments were written with the intent of improving the operational
> aspects of the IETF drafts. Comments that are not addressed in last call
may be
> included in AD reviews during the IESG review. Document editors and WG
> chairs should treat these comments just like any other last call comments.
>
> "This memo describes an RTP Payload format for the High Quality (HQ)
> profile of SMPTE Standard ST 2042-1 known as VC-2. This document
> describes the transport of HQ Profile VC-2 in RTP packets and has
> applications for low-complexity, high-bandwidth streaming of both
> lossless and lossy compressed video."
>
> This draft simply describes in detail the way in which a stream of VC-2
> information must be carried ina stream of RTP packets. It's well-written,
with
> sufficient detail to allow for inter-operating implementations.
> It's Security Considerations are clear. As with all documents of this
kind,
> operators will need to be sure that the implementations of this kind of
RTP
> stream do conform to this draft's eventual RFC.
>
> I noticed a few slightly puzzling things:
>
> Section 4.1 Payload Type says that the PT is "A dynamically allocated
> payload type field that designates the payload as VC-2 coded video."
> Given that it's dynamically allocated, how does a VC-2 receiver know
> what value has been allocated for PT?
>
> Section 4.4 has two lists of acceptable Parse Code values. but those
> sentences end with 'and'. Should that really be 'or', indicating
> that any of the listed values of allowed?
>
> Cheers, Nevil
>
> --
> --------------------------------------------------
> Nevil Brownlee Computer Science Department | ITS
> Phone: +64 9 373 7599 x88941 The University of Auckland
> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
- [payload] Pos-Dir last call review for draft-ietf… Nevil Brownlee
- Re: [payload] Pos-Dir last call review for draft-… Roni Even