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

From: "Frank Basso" <[email-masked]>
Date: Mon, 5 Jun 2000 01:42:49 PST

unsubscribe

---------- Original Message ----------------------------------
From: "Yoshihiro Kikuchi" <[email-masked]>
Date: Mon, 5 Jun 2000 13:28:32 +0900

>Dear Stephan, Fukunaga-san, all,
>
>Thank you very much for your reply.
>
>I'm one of the authors of the I/D, but I myself is not a NEWPRED proponent.
>I'm writing here just as an editor.
>
>There are two things discussed in the thread: (1) Stephan's proposal to add
>the FIR description to the I/D, and (2) How to treat NEWPRED RTCP part
>(section 5) of the I/D. These two issues are related, but I'm afraid these
>are too much mixed up throughout the discussion.
>
>(1) FIR (Stephan's proposal)
>I also think that it may have some value to have a feedback mechanism that
>covers all MPEG-4 Visual Profiles but not only ARTS Profile. However, we
>need to know exactly what the proposal is to add any technical change on the
>I/D. We heard only a rough idea on Stephan's proposal. We also need to
>discuss whether Stephan's proposal matches best to the I/D, or some others.
>These requires precise description on the proposal, and probably requires
>further discussions.
>
>I think it is hard to take the third way proposed in Stephan's latest mail
>to add the FIR description to the I/D at this very late stage. It would be
>nice to have a discussion in the future.
>
>(2) NEWPRED RTCP (section 5)
>It is true that NEWPRED RTCP covers only ARTS Profile. It would be desired
>to have feedback mechanism that covers all MPEG-4 Visual Profiles. This does
>need further discussions and thus impossible to add it to the I/D, but could
>be nice to have such scheme in a separate I/D.
>
>I don't want to prevent the future discussions for such feedback mechanism,
>Stephan's or whatever, that can be used combined with the RTP part of the
>I/D. To clarify this, I would like to propose adding some descriptions to
>the I/D that show the followings.
>
>- The RTCP described in section 5 is OPTIONAL. The use of this RTCP is
>limited to NEWPRED in ARTS Profile.
>- For profiles other than ARTS, some feedback mechanisms other than NEWPRED
>may be defined in separate documents and may be used combined with the
>MPEG-4 Visual RTP part of the I/D.
>
>
>Comments are welcome.
>
>Best regards,
>Yoshihiro
>
>----- Original Message -----
>From: Stephan Wenger <[email-masked]>
>To: Shigeru Fukunaga <[email-masked]>; Yoshihiro Kikuchi
><[email-masked]>; 4on2andIP-sys
><[email-masked]>; IETF AVT <[email-masked]>
>Sent: Thursday, June 01, 2000 9:47 PM
>Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format
>
>
>> Dear Shigeru, group,
>>
>> Thanks for your reply.
>>
>> >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.
>>
>> Ok, so you propose to leave "common" feedback mechanism like FIR to
>> some other place, and put only "MPEG-4" specific feedback stuff into
>> your payload spec.  I'm not sure that this is the right thing to do, for
>three
>> reasons: 1) unavailability of a 'general' feedback spec, 2) previous
>> payload specs contents and 3) the difficulty to define "common feedback
>> mechanisms".
>>
>> Regarding 1)
>> When we discussed RFC2429, covering H.263+, we had already adopted
>> reference picture selection (NEWPRED), due to work of your company (OKI).
>> Early Internet drafts of RFC2429 suggested at least two different ways
>> to handle NEWPRED feedback, but were deleted from the drafts because
>> of scaling problems.
>> Several people though of coming up with a 'unified feedback solution',
>but,
>> until now, nothing happened.  This might be partly lack of interest, and
>partly
>> the difficulty of the problem.  Consequently, when adopting your draft
>> unchanged, there would not be a standardized way to perform FIR and
>> similar in IETF environments such as SIP.  The only way to respond to
>> packet losses, beyond responding on RTCP receiver reports, would be
>> to use NEWPRED.  Correct me if I'm wrong here.
>>
>> Regarding 2)
>> There are currently two categories of RTP payload specs with respect to
>the
>> feedback problem.  Category one defines RTCP feedback, and category
>> two does not.  There are, to the best of my knowledge, no payload specs
>> proposed or accepted that follow your idea to include only a few feedback
>> mechanisms specific to a media coding and not in include other known
>> ones for the same media coding.  Certainly, not so important ones like
>FIR.
>>
>> Regarding 3)
>> FIR is common to all video coding?  Well, people not using compression
>> (BT565) will disagree.  Audio folk will disagree.  Motion JPEG proponents
>will
>> also disagree.  On the other hand, NEWPRED is unique to MPEG-4?  You
>> know that H.263+, available as a standard since 1998, includes NEWPRED
>> as well, so NEWPRED is NOT unique to MPEG-4.  A strong argument to
>> include NEWPRED into a unified RTCP feedback RFC?  Furthermore, there
>> are mechanisms like Slices out there, which are available in many, but not
>all,
>> predictive video coding standards.  Are they candidates for a 'common'
>feedback
>> doc, or should they go into a RTCP section of a specific payload?
>>
>> >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.
>>
>> With this I disagree strongly.
>>
>> First let me say, that I'm not on a mission to prevent MPEG-4 ES
>packetization
>> to move forward.  It's not my plan to artificially delay the process, and
>> if it would be,
>> then I'm sure that the our chairs would be able to move forward with the
>draft
>> regardless of my concerns.  If people in the ITU-T want to prevent MPEG-4
>> from happen in H.323, then there are other fori more appropriate to
>achieve
>> that
>> goal.
>> Having said this, however, I have to emphasize that a) we are talking
>about a
>> Internet Draft, b) that you asked for comments, and c) that I see an
>> architectural
>> flaw here.  I'm aware that additional delay may cause some delay in ITU-T
>> Q.13/16 and Q.14/16 work (on H.245 for example) as well (meaning that
>> possible the adoption of MPEG-4 visual/audio to H.323 would be delayed
>> somewhat).  That could be a reason for us (me and you guys) to work
>harder,
>> but not to let a draft pass that contains known architectural problems.
>>
>> Can you please inform this group about your timing constraints?  Why the
>rush?
>>
>> The way to move forward:
>>
>> I see three ways to move forward from now
>> 1) Someone convinces me that I should shut up and let things go.  Probably
>I'm
>>    stickling to principles that are not the general principles of AVT.
>Anyone
>>    besides the proponents of the draft (outside the MPEG core)?
>> 2) Delete section 5 (the rest seems to be, apart from language/editorial
>> problems,
>>    ok, at least to me).  Work together with interested parties, including
>> myself, on
>>    a unified feedback solution, in a separate RFC or a set of separate
>RFCs.
>> 3) Leave section 5 and bring it into such a shape that it can incorporate
>other
>>    feedback schemes, including FIR and SLice Re-transmission at least.
>I'm
>>    still working on my changes for that.
>>
>> Stephan
>>
>>
>>
>
>
>

