Subject: Re: [payload] summary of changes to draft-ietf-payload-rtp-ancillary from -06 to -07

From: Thomas Edwards <[email-masked]>
Date: Fri, 3 Mar 2017 01:32:30 +0000

I want to thank John Fletcher for providing feedback to the payload WG list regarding draft-ietf-payload-rtp-ancillary-07

John Fletcher comments >

>It needs to be made clear that the scope is limited to ancillary data carried over a Serial Digital Interface.

I believe that this payload could be used for ANC data packets transmitted without reference to a Serial Digital Interface.

>and delete:
>"This memo describes an RTP payload that supports ANC data packets regardless of whether they originate from an SD or HD interface"
>and add:
>"This memo describes an RTP payload that supports ANC data packets originating from or intended for a Serial Digital Interface such as SDI, HD-SDI, 
>HD_SDI, 3G SDI, 6G SDI, 12G SDI and multiple link versions of these."

That sounds a bit heavy for an introduction.  But perhaps sentence could be changed to be more generic:

“This memo describes an RTP payload that supports carriage of ANC data packets
with origin from any location within any SMPTE defined SDI signal, or 
even if the ANC packets did not originate in an SDI signal.”

>RTP header, timestamp: The term "sampling instant" needs to be clarified, particularly for playback.

I don’t believe that this document, an RTP payload, should define SDI playback.

>Payload header, C bit: You may need more than one bit for interfaces with multiple data streams.
>Cases to consider are:
>SMPTE ST 259 interface;
>In a SMPTE ST 292-1 HD-SDI interface, whether the ANC packets are carried in the Luma channel or the Color Difference channel;
>In a SMPTE ST 425-1 3G-SDI Level B or SMPTE ST 2081-10 6G-SDI mode 1 interface, whether the ANC packets are carried in the Y/G-channel of data stream one or in the other channel and/or other data streams
>In SMPTE ST 425-1 3G-SDI Level A, SMPTE ST 2081-10 6G-SDI mode 2 or SMPTE ST 2082-10 12G SDI interfaces, whether the ANC packets are carried in data stream one or in another data stream
>Payload format parameter, link number: I think you may also need data stream number unless use of C bit is expanded as above.

The LinkNumber SDP parameter definition currently is “link number (1-4) of SDI interfaces that use dual or quad link.”  It can be made more generic: “link number, stream number, or image number of multi-link, multi-stream, or multi-image SDI interfaces.”

>Payload header, line number: You need to include the image format (e.g. in payload format) for the line number to make sense.
>Payload format parameters: I think you need to specify the interface type and the image format

I believe that is out of scope of this payload.

>Payload format parameter, link number: The phrase "comes from" is used but the data could be "intended for"

Perhaps more generically “is associated with”

>Since IP/UDP/RTP are byte-orientated, you need to specify how 10-bit UDWs are mapped onto interface bytes.

OK, I can add “with the 10-bit words carried in order starting from most significant bit and ending in least significant bit”.

>Payload header, ANC_Count - "network byte order" is irrelevant as it is only one byte.

OK.

>Payload header, Line_Number and Horizontal Offset: You need to say more that “network byte order” because these are not a multiple of 8 bits.

I think the ordering from most significant bit to least significant bit is understood, for example RFC 4175 has a 15-bit Line No. field “in network byte order”.

>More normative language is needed.
>There some uses of "may" in non-normative context.

The draft has been analyzed by IETF process for normative language use already.  I do not believe any further changes are required.

>A definition of network byte order is needed

I can include a reference to IETF STD 5.

-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: John Fletcher <[email-masked]>
Date: Fri, 3 Mar 2017 10:21:29 +0000

Regarding the applicability to non-SDI signals, I think you would need to make it clear how certain fields and parameters are to be set in the case of non-SDI data.  The C bit is one example.

John

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Thomas Edwards
Sent: 03 March 2017 01:33
To: [email-masked]
Subject: Re: [payload] summary of changes to draft-ietf-payload-rtp-ancillary from -06 to -07

