Subject: [AVT] IETF54 AVT meeting summary

From: Stephen Casner <[email-masked]>
Date: Sat, 20 Jul 2002 06:02:03 -0700 (PDT)

Audio/Video Transport Working Group summary

This meeting began with an update on document publication status,
including a few issues identified for documents in the queue.  One RFC
was published since the last meeting (RFC 3267 on AMR payload format),
three are in the RFC editor queue, and six are with the IESG.  Of the
latter, two are the RTP specification and A/V profile which have been
"tentatively approved".  An issue recently raised regards a conflict
in the sample packing order for G.726 encoding between the profile and
the ITU spec for AAL2 and a request to change the profile to be
consistent with AAL2.  This issue was discussed but not resolved in
the meeting.  The chairs are seeking Area Director guidance and
additional input from parties that are using either of the packing
orders.

Four drafts in working group last call were not discussed.  The
payload format for Distributed Speech Recognition and the profile for
RTCP-based feedback are both ready to go to the IESG after updates to
address the last call comments.  The two unequal protection drafts
(ULP and UXP) have also completed last call requirements.  However,
Steve Casner proposed in the meeting that the ULP draft, which extends
RFC 2733, be changed instead to obsolete 2733 and correct what may
have been a bad design decision regarding the RTP header X and P bits.
The group seemed to be in general agreement with this idea.

The bulk of the meeting was dedicated to updates on payload formats
already in development: for audio, MIDI, AC-3, and iLBC, and for
video, JPEG 2000, JVT, SMPTE 292M and MPEG-4 (both mpeg4-simple and
FlexMux).  Of these, mpeg4-simple has, as of the meeting time,
completed its WG last call period, but there were a few last call
comments to be addressed with another revision that will be submitted
for IESG Last Call.  Most of the remaining drafts are nearing
completion; two separate demos showing transmission using the AC-3 and
JPEG 2000 payload formats were conducted at the end of the session.

Two new payload formats were presented.  The first is a generic format
to add interleaving to other audio formats in a manner analogous to
RFC 2198 for redundancy.  The second is a "native" packetization for
uncompressed video to complement the circuit emulation of the SMPTE
292M payload format.  Both generated interest and suggestions for
changes from the meeting participants.  A third new draft is a
revision of RFC 2833 (tones payload format).  This is intended to be a
quick update cycle to correct problems that have been discovered and
prepare for advancement to Draft Standard, which will require
interoperability verification.  A volunteer is sought to track this.

In addition to the payload format drafts, there were several drafts
related to RTCP.  During the course of the IETF meeting, the authors
of the RTCP reporting extensions and VoIP metrics drafts produced the
merged draft that was requested at the last IETF meeting.  It was
suggested during the meeting that this draft go to Proposed Standard
rather than Experimental as we had decided before.

Perhaps the most significant progress at this meeting resulted from
side discussions among the authors of the two alternative proposals
for RTP retransmission based on RTCP feedback.  The SN-multiplexing
scheme of the "selret" proposal will be abandoned in favor of SSRC
multiplexing so long as no problems with the latter are found.
Separately, the SEL format for communicating packet priority will be
evaluated compared to full loss reporting.  A work plan leading to
WG last call in December was outlined.

The last topic was RTCP extensions for Single-Source Multicast
sessions.  In previous discussions of this draft, we've established
the need to address the security issues it introduces.  A good
analysis of the security threats and an evaluation of the existing
solutions has been written as a separate document to work toward the
finished solution.

Action Items

We took two "hums" during the meeting which need confirmation on the
mailing list.  They were to accept the payload formats for
uncompressed video (draft-gharai-avt-uncomp-video-00.txt) and for JVT
video (draft-wenger-avt-rtp-jvt-01.txt) as working group tasks.  We
solicit confirmations or objections on these actions -- we want to
hear both "yeas" and "nays".

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Chuck Harrison <[email-masked]>
Date: Thu, 25 Jul 2002 21:45:23 -0700

Steve, Ladan, all,

> Audio/Video Transport Working Group summary
[...]
> uncompressed video (draft-gharai-avt-uncomp-video-00.txt) 

I am in favor of accepting draft-gharai-avt-uncomp-video-00.txt
for development within AVT.

I am particularly interested in the application of this payload
in an open-ended way to high-resolution, high-bit-depth, and high-
frame-rate applications being considered for Digital Cinema.

A recent SMPTE standard for 10- and 12-bit RGB transport has been
proposed http://www.smpte.org/smpte_store/standards/pdf/s372m.pdf ,
and should be supported.

Also, SMPTE 268M-1994, File Format for Digital Moving-Picture
Exchange (DPX) is a flexible, somewhat TIFF-like format, widely used
for professional postproduction work. We should look at this to
get an idea of the range of bit-depths etc. that will be useful.
Bit depths up to 16 bits per primary have been suggested, and
four-channel (RGBA) data is also used regularly.

I do not think it is difficult to accommodate a wide range of
image formats into the draft-gharai-avt-uncomp-video-00.txt
framework; the greatest part of the work is in managing the
SDP parameters.

Cheers,
  Chuck Harrison

---

From: Ladan Gharai <[email-masked]>
Date: Fri, 26 Jul 2002 11:02:52 -0400

Chuck - our goal is for the draft to be all-encompassing of
various forms of high-quality video, such that on the high end
it will be able to accommodate Digital Cinema, as well as other
forms of digital video (we will look into SMPTE 268M
to get a better idea of different color depths, thanx for the 
reference) - however as you point out the tricky part will be the 
SDP parameters, as we definitely want out-of-band signaling of 
parameters.

Ladan