Subject: Uncompressed video payloads

From: Bill Nowicki <[email-masked]>
Date: Tue, 18 Jul 2000 12:05:26 -0700

It looks like draft-ietf-avt-smpte292-video-00.txt is meant to subsume the
"hdtv" draft from last time? I will make my usual suggestion that this could
easily be generalized as a payload format for all uncompressed video
formats. That is, it could subsume RFC 2431 which was specific to standard
definition. The same extended header could be used for all resolutions, with
negotiation in the SDP parameters what the exact resolution, frame rate,
pixel aspect ratio, sample quantization (8 or 10 bit). Then just have a list
of some examples: SMPTE 292 would be one allowed set of parameters, BT.656
would be another (corresponding to SMPTE 259), and my desired application,
lower resolution for existing network technology, would be another.

The only issue I have with the payload format itself is that you seem to be
following the uncompresed audio convention of incrementing the time stamp on
each packet, as opposed to the video convention of having all packets for
the same video frame having the same time stamp. I would vote to keep the
video convention, since you can already retime the packets within each frame
from using the sequence number and offset, right? And you know missing
packets from the sequence number, so the timestamp per packet gives you no
new information. If you followed the video ceonvention of per-frame time
stamps, then each packet could not contain samples from two frames, which
generally makes decoding easier anyway.

Bill Nowicki, Omneon Video, 408-585-5126