RE: [AVT] Requirements draft on video control

["Even, Roni" <[e-mail]>]

Hi Gary

About
"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."

In case of a video switch in a multipoint conference there is a need to get
a new recovery point since the decoder will receive a stream without a
previous recovery point. The procedure in H.241 allows for either a full
picture at once or gradual recovery based on an SEI recovery point message.
Both method are fine as an encoder response to a fast update request.

Regards
Roni Even

-----Original Message-----
From: Gary Sullivan [mailto:[e-mail]]
Sent: Wednesday, July 09, 2003 3:03 AM
To: Andrea Basso; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; Orit Levin; Roni Even; [e-mail]
Subject: RE: [AVT] Requirements draft on video control



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: [e-mail] [mailto:[e-mail]] On 
+> Behalf Of Andrea Basso
+> Sent: Monday, July 07, 2003 2:34 PM
+> To: [e-mail]; [e-mail]; [e-mail]
+> Cc: [e-mail]; [e-mail]; 
+> [e-mail]; [e-mail]; Orit 
+> Levin; Roni Even; [e-mail]
+> 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
+> [phone]
+> (See attached file: draft-basso-avt-videoconreq-00.zip)
+> 

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt