Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision

From: "Yoshihiro Kikuchi" <[email-masked]>
Date: Tue, 3 Oct 2000 10:36:25 +0900

Dear experts,

Attached find please a draft text for the revision of MPEG-4 Audio/Visual
RTP Internet-Draft.

The revisions are mostly to reflect suggestions by the AVT chair. Most of
them are editorial and there are some minor revisions and clarifications.
The following is a summary of the changes:

(1) MIME subtype names were changed to "video/MP4V-ES" for video and
"audio/MP4A-LATM" for audio.
(2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short
video header mode was changed to "MAY" to "SHOULD".
(3) Clarification of timestamp definition
  There was a suggestion not to describe the detailed definition of the
video timestamp in the RTP spec. and change it as a reference to MPEG-4
visual document, so as to keep consistency with the MPEG-4 visual. A
description about the RTP timestamp in the RTCP SR packet was added.
(4) SA/TTSI over LATM
    A description was added to restrict the LATM usage so as not to transmit
 SA data by LATM.
(5) Other editorial and wording changes.

Please let us know if there is comment on the attached draft. The authors
need to submit it soon as an updated I-D and hopefully final before RFC.

Best regards,
Yoshihiro Kikuchi
and authors of the Internet Draft

----
        Yoshihiro Kikuchi

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

---

From: Franceschini Guido <[email-masked]>
Date: Tue, 03 Oct 2000 18:21:15 +0200

Does it mean that a stream with short video header (H263) SHOULD use the
traditional Payload Format for H263, but could as well (not recommended) use
the new Payload Format for MPEG-4 Video, and that the choosen PF is notified
as usual (SDP etc) ?
If so, OK

Guido

> ----------
> From: 	Yoshihiro Kikuchi[SMTP:[email-masked]]
> Sent: 	Tuesday, October 03, 2000 11:00 AM
> To: 	Franceschini Guido; IETF AVT; 4on2andIP-sys
> Cc: 	Yoshihiro Kikuchi
> Subject: 	Re: draft text for MPEG-4 Audio/Visual RTP I-D revision
> 
> Dear Guido,
> 
> Excerpt from the new text:
> 
> >   When the short video header mode is used, RTP payload format for H.263
> <   (e.g., RFC 2190 or RFC 2429) SHOULD be used.
> 
> This means that it is RECOMMENDED to use the H.263 RTP payload format for
> the short video header which is compatible with H.263 baseline. Regardless
> of MAY or SHOULD, there is a possibility that the H.263 RTP payload format
> may be used, although the possibility may be higher for SHOULD than MAY.
> If
> you really don't want to use the H.263 RTP payload format in some
> circumstances, you don't have to use it. The payload format is signaled
> through the MIME type.
> 
> (IETF experts, please correct me if my understanding on the definition of
> SHOULD is wrong.)
> 
> Best regards,
> Yoshihiro
> 
> ----- Original Message -----
> From: Franceschini Guido <[email-masked]>
> To: IETF AVT <[email-masked]>; 4on2andIP-sys
> <[email-masked]>; 'Yoshihiro Kikuchi'
> <[email-masked]>
> Sent: Tuesday, October 03, 2000 3:20 PM
> Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision
> 
> 
> > Change (2) means that significantly different packets are generated in
> case
> > of Short Video Headers (H263) between the original proposal and this new
> > version. Am I right, or is this just an editorial matter ?
> >
> > Best regards
> > Guido
> >
> > > ----------
> > > From: Yoshihiro Kikuchi[SMTP:[email-masked]]
> > > Sent: Tuesday, October 03, 2000 3:36 AM
> > > To: IETF AVT; 4on2andIP-sys
> > > Cc: Yoshihiro Kikuchi
> > > Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision
> > >
> > > <<File: draft-ietf-avt-rtp-mpeg4-es-05-Sep29.txt>>
> > > Dear experts,
> > >

---

From: [email-masked]
Date: Thu, 5 Oct 2000 11:15:55 +0200

> need to submit it soon as an updated I-D and hopefully final before RFC.

I would like to know why the presence of configuration information in the SDP is
OPTIONAL.

I would think much preferable if the profile-level-id and config fields would be
REQUIRED.

The reasons being that:

- it is only a few bytes anyway

- a decoder implementation would always
have the possibility to be initialized using the information in the SDP,
which is easier for many implementation because parsing the video
syntax requires a video decoder and when you instanciate
a video decoder it is VERY handy to already have the configuration !

- it would help a receiver discover that it cannot decode a given stream
(without having to request and start receiving the actual stream and parse it)
and that may be the key reason: in all modes of delivery this
would solve a "security" issue:

A malignant (or stupid) user of a non-capable decoder could generate
a lot of traffic by requesting repeatedly streams that cannot be decoded,
which the decoder could discover "at once" by parsing the SDP,
if the SDP would always contain the config info...

- it would save (a little) bandwidth since frequent repetition of VOL in the
stream is
required only for clients who do not use SDP info, you could then
have streams that actually do not repeat the VOL, or only rarely.

In point to point delivery, in case the stream cannot be decoded by client, it
saves:
- several round trips
- quite some network traffic
- quite some server load

In broadcast (IP multicast) it  saves:

- some start time since the decoder can start parsing immediatly after
receiving the SDP, without having to wait for repeated VOL

- quite some traffic too (in case the stream cannot be decoded by client)
since issuing a IGMP "join" in order to
receive the stream will "flood" all the network legs between
broadcaster and client.

*************************************************************

Furtheremore I would like to know the exact status of video B frames relative
to this proposal.

Regards,

Philippe Gentric
Software Architect
PHILIPS DIGITAL NETWORKS
Broadcast & Internet Delivery Solutions
Laboratoires d'Electronique Philips
B.P. 15 - 22, Av. Descartes
94453 Limeil-Brevannes Cedex France
Phone  :   33 (0)1 45 10 68 12
Fax    :   33 (0)1 45 10 69 60
[email-masked]

---

From: [email-masked]
Date: Thu, 5 Oct 2000 10:54:18 -0400

Hi Yoshihiro-san, Stephan, and Kris,

Since short-video-header mode of MPEG-4  is essentially H.263V1 baseline,
RFC 2190 and RFC 2429 are both
allowed to be the packetization format in the H.263 world.  For maximal
inter-operability with today's implementation,
and for compatibility with H.263 definition, I would suggest the inclusion
of both RFC2190 and RFC2429 in the
statement. I know for a fact that many H.263 over IP implementations are
still only using RFC2190.

Best regards,

Qunshan
-------------

"Yoshihiro Kikuchi" <[email-masked]>@advent.ee.columbia.edu on
10/05/2000 12:36:52 AM

Sent by:  [email-masked]

To:   "Stephan Wenger" <[email-masked]>
cc:   "Colin Perkins" <[email-masked]>, "IETF AVT" <[email-masked]>,
      "4on2andIP-sys" <[email-masked]>, "Yoshihiro
      Kikuchi" <[email-masked]>

Dear Stephan, Kris and all,

Thank you very much for your comments.

Seeing a comment from Kris and a suggestion form Stephan about H.263 RTP
format, I think it is reasonable to keep the use of H.263 RTP format as
"SHOULD", specifying only RFC2429 as suggested, and not to add the detailed
timestamp definition of the short video header mode.

    When the short video header mode is used, RTP payload format for H.263
    (RFC 2429) SHOULD be used.

Best regards,
Yoshihiro

----- Original Message -----
From: Stephan Wenger <[email-masked]>
To: Yoshihiro Kikuchi <[email-masked]>
Cc: Colin Perkins <[email-masked]>; IETF AVT <[email-masked]>; Yoshihiro
Kikuchi <[email-masked]>
Sent: Thursday, October 05, 2000 12:39 AM
Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision

> Dear Yoshihiro, Group,
>
> To my knowledge the only reason why RFC2190 is not yet OBSOLETE is
> that some early H.323 products still use it.  Interoperability with such
> products is probably not your main concern.  So I would suggest to select
> RFC2429 only.
>
> Stephan
>
> At 08:15 PM 10/4/2000 +0900, Yoshihiro Kikuchi wrote:
> >Dear Colin, all,
> >
> > > You should specify which of RFC 2190 or RFC 2429 is intended.
> > >
> >Can I ask suggestions from ITU-T H.263 experts on this selection of
RFCs?
> >Or, if ITU-T does not have any preference, I'm not sure if it is really
> >necessary to change the text to decide this in "MPEG-4" RTP payload
spec.