John Fletcher comments >

OK.

-Thomas

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

-----------------------------
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: Sat, 4 Mar 2017 00:42:26 +0000

draft-ietf-payload-rtp-ancillary-05 contained the text:

   “An ANC data packet with the header fields Line_Number of 0x7FF and
   Horizontal_Offset of 0xFFF SHALL be considered to be carried without
   any specific location within the field or frame, and in such a case
   the "C" field SHALL be ignored.”

However, a commenter stated that ANC payloads typically define their Y/C location - for example SMPTE ST 334-1 “Vertical Ancillary Data Mapping of Caption Data and Other Related Data” states:

   “When the ANC packets defined in this standard are carried in a high definition signal, they shall be carried in the Y stream.”

So the text about ignoring the “C” field was removed from -07 based on the comment.

A non-SDI source could emit ANC data packets using this payload.  In which case, it should fill out the “C” field as a receiver may wish to put it back into SDI.
A non-SDI receiver could receive ANC data packets using this payload.  In which case, it can ignore all the SDI-related fields.

However, I think that prescribing behavior like that is outside of the payload definition.

-Thomas

On 3/3/17, 2:21 AM, "John Fletcher" <[email-masked]> wrote:

    
    John

    -----Original Message-----

    
    To: [email-masked]

    

    John Fletcher comments >

    

    

    

    

    

    

    

    

    

    

    

    

    
    OK.

    

    

    

    
    -Thomas

    --
    
    Thomas Edwards

    
    [email-masked]
    
    Phone: +1.310.369.6696
    
    10201 West Pico Blvd.
    
    Los Angeles, CA 90035

    

    payload mailing list
    
    [email-masked]
    
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_payload&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=sRa4YBEr64p3BC0Kh82e1vJVq2Z0PYd3_AkbshBowVg&s=m_7JrywcfyViM-jX-XNRR3v6CRzrnBkc_e7TiaVcakw&e= 

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

    

    
    
    immediately.

    sent or received.

    this.

---

From: John Fletcher <[email-masked]>
Date: Mon, 6 Mar 2017 10:09:00 +0000

I still think you need to say how the C bit should be set for non-SDI data.  At the moment, there are two possibilities: "HD signals" and "SD signals".  You allow no other possibility than a video signal.  And by the way, what about UHD?

John
________________________________________
From: Thomas Edwards [[email-masked]]
Sent: 04 March 2017 00:42
To: [email-masked]
Cc: John Fletcher
Subject: Re: [payload] summary of changes to draft-ietf-payload-rtp-ancillary from -06 to -07

-Thomas

    John

    -----Original Message-----

    To: [email-masked]

    John Fletcher comments >

    OK.

    -Thomas

    --

    Thomas Edwards

    [email-masked]

    Phone: +1.310.369.6696

    10201 West Pico Blvd.

    Los Angeles, CA 90035

    payload mailing list

    [email-masked]

    immediately.

    sent or received.

    this.

---

From: Thomas Edwards <[email-masked]>
Date: Wed, 8 Mar 2017 21:50:01 +0000

Perhaps text such as

“The ‘C’ bit should be set as required by the standard defining the ANC data packet type, even if the ANC data packet did not originate from an SDI signal.  If the ANC data packet type definition does not require Y or C carriage, the bit should be set to zero.”

I don’t think UHD would change this.

-Thomas

On 3/6/17, 2:09 AM, "John Fletcher" <[email-masked]> wrote:

    John

    

    

    -Thomas

    

        John

        -----Original Message-----

    
        To: [email-masked]

    

        John Fletcher comments >

    

    

    

    

    

    

    

    

    

    

    

    

    
        OK.

    

    

    

    
        -Thomas

        --
    
        Thomas Edwards

    
        [email-masked]
    
        Phone: +1.310.369.6696
    
        10201 West Pico Blvd.
    
        Los Angeles, CA 90035

    

        payload mailing list
    
        [email-masked]

    

    

    

    
        immediately.

        sent or received.

        this.

    

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