Subject: [payload] Comments on draft-ietf-payload-rtp-ancillary-03

From: Kjetil Oftedal <[email-masked]>
Date: Sun, 26 Jun 2016 15:24:56 +0200

Hi everyone

I have some comments on the draft for RTP payload for ancillary data:

The introduction to this standard refers to RFC4175 as one of the
standards it should be interoperable with. However, RFC4175 has a
15-bit line number field allowing support for video rasters with 32K
lines. This new draft only has 11-bit line numbers with the effect of
limiting the supported video rasters to 2047 lines. The emerging
4K/UHD standards on the
other hand has around 2160 active lines, thus not fully supported.

There is a similar issue with the Horizontal_Offset field. This field
is limited to 4096 (12-bits). Ancillary data can be carried in the
horizontal blanking/HANC of a SDI-signal,
which starts after the active video section, thus it is barley
reachable in 3840/UHD formats.
And since audio is placed before ancillary data in the horizontal
blanking the horizontal
offset for any ancillary packet might exceed the supported values for
this field.

To resolve both these issues I would suggest that the
Horizontal_Offset field is replaced with a single bit, indicating that
the ancillary packet should be embedded in HANC space, and requiring
that the ancillary packets should be packetized in a the same order as
the original video signal. As it is required per ST291 that multiple
ancillary packets on the same line shall be embedded back-to-back
reducing this field to a single bit should not cause any real world
issues.

(The implementer of the Ancillary embedder must make sure that the
Ancillary packets are embedded correctly. Audio is also carried with
ancillary packets in SDI but likely
with another RTP-standard over the network (AES67?). Thus when
multiplexing the multiple streams network streams back into a
SDI-video signal no gaps must occur in the Audio/Ancillary packet
stream per line even if the audio layout changes, and the
Horizontal_Offset field can not be blindly trusted anyway)

With the reduction of the Horizontal_Offset field to a single bit, the
Line_Number field can easily be extended to support the same vertical
resolution as RFC4175, without any additional overhead compared to the
current packet format.

It is worth nothing that this suggestion will not work for SD
Ancillary EDH-packets which should not be carried using this standard,
as the checksums contained within this packet are likely to be wrong
when the signal is reconstructed.

Best regards,
Kjetil Oftedal