Subject: RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt

From: Franceschini Guido <[email-masked]>
Date: Fri, 08 Sep 2000 16:33:42 +0200

Some further comment below

> ----------
> From: 	Yoshihiro Kikuchi[SMTP:[email-masked]]
> Sent: 	Friday, September 08, 2000 2:35 PM
> To: 	Young-Kwon LIM; Franceschini Guido; Koji Imura; IETF AVT; Colin
> Perkins; Varesio Andrea
> Cc: 	4on2andIP-sys; Yoshihiro Kikuchi
> Subject: 	Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt
> 
> Dear Young-Kwon, Guido, Matsui-san, Imura-san, all,
> 
> Thank you very much for the comment.
> 
> It seems to be better to list all description related the multiple VOPs
> concatenation in the "current" draft text posted on Sep. 5 here in this
> mail
> for the better understandings.
> 
> 1. Introduction
>    The fragmentation rule recommends not to map more than one VOP in an
> RTP
>    packet so that RTP timestamp uniquely indicates the VOP time framing.
> On
>    the other hand, MPEG-4 video may generate VOPs of very small size, in
>    cases with a not coded VOP containing only VOP header or an arbitrary
>    shaped VOP with a small number. To reduce the overhead for such cases,
>    the fragmentation rule permits concatenating multiple VOPs in an RTP
>    packet when the VOP size is small.
Editorial: I don't think the last statement 'when the VOP size is small' is
necessary/appropriate

> 3.1 Use of RTP header fields for MPEG-4 Visual
>    Marker (M) bit: The marker bit is set to one to indicate the last RTP
>    packet (or only RTP packet) of a VOP. When multiple VOPs are carried in
>    the same RTP packet, the marker bit is set to 1.
> 
>    Timestamp:
>    - When multiple VOPs are carried in the same RTP packet, the timestamp
>      indicates the earliest of the composition time within the VOPs
> carried
>      in the RTP packet.
> 
> 3.2 Fragmentation of MPEG-4 Visual bitstream
>    (4) Two or more VOPs SHOULD be fragmented into different RTP packets so
>    that one RTP packet consists of the data bytes associated with a unique
>    presentation time (that is indicated in the timestamp field in the RTP
>    packet header), with the exception that multiple VOPs MAY be carried
>    within one RTP packet if the size of the VOPs is small.
Editorial: again, what is the meaning of 'small' ? Also, at the beginning, I
would change to 'Different VOPs SHOULD be fragmented into different RTP
packets' 

> I think it is better to add cross-references (see section ..., definition
> of
> ....) for each description above in the draft so that every readers of the
> draft can understand this set of rule easily.
> 
> Young-Kwon wrote:
> 
> > I don't think there is additional complexity. MPEG-4 video decoder
> always
> calculate the time difference of current VOP from the last one.  So, when
> the decoder push the reconstructed data to composition buffer, it can
> easily
> send a presentation time information to the compositor. It is nothing to
> the
> implementation.
> 
> > I'm OK with this because this allows concatenation of VOPs.
> 
> Oh, now there are agreements on the current description. As usual, if
> there
> is any other strong disagreements, we should stick with the current text.
> (except for editorial changes and clarifications)
> 
> Please look not only sentences I posted but a set of rules. It is defined
> that multiple VOPs SHOULD NOT be concatenated so as not to force huge
> amout
> of complexity. The concatenation is an exception rule only when VOP size
> is
> small.
Just to make my point clear: either you quantify 'small', or you can at most
say something like: "concatenation is allowed only when an integral number
of VOPs fit into a single RTP packet"
I would suggest to have some text clearly specifying under which
circumstances VOP concatenation may occur:
Some idea for this text:

Concatenation is allowed only when the following conditions occur:
- the result of concatenting N consecutive VOPs still fits into a single RTP
packet
- the presentation and decoding order of the VOPs is identical
- ...

> >For more clarification I'd like to add "When multiple VOPs are carried in
> one RTP payload, the presentation time of the VOPs after the first one may
> be calculated by the decoder."
> >
> Agreed.
> 
> > BTW, where is a sentence prohibiting concatenation of VOPs with
> different
> decoding order?
> 
> There is no sentence now in the draft but only in mails exchanged.
> 
> Following is the list of proposed changes by mails on this issue for
> editorial update and clarifications but not technical.
> 
> 1) Add cross-cross references to each descriptions.
> 2) Add the following sentence to the timestamp definition
>     "Timestamp information of the rest of VOPs are derived from the
> timestamp fields in the VOP header (modulo_time_base and
> vop_time_increment)."
> 3) Add the following description as a note to fragmentation rule (4)
>     "When multiple VOPs are carried in one RTP payload, the presentation
> time of the VOPs after the first one may be calculated by the decoder."
>     "This operation is necessary only for RTP packets satisfying the
> following both two conditions:
> - Marker bit equal to one, and
>   (Because marker bit in section 3.1 is defined that it is set to one when
> multiple VOP is concatenated.)
> - The beginning of RTP payload is not a start code.
>   (Because the fragmentation rule is defined that a start code is placed
> always at the beginning of RTP payload, if exists.)"
I do not understand this second condition. I would have reversed it "The
beginning of RTP payload corresponds to a start code"

Bye
Guido

> If there is no further objection, only changes reflected to the next
> version
> of I/D will be these descriptions for editorial update and clarifications.
> 
> 
> 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: "Jiro Katto" <[email-masked]>
Date: Sat, 9 Sep 2000 20:15:52 +0900

Dear all,

Current mechanism seems to have two problems:
(1) When M-bit is 1, an RTP handler has to parse all the bits every time
just to
find VOP headers (no mechanisms to indicate the number of VOPs).
(2) Encoder manufacturers may not precisely implement the two fields,
modulo_
time_base and vop_time_increment, similar to MPEG-2 case.

Therefore, I prefer just to say, "Two or more VOPs SHALL be fragmented into
different RTP packets" in the current draft. This is simple and stable.

An alternative, but may not be MPEG-4 specific, is to put the number of VOPs
and time stamps into a payload header using header extension mechanism.
Syntax
will be type, length (= number of VOPs -1), time stamps and padding bytes,
similar to other protocols' option fields. Time stamp can be shrinked to one
byte
by taking differences.

Just a comment. Thanks.

Best regards,
--
Jiro Katto
Waseda University