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

[Thomas Edwards <[e-mail]>]

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

-- 
Thomas Edwards 
VP Engineering & Development
FOX Networks Engineering and Operations
[e-mail]
Phone: [phone]
10201 West Pico Blvd.
Los Angeles, CA 90035

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

    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 [[e-mail]]
    Sent: 04 March 2017 00:42
    To: [e-mail]
    Cc: John Fletcher
    Subject: Re: [payload] summary of changes to draft-ietf-payload-rtp-ancillary from -06 to -07
    
    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
    
    --
    Thomas Edwards
    VP Engineering & Development
    FOX Networks Engineering and Operations
    [e-mail]
    Phone: [phone]
    10201 West Pico Blvd.
    Los Angeles, CA 90035
    
    On 3/3/17, 2:21 AM, "John Fletcher" <[e-mail]> wrote:
    
        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:[e-mail]] On Behalf Of Thomas Edwards
    
        Sent: 03 March 2017 01:33
    
        To: [e-mail]
    
        Subject: Re: [payload] summary of changes to draft-ietf-payload-rtp-ancillary from -06 to -07
    
    
    
        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
    
        [e-mail]
    
        Phone: [phone]
    
        10201 West Pico Blvd.
    
        Los Angeles, CA 90035
    
    
    
    
    
    
    
        _______________________________________________
    
        payload mailing list
    
        [e-mail]
    
        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=
    
        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.
    
        -----------------------------
    
    
    
    
    
    -----------------------------
    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= 
    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.
    -----------------------------