RE: [AVT] Requirements draft on video control

"Gary Sullivan" <garysull@windows.microsoft.com> Wed, 09 July 2003 06:39 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20202 for <avt-archive@odin.ietf.org>; Wed, 9 Jul 2003 02:39:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8bl-0005oM-GM for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 02:39:19 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h696dHbU022334 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 02:39:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8bV-0005ms-4f; Wed, 09 Jul 2003 02:39:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a2Ru-0001bP-Np for avt@optimus.ietf.org; Tue, 08 Jul 2003 20:04:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16378; Tue, 8 Jul 2003 20:04:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a2Rs-0001f9-00; Tue, 08 Jul 2003 20:04:40 -0400
Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 19a2Rr-0001eL-00; Tue, 08 Jul 2003 20:04:39 -0400
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Jul 2003 17:03:51 -0700
Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 08 Jul 2003 17:03:51 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jul 2003 17:03:52 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jul 2003 17:03:50 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 8 Jul 2003 17:03:49 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] Requirements draft on video control
Date: Tue, 08 Jul 2003 17:03:29 -0700
Message-ID: <91D7F2CEE3425A4A9D11311D09FCE24602A3474A@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [AVT] Requirements draft on video control
Thread-Index: AcNEz9VQ6y2SEFg1QmuFNQm9pmX67wA1yBiA
From: Gary Sullivan <garysull@windows.microsoft.com>
To: Andrea Basso <Andrea_Basso@nmss.com>, avt@ietf.org, avt-admin@ietf.org, mmusic@ietf.org
Cc: casner@acm.org, jo@tzi.uni-bremen.de, magnus.westerlund@ericsson.com, csp@csperkins.org, Orit Levin <orit@radvision.com>, Roni Even <roni.even@polycom.co.il>, nismail@cisco.com
X-OriginalArrivalTime: 09 Jul 2003 00:03:49.0718 (UTC) FILETIME=[932A2F60:01C345AD]
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Much of the content of this ID will look familiar to those with
experience with ITU-T systems control specifications (such as H.245).

Some of it seems like it could use a bit of updating in that regard
(e.g., videofastupdateGOB).
Draft Recommendation H.241 is one good place to look for such
information.

Section 3 is a bit confused in its terminology.  For example it seems to
say that intra frames are also known as inter frames, which is
definitely not the case.  It mixes the terms "predictive" and
"prediction" and seems to consider a "reference" frame to be synonymous
with an intra frame.  The terms "picture" and "frame" are also kind of
mixed up.

A more consistent terminology would be as follows:

An intra picture is a picture that can be decoded without first decoding
any other picture.

A predicted (or non-intra) picture is a picture that may require data
from one or more previously-decoded pictures in order to be properly
decoded.

A reference picture is a picture that is stored in the decoder for use
as a reference in the decoding process of some subsequent picture in the
bitstream.

A non-reference picture is a picture that is not used as a reference for
the decoding process of any other picture in the bitstream.

The concepts of intra versus non-Intra and reference versus
non-reference are independent.  A particular picture can (in general) be
any one of the four types (intra reference, non-intra reference, intra
non-reference, non-intra non-reference).

A "fast update", also known as an "instantaneous decoder refresh",
involves sending an intra picture and thereafter refraining from using
any picture sent prior to that intra picture as a reference for the
decoding process of any subsequent picture sent in the stream.

In particular it is worth noting that some concepts that applied to some
older codecs are not really valid in general and should be avoided
(e.g., that a non-reference picture is called a B picture or that an
intra picture is the same thing as a fast update or that an intra
picture is always a reference picture).

The characterization of a "slice" or "GOB" as being a "stripe" is not
really quite right.  For example, a single slice in MPEG-1, H.263 Annex
O, or MPEG-4 can consist of a few macroblocks at the right edge of one
row and a few macroblocks at the left edge of the next row (i.e., two
distinct rectangular regions quite far apart from each other in the
picture can be in a single slice).  A GOB in H.261 CIF consists of THREE
partial rows of macroblocks extending only halfway across a picture.
And in H.264/AVC, a slice can be ANY collection of macroblocks scattered
around absolutely anywhere in the picture (by use of a feature known as
a "slice group map").

In regard to section 5.1 VideoFreezePicture, I believe H.262 (also known
as MPEG-2 Video) also supports a freeze picture release within the ITU-T
extension.

It is also possible to obtain random access recovery without a fast
update.  This is sometimes called "gradual decoder refresh".  See for
example the recovery point SEI message in H.264/AVC.

Best Regards,

Gary Sullivan


+> -----Original Message-----
+> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On 
+> Behalf Of Andrea Basso
+> Sent: Monday, July 07, 2003 2:34 PM
+> To: avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org
+> Cc: casner@acm.org; jo@tzi.uni-bremen.de; 
+> magnus.westerlund@ericsson.com; csp@csperkins.org; Orit 
+> Levin; Roni Even; nismail@cisco.com
+> Subject: [AVT] Requirements draft on video control
+> 
+> 
+> Attached you will find draft-basso-avt-videoconreq-00.txt
+> 
+> Abstract:
+> 
+> A variety of communication services such as video
+> conferencing and video messaging rely on the capability of video
+> encoders and decoders to exchange control commands. This document
+> outlines this set of commands as well as the requirements for
+> their transport.
+> 
+> Comments are more than welcome.
+> 
+> 
+> 
+> 
+> 
+> Andrea Basso
+> NMS Communications
+> (732) 936-2118
+> (See attached file: draft-basso-avt-videoconreq-00.zip)
+> 

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt