Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-02.txt

[Chuck Harrison <cfharr@erols.com>]

Hi, all,

A few comments on this draft, which is looking very good so far.

---
In uncomp-video-02 we have:

4.3.  Payload Data

Depending on the video format, each RTP packet can include either a
single complete scan line, a single fragment of a scan line, or one
(or
more) complete scan lines plus a fragment of a scan line. [...]


I think there are additional logical possibilities allowed by
the document as it stands: a packet may begin with the tail
fragment of a line, then continue with 0 or more full lines, and
possibly the head fragment of another line.

If the intent is to exclude these possibilities, we need normative
language to say so. If these operational modes are permitted, the
quoted text above is misleading and should be amended.

---
On page 3 of the draft, we have

[...] This payload format
requires that applications using such synchronized ancillary data MUST
deliver it in separate RTP sessions which operate concurrently with
the
video session.  The normal RTP mechanisms SHOULD be used to
synchronize
the media.

I believe the MUST is inappropriate and SHOULD is preferable.

The idea that frame-accurate timecode will be carried as a
parallel RTP session is a laudable but forward-looking conjecture.
IMHO reliable use of this payload format in the near future
will depend on carriage of vertical interval timecode (VITC)
in an unused scan line which is part of the vertical blanking
interval. (This is normal video operational practice, as
mentioned in RFC 2431.)

At the top of page 2 of the draft, we have "...the contents of
horizontal and vertical blanking SHOULD NOT be transported." This
does not bother me as SHOULD NOT language does not prevent me from
carrying VITC when I need it, until the multisession RTP sync
issues get ironed out. On the other hand the MUST language of
page 3 is burdensome.

---
<nitpick>
A minor MUST/SHOULD nit at sec. 4.3 regarding filling to a pgroup
boundary: since a receiver MUST ignore the fill data, it seems
unneccessary that the sender MUST fill with zeroes, specifically.
The sender MUST fill, and SHOULD fill with zeroes.
</nitpick>

---

The MIME and SDP parameters do not include the video frame rate.
There are many plausible scenarios in which it is important
to distinguish alternative frame rates. For example, choosing
the right VOD stream during RTSP setup would need something like
this.

---

Cheers,
  Chuck Harrison
  Far Field Associates, LLC
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt