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

From: Thomas Edwards <[email-masked]>
Date: Tue, 12 Jul 2016 22:21:27 +0000

I'll add into the Media Type Definition / Required Parameters that the "Rate" parameter SHOULD be 90 kHz.

I understand the comment about matching clock rates to associated video streams, and I think a SHOULD is reasonable here:

"When an ANC RTP stream is to be associated with an RTP video stream, the RTP timestamp rates SHOULD be the same to ensure that ANC data can be associated with the appropriate frame or field."

-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: Jonathan Lennox <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 23, 2016 at 6:56 AM
To: "Ali C. Begen" <[email-masked]<mailto:[email-masked]>>
Cc: FNG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [payload] WGLC comments on draft-ietf-payload-rtp-ancillary-03

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

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?

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

This seems good to me.

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.

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.)

---

From: "Roni Even" <[email-masked]>
Date: Sun, 17 Jul 2016 22:13:34 +0300

Hi Thomas,

Any plans to update the document so we can progress it

Roni Even

From: payload [mailto:[email-masked]] On Behalf Of Thomas Edwards
Sent: Wednesday, July 13, 2016 1:21 AM
To: Jonathan Lennox; Ali C. Begen
Cc: [email-masked]
Subject: Re: [payload] WGLC comments on draft-ietf-payload-rtp-ancillary-03

I'll add into the Media Type Definition / Required Parameters that the
"Rate" parameter SHOULD be 90 kHz.

I understand the comment about matching clock rates to associated video
streams, and I think a SHOULD is reasonable here:

"When an ANC RTP stream is to be associated with an RTP video stream, the
RTP timestamp rates SHOULD be the same to ensure that ANC data can be
associated with the appropriate frame or field."

-Thomas

-- 

Thomas Edwards 

[email-masked]

Phone: +1.310.369.6696

10201 West Pico Blvd.

Los Angeles, CA 90035

From: Jonathan Lennox <[email-masked]>
Date: Thursday, June 23, 2016 at 6:56 AM
To: "Ali C. Begen" <[email-masked]>
Cc: FNG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [payload] WGLC comments on draft-ietf-payload-rtp-ancillary-03

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

Commenter: Jonathan Lennox <[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.)

---

From: Thomas Edwards <[email-masked]>
Date: Mon, 18 Jul 2016 18:27:40 +0000

Here is the complete comment resolution on WGLC for
draft-ietf-payload-rtp-ancillary-03.

My belief is that all comments have been resolved, and I am ready to
upload an 04 version if the WG approves.

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

Comment:
"The offer/answer section is very vague and needs work, assuming anyone
cares about using this format with offer/answer. (If no one does,
presumably it should say that use with offer/answer is undefined, but that
would be unfortunate.)"

Resolution:
Added: "3.3.  Offer/Answer Model and Declarative Considerations

   Receivers may with to receive ANC data streams with specific DID_SDID
   parameters.  Thus when offering ANC data streams using the Session
   Description Protocol (SDP) in an Offer/Answer model [RFC3264] or in a
   declarative manner (e.g., SDP in the Real-Time Streaming Protocol
   (RTSP) [RFC2326] or the Session Announcement Protocol (SAP)
   [RFC2974]), the offerer may provide a list of ANC streams available
   with specific DID_SDID parameters in the fmtp line.  The answerer may
   respond with a all or a subset of the streams offered along with fmtp
   lines with all or a subset of the DID_SDID parameters offered.  Or
   the answerer may reject the offer."

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."

Resolution:
Show an example SDP file with "a=group:LS" lip sync grouping between video
and ANC as per RFC 5888.

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."
[I think Jonathan wants to see this mentioned in Section 3.1 under
Required parameters.]

Resolution:
In the description of the timestamp, the I-D states "A 90-kHz timestamp
SHOULD be used"
However I have added this under Required Parameters as well.

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

Comment:
"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."

Resolution:
Added: "When an ANC RTP stream is to be associated with an RTP video
stream, the RTP timestamp rates SHOULD be the same to ensure that ANC data
can be associated with the appropriate frame or field."

From: James P. Weaver <[email-masked]>
Date: 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."

Resolution:
"Ali C. Begen <[email-masked]> Tue, 19 April 2016 13:40 UTC: "I believe
this was discussed in the session during Thomas' first presentation. The
room was somewhat split IIRC. I personally prefer application/smpte291 as
well but someone had an argument for the video mime-type, which I cannot
recall right now."

Thomas Edwards <[email-masked]> "The argument for video/smpte291
is that SMPTE ST 291 Ancillary Data format only makes sense within a video
environment, it has some inherent links to SDI, 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 Media Type as shown
through the Video Services Forum Technical Recommendation TR-03 and the
draft SMPTE ST 2110 reference of the I-D."

Harald Alvestrand <[email-masked]> Thu, 12 May 2016 07:42 UTC: "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"."

From: Dan Wing <[email-masked]>
Date: 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"."

Resolution: 
Moved 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."

Resolution:
Added in Section 3.1 that "Type 1" ANC packets (which do not have SDIDs
defined) SHALL be labeled with SDID=0x00.

From: Dan Wing <[email-masked]>
Date: Fri, 22 Apr 2016 13:23:43 -0700

Comment:
"[the offer/answer section] does not discuss what happens if there isn't a
match of what is offered and what the answerer can receive.  The I-D
should explain if the a=fmtp is returned empty, or if the entire offer is
rejected."

