Subject: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-13.txt

From: [email-masked]
Date: Fri, 15 Dec 2017 11:40:59 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Payloads WG of the IETF.

        Title           : RTP Payload for SMPTE ST 291-1 Ancillary Data
        Author          : Thomas G. Edwards
	Filename        : draft-ietf-payload-rtp-ancillary-13.txt
	Pages           : 19
	Date            : 2017-12-15

Abstract:
   This memo describes a real-time transport protocol (RTP) payload
   format for the Society of Motion Picture and Television Engineers
   (SMPTE) Ancillary data, as defined by SMPTE ST 291-1.  SMPTE
   Ancillary data is generally used along with professional video
   formats to carry a range of ancillary data types, including time
   code, Closed Captioning, and the Active Format Description (AFD).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ancillary/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-payload-rtp-ancillary-13
https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-ancillary-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-ancillary-13

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Ali C. Begen" <[email-masked]>
Date: Sat, 16 Dec 2017 17:21:55 +0300

Payload WG,

Is there any objection to the latest revision that addresses the issues Thomas pointed out earlier? The draft was in the RFC editor queue and if there are no objections, we will soon ship it back there. But to give people a chance to read and officially comment on the revision, I think we should start a new IETF LC for a week.

@Ben, could we do that?

-acbegen

> On Dec 15, 2017, at 10:40 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: Kjetil Oftedal <[email-masked]>
Date: Sat, 16 Dec 2017 18:34:06 +0100

Hi,

The submitted changes does not address the previous concern
regarding the M-bit in the RTP Header.
The M-bit should signal the end of a access unit in the stream.
Currently that access unit is a field/frame and is signaled in the
last RTP packet before the field/frame boundary. However, the SDI
splicing points are not on the field/frame boundary, but several video
lines into the field/frame.

Thus the result of splicing streams at the M-bit will be that the
ANC/SDI streams is not to be spliced at the SDI splicing point.
There should be little or no ANC data above the switching line in
a field/frame, so it might not be a big issue. But if care is taken to
avoid switching line problems in the standard. Such care should
also be taken with the M-bit signaling.

Changing the M-bit signaling creates secondary considerations with
the line signaling in the header. As the line numbers will wrap
before the M-bit is set.

Best regards,
Kjetil Oftedal

On 16/12/2017, Ali C. Begen <[email-masked]> wrote:
> Payload WG,
>
> Is there any objection to the latest revision that addresses the issues
> Thomas pointed out earlier? The draft was in the RFC editor queue and if
> there are no objections, we will soon ship it back there. But to give people
> a chance to read and officially comment on the revision, I think we should
> start a new IETF LC for a week.
>
> @Ben, could we do that?
>
> -acbegen
>
>
>

---

From: Thomas Edwards <[email-masked]>
Date: Sun, 17 Dec 2017 04:32:52 +0000

I think there is general acceptance within SMPTE and AIMS for the current M-bit definition.

What would be your precise suggested language?

-Thomas

On 12/16/17, 9:34 AM, "payload on behalf of Kjetil Oftedal" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    
    
    Best regards,
    Kjetil Oftedal

    On 16/12/2017, Ali C. Begen <[email-masked]> wrote:
    >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpayload-2Drtp-2Dancillary_&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=xuzh42Xrt8nAWeZRUdIKO_Adk8JUqu3yzEJvh7mHdKU&s=7vyaA7cXEAI-MYlylZlkl3STidpQ1ctcYAjjk6bJ44c&e=
    >>
    >> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dpayload-2Drtp-2Dancillary-2D13&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=xuzh42Xrt8nAWeZRUdIKO_Adk8JUqu3yzEJvh7mHdKU&s=b39SxdEFh4pxT4eZNJk_MfWlkc9238r5RRhk_PKAV5k&e=
    >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dpayload-2Drtp-2Dancillary-2D13&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=xuzh42Xrt8nAWeZRUdIKO_Adk8JUqu3yzEJvh7mHdKU&s=DCg2JFGaBVlluGzoBxvJvksJ_N7QOLwow7a0_jjHhVA&e=
    >>
    >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dpayload-2Drtp-2Dancillary-2D13&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=xuzh42Xrt8nAWeZRUdIKO_Adk8JUqu3yzEJvh7mHdKU&s=uY76k4Yntj9-YL-mWlHiXoAGICOZQfdQQfjklNVzwG4&e=
    >>
    >>
    >> until the htmlized version and diff are available at https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=xuzh42Xrt8nAWeZRUdIKO_Adk8JUqu3yzEJvh7mHdKU&s=HobSEbaVmmKGprXspV1A6yZ7ALees2CQEgqUNg9dKxw&e=.
    >>
    >> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=xuzh42Xrt8nAWeZRUdIKO_Adk8JUqu3yzEJvh7mHdKU&s=5jv9BUCxAiBWSrl9kgfzMHFdirTIpIJ449-avdrHYys&e=
    >>
    >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_payload&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=xuzh42Xrt8nAWeZRUdIKO_Adk8JUqu3yzEJvh7mHdKU&s=hrbeU7fPZX5Dy4O60APeQf7Noz_wcyE40T6e9ehGJzE&e=
    >
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_payload&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=xuzh42Xrt8nAWeZRUdIKO_Adk8JUqu3yzEJvh7mHdKU&s=hrbeU7fPZX5Dy4O60APeQf7Noz_wcyE40T6e9ehGJzE&e=
    >
    
    _______________________________________________
    payload mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_payload&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=xuzh42Xrt8nAWeZRUdIKO_Adk8JUqu3yzEJvh7mHdKU&s=hrbeU7fPZX5Dy4O60APeQf7Noz_wcyE40T6e9ehGJzE&e=

---

From: John Fletcher <[email-masked]>
Date: Wed, 20 Dec 2017 17:30:26 +0000

I think there may still be an issue with the definition of Horizontal_Offset.  No definition is given for UHD and I'm not sure that the HD definition in terms of Y samples is always applicable.

The ANC data consists of 10-bit words in a 10-bit data stream (or a data channel of a data stream).  The position should be measured in terms of  10-bit words relative to the SAV sequence in the data stream.  A definition along those lines works regardless of the image format (YCbCr, RGB, 10-bit, 12-bit) or the mapping from source image to interface.

John Fletcher
________________________________________
From: payload [[email-masked]] on behalf of Ali C. Begen [[email-masked]]
Sent: 16 December 2017 14:21
To: [email-masked]
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-13.txt

Payload WG,

@Ben, could we do that?

-acbegen