Subject: [payload] WGLC comments on draft-ietf-payload-rtp-ancillary-03

From: Thomas Edwards <[email-masked]>
Date: Thu, 16 Jun 2016 03:34:05 +0000

Dear Payload WG,

I have looked at the WGLC comments on draft-ietf-payload-rtp-ancillary-03.
 I believe that I have responses to these comments (although I am still
working on some offer/answer issues based on SDP Directorate comments).
If the group is OK with these, I can edit the I-D and issue a new version.

Commenter: Jonathan Lennox <[email-masked]> Mon, 18 April 2016 15:59
UTC

Comment:  "No mechanism is given to associate the video/smpte291 streams
with their associated video/raw or video/jpeg2000 streams.  In complicated
scenarios (multiple video streams, e.g.) some SDP grouping might be
necessary to provide this association."
Response: How about if the I-D is amended with an example SDP file with
"a=group:LS" to show lip sync grouping as per RFC 5888 between say RFC
4175 video and ANC?

Comment: "The RTP clock rate isn¹t specified.  Presumably it should be the
same as the associated video streams; i.e., normally 90000, but variable
for JPEG2000."
Response: In the description of the timestamp, the I-D states "A 90-kHz
timestamp SHOULD be used".  Based on industry input, I believe this is the
proper level of specificity.

Commenter: James P. Weaver <[email-masked]> Tue, 19 April 2016
13:11 UTC

Comment: "I think that the mime-type should probably not be
video/smpte291, but rather application/smpte291. The data carried here
isn¹t video data, so it seems incorrect to use video as the type."
Response: We did discus this at the WG F2F in Dallas, and my impression is
that the group was OK with video/smpte291 although there were some
dissenters.  My argument is that SMPTE ST 291 Ancillary Data format only
makes sense within a video environment, and frankly it is probably not the
optimal way to carry some of this metadata in a more generic case.  The
broadcast industry appears OK with a video type as far as I have seen
through the Video Services Forum Technical Recommendation TR-03 and the
SMPTE ST 2110 processes which reference the I-D.  Harald Alvestrand
<[email-masked]> Thu, 12 May 2016 07:42 UTC pointed out "If one
wishes to multiplex the video and these packets on the same SDP-negotiated
RTP session without using BUNDLE, the top level mime-type has to be
"video"."  So I'd prefer to keep it video/smpte291 unless there is a
strong consensus in the group against that.

>From the SDP Directorate:

Commenter: Dan Wing <[email-masked]> Thu, 21 Apr 2016 14:42:10 -0700

Comment: "I see the text in 3.1 partially defines the SDP syntax, but is
in a section titled "Media Type Definition".  Much of that is very
specific to SDP (especially the text describing location of comma, use of
"{}", suchlike), and should be in section 3.2, "Mapping to SDP"."
Response: I can move the SDP-specific info in section 3.1 into section 3.2

Comment: "The text needs to if both DID and SDID are required, because I
notice at http://www.smpte-ra.org/smpte-ancillary-data-smpte-st-291, some
DIDs SDIDs, such as 0xa0 ("Audio data in HANC space").  Are such DIDs
without SDIDs illegal to use with SDP, illegal to use with this RTP
Ancillary payload, or anything like that?  The I-D should say something
about DIDs that don't have SDIDs, and how they are expressed in the SDP.
For example is it possible for SMPTE to register a new DID next year which
have no SDID, and how do we want that signaled in SDP?  This may be solved
with a simple, "All DIDs using this RTP Ancillary Payload format will
always have SDIDs registered with them by SMPTE.", which may well exist
somewhere in the document already and I missed it."
Response: It is true that DID 0x80 (deletion) has no required SDID.  Some
of the audio ANC packets are "Type 1" ANC packets that have Data Block
Numbers (DBN) in place of where "Type 2" ANC packets have SDIDs.  In
either case, one would want to filter based on just the DID.  I can make
this clear is section 3.2.

Comment: "I'd like to see an ABNF syntax of the fmtp parameters, including
things like how long the hex values can be, and whether they can have both
lower and upper case."
Response: I can add the ABNF.

-Thomas

-- 
Thomas Edwards	
VP Engineering & Development
FOX Networks Engineering and Operations
[email-masked]
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035

---

From: "Ali C. Begen" <[email-masked]>
Date: Wed, 22 Jun 2016 12:41:37 +0300

Hi Thomas

Here are my comments. First, please take of the nits for your draft as
listed here:
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-payload-rtp-ancillary-03.txt

Second, please wait for a response from Jonathan, James and Dan before
moving on.

Further comments inline.

> "a=group:LS" to show lip sync grouping as per RFC 5888 between say RFC

I am ok with this approach. LS grouping is generic enough to sync any two
streams.

> proper level of specificity.

I think Jonathan wants to see this mentioned in Section 3.1 under Required
parameters.

> strong consensus in the group against that.

OK.

> Response: I can move the SDP-specific info in section 3.1 into section 3.2

Please do so.

> this clear is section 3.2.

Good idea.

> Response: I can add the ABNF.

Thanks.

> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
>

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 23 Jun 2016 13:56:22 +0000

On Jun 22, 2016, at 5:41 AM, Ali C. Begen <[email-masked]<mailto:[email-masked]>> wrote:

Commenter: Jonathan Lennox <[email-masked]<mailto:[email-masked]>> Mon, 18 April 2016 15:59
UTC

I am ok with this approach. LS grouping is generic enough to sync any two streams.

This seems good to me.

I think Jonathan wants to see this mentioned in Section 3.1 under Required parameters.

Yes.

Additionally, since JPEG2000 can optionally have clock rates other than 90 kHz, I would presume that if that’s used, the ancillary data should have a matching clock rate.

(Unless no one uses JPEG2000 at a clock rate other than 90 kHz, and that usage can be considered deprecated.)