Resolution:
Added answerer must provide all or a subset of DID_SDID pairs in fmtp
line, or reject offer.

From: Paul Kyzivat <[email-masked]>
Date: Sat, Apr 23, 2016 at 4:51 AM

Comment:
"[the offer/answer section] *doesn't* say *clearly* how the fmtp in the
answer is to be constructed - what the relationship (if any) is to that in
the offer, should be."

Resolution:
Added answerer must provide all or a subset of DID_SDID pairs in fmtp
line, or reject offer.

Comment:
"I infer that the fmtp in the answer should be the same or a subset of
that in the offer."

Resolution:
Made clear that the answer should be all or a subset.

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."

Resolution:
The ABNF as per RFC 5234 of the fmtp line shall be:

TwoHex = "0x" 1*2(HEXDIG)
DidSdid = "DID_SDID={" TwoHex "," TwoHex "}"
FormatSpecificParameters = DidSdid *(";" DidSdid)

From: Kjetil Oftedal <[email-masked]>
Date: Sun, 26 Jun 2016 15:24:56 +0200

Comment:
"This new draft only has 11-bit line numbers with the effect of limiting
the supported
video rasters to 2047 lines. The emerging 4K/UHD standards on the other
hand has around
2160 active lines, thus not fully supported.  There is a similar issue
with the Horizontal_Offset field. This field is limited to 4096 (12-bits).
Ancillary data can be carried in the horizontal blanking/HANC of a
SDI-signal, which starts after the active
video section, thus it is barley reachable in 3840/UHD formats."

Resolution:
"Line_Number" and "Offset" refer to the location of ANC data within an SDI
raster, not active video.  Several professional video vendors have told me
that since 2160 line professional video is carried in a quad mux, the SDI
line numbers are not going to change.  Moreover, it is expected that ANC
data will only be carried in one quadrant of the mux.  Going forward, the
industry seeks to move away from linkage between SDI lines and location of
ANC packets anyway, so it is expected that SDI raster location data will
no longer be required soon.  Thus I think it is best to maintain
compatibility with the existing SMPTE ST 2038 data model.

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

Comment:
"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"

Resolution:
Obsolete normative reference: RFC 4288 replaced with RFC 6838.

From: Leigh Whitcomb <[email-masked]>
Date: Thu 14 Jul 2016

Comment:
"Be clear than ANC_count can be 0, especially for allowing an RTP packet
with marker bit and no ANC data"

Resolution:
Added

From:  Roni Even <[email-masked]>
Date:  Sunday, July 17, 2016 at 12:13 PM
To:  FNG <[email-masked]>, "'Ali C. Begen'" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  RE: [payload] WGLC comments on
draft-ietf-payload-rtp-ancillary-03

Hi Thomas,

---

From: "Roni Even" <[email-masked]>
Date: Tue, 26 Jul 2016 09:16:46 +0300

Hi Thomas,
Please upload the version and I will ask if there are any open issues
Thanks
Roni

> -----Original Message-----
> From: Thomas Edwards [mailto:[email-masked]]
> Sent: Monday, July 18, 2016 9:28 PM
> To: Roni Even; 'Ali C. Begen'
> Cc: [email-masked]
> Here is the complete comment resolution on WGLC for draft-ietf-payload-
> rtp-ancillary-03.
> 
upload
> an 04 version if the WG approves.
> 
presumably
> it should say that use with offer/answer is undefined, but that would be
> unfortunate.)"
> 
> Resolution:
the
> associated video streams; i.e., normally 90000, but variable for
JPEG2000."
> [I think Jonathan wants to see this mentioned in Section 3.1 under
Required
> parameters.]
have a
> matching clock rate."
> stream, the RTP timestamp rates SHOULD be the same to ensure that ANC
> data can be associated with the appropriate frame or field."
> 
room
> was somewhat split IIRC. I personally prefer application/smpte291 as well
> but someone had an argument for the video mime-type, which I cannot
> recall right now."
> 
> Thomas Edwards <[email-masked]> "The argument for
> video/smpte291 is that SMPTE ST 291 Ancillary Data format only makes
> sense within a video environment, it has some inherent links to SDI, and
> frankly it is probably not the optimal way to carry some of this metadata
in a
> more generic case.
> 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"."
> 
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"."
> 
> Resolution:
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."
> 
> Resolution:
should
> explain if the a=fmtp is returned empty, or if the entire offer is
rejected."
> Added answerer must provide all or a subset of DID_SDID pairs in fmtp
line,
> or reject offer.
the
> offer, should be."
line,
> or reject offer.
that in
> the offer."
like
> how long the hex values can be, and whether they can have both lower and
> upper case."
> 
> Resolution:
the
> supported video rasters to 2047 lines. The emerging 4K/UHD standards on
> the other hand has around
with the
> Horizontal_Offset field. This field is limited to 4096 (12-bits).
SDI-signal,
> which starts after the active video section, thus it is barley reachable
in
> 3840/UHD formats."
line
> numbers are not going to change.  Moreover, it is expected that ANC data
> will only be carried in one quadrant of the mux.  Going forward, the
industry
> seeks to move away from linkage between SDI lines and location of ANC
> packets anyway, so it is expected that SDI raster location data will no
longer
> be required soon.  Thus I think it is best to maintain compatibility with
the
> existing SMPTE ST 2038 data model.
> 
> Any plans to update the document so we can progress it Roni Even
>