---

From: "Shigeru Fukunaga" <[email-masked]>
Date: Mon, 19 Jun 2000 19:32:28 +0900

Dear Stephan, Dr. Rhee, and all,

We would like to revise the RTCP part of the ID according to your comments. 
Would you please check the new RTCP text?

The revised points are following.
- We removed all text about re-transmission.
- We added the supplementary text about the upstream message of MIME registration.
- We updated the English quality.

If any problems are remained in this RTCP text, would you please indicate them
as soon as possible?

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

---

From: John Lazzaro <[email-masked]>
Date: Mon, 19 Jun 2000 11:50:01 -0700

> Dear John and all,
>
> Thanks for your comments.

>> Rare will they be under a kbyte. Is SDP happy
>> handling data chunks this large?

> I think it is not happy for SDP to handle such large data. [...]
> As described in draft-ietf-avt-rtp-mpeg4-es-01.txt,
> this can be done by setting the cpresent flag to 1.

This sounds like a good solution, I didn't realize there was an 
alternative mechanism to transmit large config data blocks ...

>> So in this sense,
>> an uncorrected error in an SA_access_unit can essentially destroy all
>> audio produced after the error, for the rest of the performance.

> I think re-transmission can be applied. [...]

This sounds reasonable -- also, any SA_access_unit can be folded into
the StructuredAudioSpecificConfig, which as you note above can be 
transmitted out of band in a reliable way while staying within the spec.

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------