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

From: Kris Huber <[email-masked]>
Date: Tue, 3 Oct 2000 12:50:10 -0600

Hello Guido,

I think you are right.  It appears that the other alternative (change MAY to
SHALL or SHOULD) was taken rather than insertion of the MPEG-4 visual
semantics regarding picture rate in short header mode (which lacks
modulo_time_base, vop_time_increment, and vop_time_increment_resolution).
These were spelled out for short header in
draft-ietf-avt-rtp-mpeg4-es-04.txt based on a suggestion I made (e-mail of
9/8/00 "RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt -
timestamp of short header VOP").

Since then, I have learned that a more typical way (I think) that
hardware-assisted compression systems are used with PAL devices is with the
picture clock frequency driving the temporal_reference/TR field set to 25 Hz
rather than giving rounded values of a 30 Hz picture clock.  However, my
suggestion does match baseline H.263 and MPEG-4 short-header mode, although
I think H.263 implementers have been a little loose in their interpretation,
perhaps with good reason.

Another opinion I respect is that a better partitioning of functions would
have placed all timing information in the systems part, as (I think) was
done for the audio part.  But on the other hand you can't properly decode
video without some timing information (sequence number at least) due to
temporal prediction and B-VOPs.

I heard no discussion of the text I proposed for clarification of the
timestamp relationship to temporal_reference in short header mode after Gary
Sullivan's clarifications and suggestion that MAY be changed to SHALL.  I'm
not on the IETF AVT mailing list or at other meetings where the discussion
probably occurred.

Regards,
Kris

-----Original Message-----
From: Franceschini Guido [mailto:[email-masked]]
Sent: Tuesday, October 03, 2000 12:20 AM
To: IETF AVT; 4on2andIP-sys; 'Yoshihiro Kikuchi'
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,
> 
> 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: Colin Perkins <[email-masked]>
Date: Wed, 04 Oct 2000 00:50:31 -0400

A brief note - the issue of the timestamp is one area where I had some
concerns with this draft, but unfortunately I haven't had enough spare
cycles this past week to follow up on them. This is likely just my mis-
understanding, but input from those who know both MPEG4 and RTP, to ensure
that this is both accurate and consistent with the two timing models, would
be greatly appreciated.

Colin