[payload] Issues with draft-ietf-payload-rtp-ancillary-12

[Thomas Edwards <[e-mail]>]

Dear IETF Payload WG,

While draft-ietf-payload-rtp-ancillary-12 was in the RFC Editor Queue, a problem in the document was brought to my attention.  I have requested that the document be paused in the RFC Editor Queue for IESG action.

The draft currently states of the “Line_Number” field:

                “A value of 0x7FE indicates that the ANC data is intended to be placed into any legal area of the vertical blanking period ("VANC data space"), specifically.”

As we know, “any legal area of the vertical blanking period” is not “VANC data space” as defined in SMPTE ST 291-1, so this statement is incorrect.

I briefly considered asking the RFC Editor to simply remove the parenthetical statement.  But two problems sprung up.

First, we don’t have a Horizontal_Offset code for placing a packet horizontally anywhere in the VANC space (i.e. between SAV and EAV).   We do have a Horizontal_Offset code for anywhere in HANC space though.

But a bigger problem is that a generic code for ANC data on any line in the vertical interval is actually a BAD idea.

Imagine an SDI to IP converter taking a VANC packet from below the RP 168 switch point, coding it as Line_Number 0x7FE, then an IP to SDI converter placing that packet in a line above the RP 168 switch point.  Then an SDI switch occurs, and that VANC packet is no longer attached to its corresponding active video frame.

After surveying all non-audio ANC data standards and their preferred locations, I propose the following solution for the special values that code for the location of the ANC data packet to be in certain generic vertical regions of the SDI raster.  For Line_Number:

0x7FF: Without specific line location within the field or frame
0x7FE: On any line in the range from the second line after the line specified for switching, as defined in SMPTE RP 168, to the last line before active video, inclusive
0x7FD: On a line number larger than can be represented in 11 bits of this field (if needed for future formats)

And similarly, for Horizontal_Offset:

0xFFF: Without specific horizontal location
0xFFE: Within horizontal ancillary data space (HANC) as defined in SMPTE ST 291-1
0xFFD: Within the ancillary data space located between SAV (Start of Active Video) and EAV (End of Active Video) markers of the serial digital interface
0xFFC: Horizontal offset is larger than can be represented in the 12 bits of this field (if needed for future formats, or for certain low frame rate 720p formats)

This methodology would code the most important generic use cases:

“VANC Space after 2nd line after RP 168” Line_number: 0x7FE , Horizontal_Offset 0xFFD [most VANC formats]
“HANC Space after 2nd line after RP 168” Line_Number: 0x7FE, Horizontal_Offset 0xFFE [e.g. SMPTE ST 12-2 ATC, ST 2051 Two Frame Marker in HANC]
“HANC Space (any line)”: Line_Number: 0x7FF, Horizontal_Offset: 0xFFE [e.g. SMPTE RP214 KLV Metadata transport in HANC space]
“not tied to location in SDI raster at all”: Line_Number: 0x7FF, Horizontal_Offset: 0xFFF [e.g. all-IP systems in the future]

I am currently coordinating with subject matter experts within SMPTE and the Alliance for IP Media Solutions (AIMS) to confirm these code values.

I hope to have a confirmation of these code values by the end of next week, at which time I can issue a -13 version of the draft if the WG approves.

(Note: In such a draft, I would probably bring out these special codes as tables rather than the current text to make them more readable.)

-Thomas

--
Thomas Edwards
FOX Networks Engineering & Operations
VP Engineering & Development
[e-mail]
[phone]
10201 W Pico Blvd
Los Angeles, CA 90035