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

[Kjetil Oftedal <[e-mail]>]

On 03/12/2017, Roni Even <[e-mail]> wrote:
> Hi Thomas,
> I read this proposal
> I understand that the major change is the definition of the methodology:
>
>
> 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]
>
>
> My recommendation is that once you decide on the correct text it will help
> us if we get feedback from other members of SMPTE to the payload mailing
> list that this methodology is the correct one.
>
> Thank
> Roni Even
> Payload G co-chair
>
> From: payload [mailto:[e-mail]] On Behalf Of Thomas Edwards
> Sent: שבת 02 דצמבר 2017 03:10
> To: [e-mail]
> Subject: [payload] Issues with draft-ietf-payload-rtp-ancillary-12
>
> 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]<mailto:[e-mail]>
> [phone]
> 10201 W Pico Blvd
> Los Angeles, CA 90035
>

Hi,

I do agree that there will be an issue when mixing RP168 switching and
this standard/
SMPTE2110. These new values will fix the issue at hand. However, when thinking
about hopefully replace RP168 with something suitable for network-based stream
switching there is another issue that pops up:

The simplest form for switching I would guess will be switching
streams on the M-bit.
However, the ANC payload standard defines:
"Marker bit (M): 1 bit
           The marker bit set to "1" indicates the last ANC RTP packet
           for a frame (for progressive scan video) or the last ANC RTP
           packet for a field (for interlaced video)."

I guess the question is about the definition of the last ANC RTP packet for a
frame/field? Is is the last line of a frame/field? Line 1125 for most
HD formats?
Or is it the line prior to the RP168 switching lines?

If it isn't the line prior to the RP168 switching line, then switching
on the M-bit
will potentially splice ANC data onto a unrelated frame/field in the
RP168 switching context.

Best regards,
Kjetil Oftedal