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

[Thomas Edwards <[e-mail]>]

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