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

From: Thomas Edwards <[email-masked]>
Date: Wed, 30 Sep 2015 23:16:46 +0000

I believe that Kevin Gross pointed out some important issues in draft-ietf-payload-rtp-ancillary-01, and I would like to ask the Payload WG to allow me to update the I-D to draft-ietf-rtp-ancillary-02.  A draft is attached.

Also addition to some off-list comments:

To "An ANC 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" add ", and in such a case the "C" field will be ignored."

My replies to Kevin inline starting with "TE>".

-Thomas Edwards
 FOX

From: Kevin Gross <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 4, 2015 at 3:13 PM
To: FNG <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-01.txt

Thomas,

I have some additional comments on your draft:

Abstract:

Consider providing a definition for "KLV" early on

TE> I will get rid of "KLV Metadata", as it is a very rare use case.

1 Introduction:

Jargon attenuation
s/carriage of metadata within the bit stream multiplex of a Serial Digital Interface/carriage of metadata within the bit stream of a Serial Digital Interface

Payload does not describe
s/This RTP payload supports ANC data packets/This memo describes an RTP payload which supports ANC data packets

Quotes unnecessary
s/restored to their "original" locations/restored to their original locations

Other wording improvements
s/This payload could be used by itself, or used along with a range of RTP video formats. In particular, it has been specifically designed so that it could be used/This ANC payload can be used by itself, or used along with a range of RTP video formats. In particular, it has been designed so that it could be used

TE> Wording improvements accepted

2.1 Payload Header Definitions

Is there a justification you can provide for including Extended Header Sequence Number. Video payload protocols potentially require this because there may be many packets per video frame. I don't think that's the case for ANC. What is the maximum realistic rate for ANC data?

TE> It depends on what type of ANC data is mapped.  There could easily be several hundred ANC packets per frame if embedded audio is carried in RTP.  There can be as much as 563 Mbps of ANC space in 720p50 HD-SDI.  I have had many inconclusive discussions with experts on this, and my intuition is that too many bits is better than too few bits when it comes to potential sequence number over-run, so I would prefer to leave the extended sequence number in.

We need some additional information about the ANC format to complete this draft. How do we find the beginning of each ANC packet in the payload? Where in an ANC packet is the Ancillary Data Flag (ADF)?

TE> The Ancillary Data Flag is not present in the payload because it is a property of an SDI interface involved, and has no bearing on the ANC packet data.  In all digital component interfaces I am aware of it is 000h 3FFh 3FFh.  I will add "It should be noted that the ancillary data flag (ADF) word is not specifically carried in this RTP payload.  The ADF may be specified in a document defining an interconnecting digital video interface, otherwise a default ADF is specified by SMPTE ST 292-1 [ST292]."

Where do DID values come from?

TE> "The fields DID, SDID, Data_Count, User_Data_Words, and Checksum_Word represent the 10-bit words carried in the ANC data packet, as per SMPTE ST 291"

Based on what I've cleaned from the draft, it seems that we don't need both Length and ANC_Count. It seems like either would be sufficient to determine where payload data stops. You could possibly do without either and use the Length field in the UDP header to know when data ends.

TE> I prefer the RTP ANC payload parser to know how large the ANC data packet payload is without having to refer to higher level network information.  Hopefully that is not an RTP anti-pattern.  ANC_Count does not directly tell you a size, only the number of ANC packets present, which would have to be iterated through as ANC packets may have different lengths.

It is not clear to me what happens at (next ANC data packet). Is there another DID here or do we get a new Line_Number or something else? We need a better description of what an ANC data packet is.

TE> I thought I was being clear with the statement "And for each ANC data packet in the payload, the following header fields MUST be present:" but indeed I am less clear regarding DID,SDID,etc.  I will add "For each ANC data packet in the payload, immediately after the ANC data packet header fields, the following  data fields MUST be present, with the fields DID, SDID, Data_Count, User_Data_Words, and Checksum_Word representing the 10-bit words carried in the ANC data packet, as per SMPTE ST 291-1:"

There's something off in Checksum_Word description, "The lower 8 bits of Checksum_Word, corresponding to bits b8 (MSB) through b0 (LSB) of the 10-bit data count word". b8 through b0 is 9 bits.

TE> Agreed.  I will replace with description "It consists of 10 bits, where bits b8 (MSB) through b0 (LSB) define the checksum value and bit b9 is the inverse (logical NOT) of bit b8."

Kevin Gross - AVA Networks

On Wed, Jun 3, 2015 at 6:50 PM, Thomas Edwards <[email-masked]<mailto:[email-masked]>> wrote:
Based on input from SMPTE members, the following changes were made in the
new draft-ietf-payload-rtp-ancillary:

1) Made this explicitly clear:

"If more than 255 ANC data packets need to be carried in a field or frame,
additional RTP packets carrying ANC data may be sent with the same RTP
timestamp but with different sequence numbers."

2) Added a "don't care" value of 0xFFF to Horizontal_Offset to indicate if
the ANC data is carried without any specific location within the line.

3) Made this explicitly clear:

"An ANC 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."

4) Made this explicitly clear:

"When reconstructing an SDI signal based on this payload, it is
important to place ANC packets into the locations indicated by the    ANC
payload header fields Line_Number and Horizontal_Offset, and also    to
follow the requirements of SMPTE ST 291-1 [ST291] Section 7    "Ancillary
Data Space Formatting (Component or Composite Interface)",    which
include rules on the placement of initial ANC data into allowed    spaces
as well as the contiguity of ANC data packet sequences within    those
spaces in order to assure that the resulting ANC packets in the    SDI
signal are valid."

5) A more clear example of multiple DID_SDID parameters in SDP.

6) Minor editorial nits.

If there is any concern with these changes, please let me know!

-Thomas

--
Thomas Edwards
VP Engineering & Development
FOX Networks Engineering and Operations
[email-masked]<mailto:[email-masked]>
Phone: +1.310.369.6696<tel:%2B1.310.369.6696>
10201 West Pico Blvd.
Los Angeles, CA 90035

_______________________________________________
payload mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/payload<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_payload&d=AwMFaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_iK-42BnvmbbP5Nr7_ClbyieBpuYdQPuRKOiVC2SpSE&s=88mmYChaLERR_FxxOM64DpHnl6PPDZigq3GASMJHVpw&e=>