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

From: Thomas Edwards <[email-masked]>
Date: Thu, 4 Jun 2015 00:50:09 +0000

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]
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035

---

From: Kevin Gross <[email-masked]>
Date: Thu, 4 Jun 2015 16:13:14 -0600

Thomas,

I have some additional comments on your draft:

Abstract:

Consider providing a definition for "KLV" early on

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

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?

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)? Where do DID
values come from?

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.

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.

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.

Kevin Gross - AVA Networks

On Wed, Jun 3, 2015 at 6:50 PM, Thomas Edwards <[email-masked]>
wrote:

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