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

From: "Ali C. Begen" <[email-masked]>
Date: Mon, 18 Apr 2016 13:23:09 +0300

Hi everyone

I am starting a WGLC on the following draft:
https://www.ietf.org/id/draft-ietf-payload-rtp-ancillary-03.txt

It is a short document. Please review and send any comments to the list by
May 2nd.

-acbegen (as a co-chair)

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 18 Apr 2016 15:59:29 +0000

On Apr 18, 2016, at 6:23 AM, Ali C. Begen <[email-masked]<mailto:[email-masked]>> wrote:

Hi everyone

It is a short document. Please review and send any comments to the list by May 2nd.

I don’t have the expertise to review the payload format itself.  However, I have several comments about its signaling.

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

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.

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.

Chairs: have you sent this document for an SDP directorate review?

---

From: "Ali C. Begen" <[email-masked]>
Date: Tue, 19 Apr 2016 13:28:44 +0300

On Mon, Apr 18, 2016 at 6:59 PM, Jonathan Lennox <[email-masked]> wrote:

>
> On Apr 18, 2016, at 6:23 AM, Ali C. Begen <[email-masked]> wrote:
>
> Hi everyone
>
> I don’t have the expertise to review the payload format itself.  However,
> I have several comments about its signaling.
>
> 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.)
>
> 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.
>
> 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 will let the author respond to these questions. My assumption is that
these cases won't be necessary for this payload but I will let the author
confirm.

> Chairs: have you sent this document for an SDP directorate review?

I just did. Thanks.

-acbegen

---

From: James Barrett <[email-masked]>
Date: Tue, 19 Apr 2016 13:11:20 +0000

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.

--
James P. Weaver (né Barrett)
Research Engineer
BBC R&D North Lab,
Floor 5 Dock House, MediaCity,
M50 2LH
Tel: +44(0)30 3040-9521
e-mail: [email-masked]

> On 19 Apr 2016, at 11:28, Ali C. Begen <[email-masked]> wrote:
> 
> 
> 
> I will let the author respond to these questions. My assumption is that these cases won't be necessary for this payload but I will let the author confirm.
>  
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: "Ali C. Begen" <[email-masked]>
Date: Tue, 19 Apr 2016 16:40:08 +0300

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.

On Tue, Apr 19, 2016 at 4:11 PM, James Barrett <[email-masked]>
wrote:

> 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.
>
> --
> > I don’t have the expertise to review the payload format itself.
> However, I have several comments about its signaling.
> >