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

[Colin Perkins <csp@csperkins.org>]

Hi,

Thanks for the comments. A couple of replies inline.

--> Chuck Harrison writes:
>
>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.

Those modes are permitted, so I guess we need to clarify the text. Can you
suggest some wording?

>---
>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.

I'm still not convinced that an additional timecode is necessary: it should
be derivable from the RTP timestamp and RTCP SR packets. Accordingly if you
wish to synchronize the video to another source, you should use the normal
RTCP method, rather than sending an additional timecode stream (indeed, if
you use RTSP, I _think_ there is already a mapping function between the RTP
timestamp and SMPTE timecode).

>---
><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>

Okay. Is there a reason why zero fill doesn't work?

>---
>
>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.

You can use the SDP "a=framerate:" attribute, defined in RFC 2327.

Cheers,
Colin
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt