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

From: Thomas Edwards <[email-masked]>
Date: Thu, 4 Jan 2018 01:17:41 +0000

draft-ietf-payload-rtp-ancillary-13 currently says for Horizontal_Offset:

“This field defines the location of the ANC data packet in an SDI raster relative to the start of active video (SAV, a digital synchronizing signal present in SDI interfaces) as an unsigned integer in network byte order.  A value of 0 means that the Ancillary Data Flag (ADF) of the ANC data packet begins immediately following SAV.  For HD, this is in units of Y samples as defined in ITU-R BT.1120 [BT1120]…”

How about we change the last sentence to:

“For HD, the horizontal offset from SAV is measured in terms of 10-bit words of the particular channel indicated by the ‘C’ bit.”

-Thomas

On 12/20/17, 9:30 AM, "payload on behalf of John Fletcher" <[email-masked] on behalf of [email-masked]> wrote:

    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,
    
    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: John Fletcher <[email-masked]>
Date: Thu, 4 Jan 2018 12:21:20 +0000

That is better but there is still the issue that no definition is given for UHD.  I don't think there is any need for make a distinction for SD/HD/UHD, so the last sentence could be as below (deleting the "For SD..." sentence):

"The horizontal offset from SAV is measured in terms of 10-bit words of the indicated data stream/data channel."

I also have a slight issue with the Line_Number definition because it says line number for HD is defined in ITU-R BT.1120 but that does not cover 3G Level A or HFR.  So I would suggest changing the first paragraph to:

"This field contains the line number (as defined in ITU-R BT.1700 [BT1700] for SD video or the appropriate interface mapping specification for HD or UHD video) that corresponds to the location of the ANC data packet in an SDI raster as an unsigned integer in network byte order."

I would also move the paragraph beginning "In multi-stream interfaces ..." so that it follows the first paragraph.

And finally, in the "Note ..." paragraph, I would change "sample structure specification" to "interface mapping specification".

John
________________________________________
From: Thomas Edwards [[email-masked]]
Sent: 04 January 2018 01:17
To: John Fletcher; [email-masked]
Cc: Ali C. Begen
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-13.txt

-Thomas

    John Fletcher

    Payload WG,

    @Ben, could we do that?

    -acbegen

---

From: Thomas Edwards <[email-masked]>
Date: Sat, 6 Jan 2018 00:58:19 +0000

OK, I am fine with this:

Horizontal_Offset: 12 bits
           This field defines the location of the ANC data packet in an
           SDI raster relative to the start of active video (SAV, a
           digital synchronizing signal present in SDI interfaces) as an
           unsigned integer in network byte order.  A value of 0 means
           that the Ancillary Data Flag (ADF) of the ANC data packet
           begins immediately following SAV.  The horizontal offset
           from SAV is measured in terms of 10-bit words of the
           indicated data stream and data channel.

For line number, I see your point.  Really no point in referencing anything even for SD, how about just:

Line_Number: 11 bits
           This field contains the digital interface line number
           that corresponds to the location of the ANC data
           packet as an unsigned integer in network
           byte order.

-Thomas

On 1/4/18, 4:21 AM, "John Fletcher" <[email-masked]> wrote:

    

    
    
    John

    

    -Thomas

    
    
        John Fletcher
    
        Payload WG,

        @Ben, could we do that?
    
        -acbegen

---

From: John Fletcher <[email-masked]>
Date: Sun, 7 Jan 2018 15:01:56 +0000

Looks good to me.
John
Sent: 06 January 2018 00:58

OK, I am fine with this:

Line_Number: 11 bits

-Thomas

    John

    -Thomas

        John Fletcher

        Payload WG,

        @Ben, could we do that?

        -acbegen

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Thomas Edwards <[email-masked]>
Date: Wed, 10 Jan 2018 03:26:00 +0000

OK, I’d be glad to issue a new I-D with this language if it pleases the Payload WG.  I have passed it by some key SMPTE SMEs who also feel it is OK wording.

-Thomas

On 1/7/18, 7:02 AM, "John Fletcher" <[email-masked]> wrote:

    Looks good to me.
    John
    
    OK, I am fine with this:

    
    Line_Number: 11 bits
    
    -Thomas

    

    

        John

    

        -Thomas

    
    
            John Fletcher
    
            Payload WG,

            @Ben, could we do that?
    
            -acbegen

    
    
    https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bbc.co.uk&d=DwIF-g&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=V2EAlSlkG_oZade6gVi4ztzBsIIms5rqHMx_ps519Kk&s=EZGTs6H5N1HOkhnHnvZc0EdR573b8IkIaiMCZFad3B0&e=

---

From: "Ali C. Begen" <[email-masked]>
Date: Wed, 10 Jan 2018 08:58:59 +0300

Please do so, Thomas,

Thanks.

> On Jan 10, 2018, at 6:26 AM, Thomas Edwards <[email-masked]> wrote:
>

---

From: Thomas Edwards <[email-masked]>
Date: Wed, 24 Jan 2018 04:07:03 +0000

OK, I think we are ready to move forward with draft-ietf-payload-rtp-ancillary-14.

-Thomas

On 12/16/17, 6:22 AM, "Ali C. Begen" <[email-masked]> wrote:

    Payload WG,

    @Ben, could we do that?
    
    -acbegen

    > On Dec 15, 2017, at 10:40 PM, [email-masked] wrote:
    > 
    > 
    > 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpayload-2Drtp-2Dancillary_&d=DwIFAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=ofqEJl8AbYOcvTUl-4v4Uewvp180a0_Me7hCIWm32zo&e=
    > 
    > There are also htmlized versions available at:
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dpayload-2Drtp-2Dancillary-2D13&d=DwIFAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=fFbDuGwzaS5gbYQ7V2GJGmZgqNH93TXCOBCX0c6Ueuk&e=
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dpayload-2Drtp-2Dancillary-2D13&d=DwIFAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=FfbAuMttxcRCQOK3EwWp9eeNXXJCI3X46ndx_zkc0Jg&e=
    > 
    > A diff from the previous version is available at:
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dpayload-2Drtp-2Dancillary-2D13&d=DwIFAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=AuWy69MQol93d66H8J7QVm53zNnrWVwollgbBmFnO2A&e=
    > 
    > 
    > Please note that it may take a couple of minutes from the time of submission
    > until the htmlized version and diff are available at https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwIFAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=vrri0RFzwNmwd5G6mJgffeHveltsjb7oeIa0FjC7J8g&e=.
    > 
    > Internet-Drafts are also available by anonymous FTP at:
    > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwIFAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=2UNqqbw3azm9uXp6lTyi9pYozsqqYlbtqoDujws53eg&e=
    > 
    > _______________________________________________
    > payload mailing list
    > [email-masked]
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_payload&d=DwIFAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=Vg4M7XIVQeP0jvKrKQzEWDHagbdPtcIe0R90niUURQE&e=

---

From: "Ali C. Begen" <[email-masked]>
Date: Wed, 24 Jan 2018 09:09:58 +0300

Yes. @Ben, can we ship it back to the rfc editor?

On Wed, Jan 24, 2018 at 7:07 AM, Thomas Edwards <[email-masked]>
wrote:

>     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
>
>
>
>     > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> datatracker.ietf.org_doc_draft-2Dietf-2Dpayload-2Drtp-
> 2Dancillary_&d=DwIFAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=
> lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_
> kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=ofqEJl8AbYOcvTUl-
> 4v4Uewvp180a0_Me7hCIWm32zo&e=
>     >
>     > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.
> ietf.org_html_draft-2Dietf-2Dpayload-2Drtp-2Dancillary-2D13&d=DwIFAg&c=
> uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=
> lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_
> kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=
> fFbDuGwzaS5gbYQ7V2GJGmZgqNH93TXCOBCX0c6Ueuk&e=
>     > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> datatracker.ietf.org_doc_html_draft-2Dietf-2Dpayload-2Drtp-
> 2Dancillary-2D13&d=DwIFAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=
> lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_
> kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=
> FfbAuMttxcRCQOK3EwWp9eeNXXJCI3X46ndx_zkc0Jg&e=
>     >
>     > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dpayload-2Drtp-2Dancillary-2D13&d=
> DwIFAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=
> lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_
> kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=
> AuWy69MQol93d66H8J7QVm53zNnrWVwollgbBmFnO2A&e=
>     >
>     >
>     > until the htmlized version and diff are available at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.
> ietf.org&d=DwIFAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=
> lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_
> kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=
> vrri0RFzwNmwd5G6mJgffeHveltsjb7oeIa0FjC7J8g&e=.
>     >
>     > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.
> org_internet-2Ddrafts_&d=DwIFAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zv
> FcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_
> kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=
> 2UNqqbw3azm9uXp6lTyi9pYozsqqYlbtqoDujws53eg&e=
>     >
>     > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_payload&d=DwIFAg&c=
> uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=
> lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_
> kB1CWwwMTgmunEUHGyQasQPIHmO1ckBhII1Sv2RWEo&s=
> Vg4M7XIVQeP0jvKrKQzEWDHagbdPtcIe0R90niUURQE&e=
>
>
>
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Jan 2018 09:37:31 -0600

I think we can. The changes are borderline material, but I imagine everyone who cares about them in the IETF is on the payload list. I need to figure out how to hand it back, then will do so.

Thanks!

Ben.

> On Jan 24, 2018, at 12:09 AM, Ali C. Begen <[email-masked]> wrote:
> 
> On Wed, Jan 24, 2018 at 7:07 AM, Thomas Edwards <[email-masked]> wrote: