Subject: Updated I/D for MPEG-4 Audio/Visual RTP payload format

From: "Yoshihiro Kikuchi" <[email-masked]>
Date: Wed, 31 May 2000 11:08:47 +0900

Dear MPEG-4 on IP experts,

I have just submitted the attached text as an updated Internet-Draft for the
MPEG-4 Audio/Visual RTP payload format.

The following is the list of changes from the previous Internet-Draft.

(1) Revision on the MPEG-4 upstream message RTCP (Section 5)
The RTCP specification was changed according to the discussion at the
Adelaide meeting.

(2) MIME type registration (Section 6)
As announced in Adelaide, a new section was added for the MIME type
registrations and SDP usages of MPEG-4 Audio/Visual streams.

(3) Some other clarifications and wording changes.

There is no essential change on the RTP part from the previous version,
which was verified and demonstrated by companies in Noordwijkerhout.

If you have any comments and questions, please let us know. Depend on the
discussion, we may provide another updated I/D with reflecting all comments
and suggestions, which should be the very final version of the I/D. We hope
we can finalize it by the end of the next week. We appreciate if we can have
all comments, if any, by then.

Best regards,
Yoshihiro

----
        Yoshihiro Kikuchi

E-mail: [email-masked]
Corporate Research and Development Center
TOSHIBA Corporation
TEL: +81 +44 549 2288    FAX: +81 +44 520 1267

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 31 May 2000 09:21:04 +0200

Dear all,

I have a some concerns with the current draft.

Number one is the language quality, which really needs
improvement.  An English native speaker should look
through this.  No insult intended :-)

Number two is technical, and much more important.  It
is related to the RTCP-based back channel for NEWPRED in
section 5.

I believe that, when a payload specification defines RTCP-based
feedback, at least the most common mechanisms that could
also use RTCP-based feedback should also be defined.  For
predictive video coding this would be at least a Full Intra Refresh.
Compared to NEWPRED, FIR has obvious disadvantages in
terms of bitrate and delay, but the advantage of being available
in ALL profiles/levels of MPEG-4 visual.  NEWPRED, on the
other hand, is only available when the ARTS profile is implemented,
implying (at least) version 2 of MPEG-4.

I could also think of other back channel messages that report the
loss of single slices, or even macroblocks, and similar.

During a recent ITU-T meeting in Osaka I had the chance to talk
to Mr. Fukunaga regarding this.  There, I promised to come up
with some text to include FIR into the draft.  Unfortunately I was
unable to do this in a as timely fashion as promised, because
a) work overload and b) there is a need for a complete rewriting
of section 5 of the draft.

Why this?  Currently, although the syntax of the RTCP packets
is already general enough to accommodate FIR and other schemes,
the text is only concerned with NEWPRED.  NEWPRED has
certain attributes, which might not be of similar importance to
other schemes.  It is, for example, absolutely necessary to send
NEWPRED NACK messages in a timely fashion in order to make
NEWPRED effective.  Therefore, the draft suggests to send
RTCP packets containing feedback messages without waiting the
random delays suggested for Receiver Reports.  To avoid the
resulting network flooding problems, the draft further limits the
use of RTCP-based feedback to unicast.

While all this makes totally sense for NEWPRED, sending FIR
is not as time critical as NEWPRED, and would thus allow for
using random delays, which in turn would allow to use multicast.

For this reason (and other, similar reasons) it is much more effort to
include FIR into the draft then I originally anticipated.  It is only an
editing job, but a tricky one.

Comments?  Does it make sense to continue this editing job?

Stephan

---

From: "Shigeru Fukunaga" <[email-masked]>
Date: Thu, 1 Jun 2000 00:38:36 +0900

Dear Stephan and all,

Thank you for your comment to our draft.

> implying (at least) version 2 of MPEG-4.

RTCP for FIR seems good idea, however, there are some problems.

At first, we would like to describe only MPEG-4 specific things in this draft. 
As FIR is a common technique for all video coding, other common document
seems to be appropriate.

Second, new proposal just before the last call is not good. We largely discussed
the issues of RTCP for NEWPRED since Adelade meeting, and revised text.
It also takes much time to discuss FIR, however, we have enough time.

> of section 5 of the draft.

I was looking forward to seeing your revision.

> use of RTCP-based feedback to unicast.

I think you mean the FIR RTCP in H.261 paylord format (FRC2032).
The description of FIR RTCP of the RFC seems to be not good for 
the current networks. Therefore Steve advised us to add many descriptions
of the congestion control for NEWPRED RTCP, and limit to unicast.

> editing job, but a tricky one.

Again it is better that FIR RTCP is defined in the common document.

Best Regards,
Shigeru
--
   Shigeru Fukunaga ([email-masked])
   Oki Electric Industry Co., LTD.
   Tel. +81 6 6949 5101; Fax. +81 6 6949 5108