ITU - Telecommunications Standardization Sector
STUDY GROUP 16
Video Coding Experts Group (Question 15)
_________________
Third Meeting: Eibsee, Bavaria, Germany, 2-5 December, 1997	Document  Q15-C-30
Filename: q15c30.doc
Date generated: 01/12/97	

Question:	Q.15/16	
Source:	Stephan Wenger
TU Berlin, Sekr. FR6-3
Franklinstr. 28-29
D-10587 Berlin, Germany	
Tel:
Fax:
Email:	
+49 172 3000813
+49 30 31425156
stewe@cs.tu-berlin.de	
Title:	VRC simulation results and a new scalability mode based on Annex N	
Purpose:	Information	
_____________________________

The rest of this document is an extended abstract submitted to the ’98 DCC conference.  It covers, additional to an introduction to the Reference Picture Selection mode of H.263 V.2, two mechanisms of that mode:

•	Video Redundancy Coding, and
•	A new temporal scalability mode, which offers scalable latency time (which is not possible in case of Annex O temporal scalability.

While various demonstrations have already shown the effectiveness of H.263 V.2, this is the first document presented to this group which compares VRC to the other error resilience mechanism for suitable for high packet loss rates, which is the more frequent sending of I-frames.  The performance and bitrate requirements of VRC are comparable to a more frequent sending of I-frames, whereas its real-time characteristics are better.

The new temporal scalability mode based on Annex N relies completely on P-frames, and allows at a bitrate penalty of around 20% the scalability of the latency, which cannot be achieved by using B-frames.

Both mechanisms are intended for the use in conjunction with the H.263+ payload specification on the Internet.  Simulation software, which performs real-time communication over the Internet is already available for VRC (see Q15C31 for details); software for the other mechanism will follow shortly.

Two new usage forms of the Reference Picture Selection Mode of H.263V.2 for low latency interactive applications

Stephan Wenger †, Gerd Knorr †, Jörg Ott ‡
{stewe, kraxel}@cs.tu-berlin, jo@tzi.uni-bremen.de
† Technische Universität Berlin, Germany
‡ Universität Bremen, Germany

ABSTRACT
This paper introduces two new mechanisms based on the ‘Reference Picture Selection mode’ of H.263 Version 2, formerly known as H.263+.  Both of them are intended to be used on packet networks, mainly on the Internet or similar networks, with packet sizes around one Kbyte or larger. The first mechanism, called Video Redundancy Coding, is intended to improve the error resilience characteristics of the coded video data with its Inter Picture Prediction dependencies in case of packet losses. The second one is a scalability mode based on the Reference Picture Selection mode.  Both of these mechanisms are not intended to, and consequently do not improve the coding efficiency.  When compared to traditional mechanisms with the same goal, such as Forward Error Correction (FEC) or the layered codec approach of Annex O of H.263V.2 their performance is even worse.  However, they do have the great advantage of not adding or – in case of the scalability enhancement – even reducing the overall latency. This makes both schemes useful especially for interactive multimedia communication on networks like today’s Internet with high enough available bandwidth, but bad real-time characteristics.  

Introduction
One of the most interesting topics from both the video compression and the networking point of view is the transmission of coded video data over well-established packet network infrastructures like the Internet.  While some years ago, only very few people believed in the possibility of using the Internet ‘as is’ for any form of interactive multimedia communication, today, this form of communication is quite common.  Examples include Internet telephony and Internet videoconferencing systems, both applications are shipped in millions as commercial products.  Furthermore, the Mbone [1] is now a well respected tool not only for evaluating multimedia communication on the Internet, but also as a communication medium within and for the academic community.
This rapid development was accompanied by the emerging of international standards in both the Internet and the ITU-T community.  While in case of the Internet the IETF created mostly new transport oriented protocols like RTP [2] along with some session control mechanisms, the ITU-T designed a couple of recommendations known as the H.323 series [3]. This series was originally intended only for LAN-based videoconferencing, but it is now the base for most of both Internet-telephony and Internet-videoconferencing systems.  All those standards are designed for the use on today’s Internet.
In addition to those protocols and standards, the academic community has tried to make the Internet protocol hierarchy more useful for interactive multimedia communication systems by adding mechanisms to achieve guarantied quality of service (QoS).  The most prominent outcome of this discussion is probably the bandwidth reservation protocol RSVP [4], which would allow, if used in a sufficiently large part of the Internet, guarantied QoS virtual connections.  On those connections, multimedia communication would show commercially useful quality.  However, due to the unanswered question of billing in the Internet, bandwidth reservation hasn’t been widely introduced; in fact it is disabled by most ISP’s, although their router infrastructure is often capable of handling RSVP request.  We don’t expect that this situation will change on the Internet in the near future, and free guarantied QoS connection will most likely never become available outside the LAN / Intranet context.
The main problem on the Internet for any type of interactive multimedia communication is the problem of packet losses.  IP-packets can get lost on their way from the sender through various routers and data lines to the receiver, mostly because of overloaded routers, as well as for other reasons.  The packet loss probability on the Internet varies between 0% and 100%, depending on numerous factors like location of the sender or receiver, their connectivity to their ISP’s, and time (which influences network utilization).
As, in the near future, the Internet is not and will not be able to, offer guarantied QoS connections, researchers have tried to implement protocols and media coding techniques to achieve a reasonable QoS in terms of media quality on a low QoS network.  Since the usual transport protocols like TCP [5], which are based on retransmission of lost packets, cannot be used in case of interactive communication, because of the potentially long and unpredictable latency times, other mechanisms have to be introduced.  Three general classes of solutions for this problem were taken into consideration in the last couple of years:
1.	Suggestion to add functionality within the transport stack to transport the coded media.  Examples for this research include the adding of FEC data [6], or schemes like Audio Redundancy Coding [7].
2.	Attempt to make the media coding more robust against packet losses.  This can be done for example by avoiding any dependencies between data entities and thus allowing the correct decoding of the media information even if parts of this information got lost.  One example for this is the coding scheme introduced with the Mbone tool nv [8], which does not rely on Inter Picture Prediction.  The other prominent example is the coding used in most of today’s Mbone broadcasts, which is INTRA-mode only H.261 [9].
3.	Last but not least, Proposal to avoid packet loss situations by not overloading routers.  One well known approach for this might be receiver driven transportation, e. g. as known from [10] or [11].
The two new mechanisms, which will be discussed in this paper, clearly belong to the second category.
The version 2 of H.263, which will be in force by the time this paper is published, includes several mechanisms to minimize the influence of packet losses in the coded data stream. The most relevant new mode for interactive Internet video transmission is probably the Reference Picture Selection mode, Annex N of H.263V.2.  Both mechanisms introduced in the paper are based on that optional mode, and share many characteristics, which was the reason for introducing both of them in a single paper. A short description of that mode will follow in the next chapter. The reader should refer to Annex N of H.263V.2 for details.
Video Redundancy Coding (VRC), the first mechanism, will be introduced in the following section. VRC allows the decoding of coded H.263V.2 video after the occurrence of packet losses at a rate as high as 20% with minimal impact on the quality and no negative impact on the latency time at all.  The penalty one has to pay for this functionality is a substantial bitrate increase. 
After describing VRC, a new scalability mode will be presented, which is also based on the Reference Picture Selection mode and has no relationship with the Temporal, Spatial, and SNR Scalability Mode (Annex O) of H.263V.2.  The most obvious advantage of the new scalability support is its low latency time, which scales according to the frame rate of the enhancement layer. Again, the penalty for those positive characteristics is a lack of coding efficiency compared to both Annex O’s mechanisms or not using scalability at all.
After the introduction of each of the new mechanisms, we will present some simulation results showing their performance.  
The Reference Picture Selection mode of H.263V2
The various optional coding modes of H.263V2 can be categorized into either transport oriented, or coding efficiency oriented modes.  An example for the latter is the Reference Picture Selection mode, which is defined in Annex N of H.263 V.2.
In the earlier stages of the standardization of H.263V.2, this mode was intended for use in conjunction with back channel messages, which inform the coder about the situation of the decoder.  More precisely, the decoder can inform the encoder via a back channel message about:
•	The successful decoding of a frame by sending an ACK-message along with the Temporal Reference (TR) of the decoded frame as a picture ID, or
•	The unsuccessful decoding of a frame by sending an NACK-message and the TR of the frame not decoded, if this number is available – which is a condition that is indicated by the Unreliable-flag in the back channel message.

Based on this information, the encoder can use an ‘earlier’ frame in the sequence as the anchor frame for the subsequent P-frames.  Obviously, that anchor frame has to be chosen in such a way that it was transmitted and decoded correctly.  If no such frame is available, the only option the encoder has to achieve good picture quality is to send an I-frame.  In both cases, error accumulation can be prevented, and thus the artifacts are avoided, which are the results of even one missing P-frame in a sequence.

The data stream might contain a forward channel message, which informs the decoder about what frame should be used in conjunction with the transmitted P-frame.  If this forward channel message is not present, the usual mechanism, which is the use of the latest transmitted frame, is in charge.
The back channel mechanism is a very powerful means of making video coding based on Inter Picture Prediction tolerant against packet losses and the resulting frame loss/damage.  However, one can think about numerous applications in which back channel mechanisms are not advisable.  Examples of these include multicast or broadcast video transmission, or point to point communication over lines with long latency characteristics.  The latter will lead to the necessity of very ‘early’ reference frames (because of the long transmission delay of both the forward- and the back channel information) and thus to a very high coding penalty.
For those scenarios, a second form of the Reference Picture Selection mode was introduced, which is to use the forward channel syntax without any back channel mechanism.  The following sections of this paper describe two possible uses of this condition. 
Video Redundancy Coding 
The basic concept of Video Redundancy Coding (VRC) was already introduced in [12], so a brief summary of the mechanism itself will be sufficient here.  Most of this section of the paper will cover our new simulation results of this mechanism, which again shows its superior performance in terms of latency compared to all other error resilience mechanisms for packet networks.
Introduction to Video Redundancy Coding
Video Redundancy Coding is one form of usage of the Reference Picture Selection mode, which operates without the means of a back channel.  It can be used either on full frames, or on the independently decodable segments, which are well defined, rectangular parts of the picture (see Annex R of H.263V.2 for details).  The latter is especially useful on higher bitrate, bad quality connections.
The principle of VRC is to divide the incoming sequence of frames into two or more ‘threads’ in such a way that all incoming camera pictures are assigned to one of the threads in an interleaved manner.  Each of those threads is coded independently. From time to time, all threads converge into a so-called Sync frame, and later from this Sync frame, a new thread series is started.  If one of these threads are damaged by a packet loss, the rest of the threads remain intact and can be used for Sync frame prediction.  The following figure shows an example of two threads at three frames per thread.

Figure 1: VRC with 2 threads and 3 frames per thread

Obviously, the ‘frame rate’ within one thread is much lower than the original frame rate: half in case of two threads, a third in case of three threads and so on.  This leads to a substantial coding penalty because of the larger changes and longer motion vectors between two P-frames within a thread.
In case of a packet loss, the decoding of the damaged thread (in which the packet loss has occurred) can continue.

Figure 2: VRC with a packet loss in thread 2

Sync frames are always predicted out of one undamaged thread. If all threads are damaged between two Sync frames, a correct Sync frame prediction is no longer possible, and we are in the same situation as we were without Video Redundancy Coding.  For such cases, a sufficiently high number of I-frames have to be sent, but this number of I-frames can be significantly lower than without VRC.
The general advantage of Video Redundancy Coding compared to other temporal error resilience methods, like back channel mechanisms or FEC packets, is that it adds no latency time at all. However, this is bought by adding a substantial bitrate penalty for schemes, which provides acceptable error resilience at higher packet loss rates. Video Redundancy Coding is highly scalable, so that encoders can choose the VRC parameters according to the network characteristics, which can be easily monitored by mechanisms like RTCP.
Simulation Results
The following simulation results were generated using a common set of parameters (unless otherwise indicated):
•	The modified TELENOR tmn2.0 software codec was used for the simulation. The only modification worth mentioning was the inclusion of the Annex N functionality, but with a different syntax.
•	The sequences Foreman, Coastguard and Paris all of them in QCIF image size were used.  A fixed quantizer of 10 and a fixed frame rate were applied which resulted in a variable bitrate.  QCIF image size was used because both the bitrates and the necessary CPU power seemed to be useful for software based codecs and Internet connections.
•	None of the optional coding modes except our implementation of the functionality of Annex N was employed.  The results should be comparable with more complex mode configurations, although the bitrate should be somewhat lower.  Some information regarding the benefits of using the quality oriented optional modes of H.263V.2 as well as their impact on the complexity can be found in [13].
•	The rate of I-frames was chosen in such a way that every an I-frame was sent every 5 seconds, regardless of the frame rate. 
•	All sequences were looped for the duration of 5 minutes to prevent the influence of the random nature of the packet loss generator.  Additional simulations showed that that in worst cases influence is still in a 0.4 dB interval but in average somewhere less than 0.2 dB.

Sequence,
Frame rate	VRC-
Scheme	Packet
Loss	Data rate
(Kbit/s, %)	SNR	Remarks	
Paris	none	None	82.3 100%	29.6	Error free environment, no VRC	
Paris, 10 fps	None
2-2
2-5
3-3	10%	82.3  100%
111.0  135%
104.3  127%
121.8  148%	26.6
28.7
27.8
28.5	

2.2 dB SNR for 27% more bitrate
2.9 dB SNR for 48% more bitrate	
Paris, 10 fps	None
2-2
3-3	20%	82.3  100%
111.0  135%
121.8  148%	24.4
26.5
26.8	
2.1 dB SNR for 35% more bitrate
2.4 dB SNR for 48% more bitrate	
Paris, 30 fps	None
2-2
2-5
3-3	10%	148.8  100%
214.6  144%
204.2  137%
248.8  167%	25.6
28.4
27.7
28.3	
2.8 dB SNR for 44% more bitrate

Paris, 30 fps	None
2-2
3-3	20%	148.8  100%
214.6  144%
248.8  167%	23.6
26.0
26.2	
2.4 dB SNR for 44% more bitrate	
Foreman, 15fps	None
2-2
2-3
3-3	10%	92.8  100%
128.2  138%
125.0  135%
144.9  156%	24.4
27.5
28.1
28.7	

3.7 dB SNR for 35% more bitrate
5.3 dB SNR for 56% more bitrate	
Coastguard,
15 fps	None
2-2
2-3
3-3	10%	190.6  100%
252.7  133%
249.2  131%
280.0  147%	22.9
26.8
26.9
27.0	
4.0	dB SNR for 31% more bitrate
4.1 dB SNR for 47% more bitrate	
Table 1: VRC simulation results

A second set of simulations were run to check, whether or not a similar SNR gain can be reached by simply spending the additional bitrate for a higher amount of I-frames or by using a numerically lower QP.  Out of those simulation results, we only want to present the following examples, which are based on a packet loss rate of 10%.
The first three columns of this table do not need any further explanation.  The fourth and fifth columns contain the SNR using a variable number of I-frames to fill the bandwidth overhead introduced by VRC. The TMN5 rate control mechanism was used for that simulation.  The difference between the two data sets is that the data of the fourth column was generated assuming one lost packet (with a payload size of 1400 bytes) in an I-frame that lead to the loss of the whole I-frame, whereas the fifth column simulates a situation with unlimited packet size, so that one I-frame fits into one packet.  Similar results might be possible by splitting the I-frames into slices by the use of the Slice Structured Mode (Annex K).

Sequence and Parameters	SNR for VRC Scheme, 5s I-Frame Interval	SNR, variable QP, 5s I-Frame Interval	SNR, variable
Number of I-frames, unlimited packet size	SNR, variable number of I-Frames, packet size 1400 bytes	
Paris, 10 fps, 111 kbit/s	VRC 2-2: 28.7	27.1	28.5	27.0	
Paris, 30 fps, 214.6  kbit/s	VRC 2-2: 28.4	26.5	28.6	27.4	
Foreman, 15 fps, 125 kbit/s	VRC 2-2: 28.1	25.0	29.4	28.4	
Coastguard, 15 fps, 249.2	VRC 2-3: 26.9	23.2	28.4	26.7	
Table 2: VRC compared to other mechanisms
Discussion
The simulation results do show the superior performance of VRC-protection compared to a non-VRC protected data stream, whether or not the bitrate occupied by VRC is used by additional coefficient bits generated by applying a numerically lower quantizer factor.  However, it seems this is not the case when this additional bitrate is used to send more frequent I-frames, especially for unlimited packet sizes.  If the packet loss simulation is performed by a simple skipping of the data between two Picture Headers in the coded data stream, again VRC shows better performance.
Both variable I-frame scenarios are not totally realistic. For many networks including the Internet, the maximum advisable packet size is much smaller than the size of a coded I-frame even at QCIF size. On the other hand, the Slice Structured Mode offers a very useful mechanism for breaking up the whole I-frame into small packets that can be decoded completely independent from each other.  Using this mechanism and simulating packet loss as a loss of only one slice instead of the whole I-frame will lead to a significant improvement of the SNR, which comes close to that one of the unlimited packet size scenario.  Nonetheless, this leads to a picture in which some macroblocks in the scanning order show serious distortion while the surrounding picture quality is better.  Our experience shows that the resulting artifacts of that method are much more disturbing for most users than an overall bad picture quality.
It’s beyond the scope of this paper to even scratch the problems of an objective picture quality measurement, which is closer to the subjective picture quality observation of typical users than SNR based judgement.  We do not know about any picture quality scale, which weighs that type of artifacts strong enough.  Readers are encouraged to download our simulation software along with the data streams and make up their own mind on the subjective measurement by watching the decoded streams.
The last positive attribute of VRC we want to mention here is it’s superior real-time characteristics.  The overall latency (composed out of coding/decoding and transport delay) might be the same for VRC or for any other I/P-frame based coding scheme.  However, this is only true, if we assume a link of unlimited bitrate.  If the bitrate of the video connection is limited, then the theoretical transmission latency is the one for the largest coded frame (usually an I-frame), which can be around one second.  This latency comes in whether or not VRC is in use, because I-frames have to be sent also in case of VRC.  However, in this case, it is possible to achieve an acceptable latency after a short period by doing a faster playback, which in case of video is much less disturbing than in case of audio.  This is not possible with a high I-frame rate, because the time between two I-frames does not allow the graceful lowering of the delay. 
Temporal Scalability based on Reference Picture Selection
In this second part of this paper, we present our new temporal scalability mechanism based on the Reference Picture Selection mode of H.263V.2.  Before we start the introduction of that scheme, we want to introduce the temporal scalability, which is already defined in Annex O of H.263V.2.
Temporal Scalability of Annex O versus Temporal Scalability based on Annex N
One of the most prominent extensions of H.263 version 2 relative to version 1 of this recommendation is the inclusion of the very general approach of a layered codec. Three different types of layering are defined in H.263V.2 Annex O:
•	Temporal scalability, which is the enhancement of the temporal resolution (frame rate) by the transmission of B-frames between two anchor frames, which can be either P- or I-frames.
•	Spatial scalability, which is the enhancement of the picture size by a factor of two in each spatial dimension. This is done by the transmission of a difference image, which is constructed out of the up- scaled reference image and the original image.
•	SNR scalability, that allows the increase of the overall quality of a picture (and thus increasing the SNR) by the transmission of a difference image. This difference image is constructed out of the reference image and the original image by using a numerically lower quantizer factor than the original base layer coding.
All three scalability submodes can be used individually, or in conjunction with the others. H.263V.2 allows both the transmission of each base- or enhancement-layer in its own transport stream, and the multiplexing of more than one layer into an individual transport stream.
Since we are focused with our new scheme on temporal scalability only, the further discussion will be only on that type of scalability, and not on the spatial and SNR scalability. The latter two can be used in conjunction with both the original Annex O temporal scalability, or with our scheme.
The big advantage of the temporal scalability of Annex O is the very efficient coding, which is possible by using B-frames.  Since it is forbidden to use B-frames as anchor frames of any kind, they can usually be coded with somewhat numerically higher quantizer factors.  This, and their bidirectionally predicted nature, allow a very small coded frame size which is often smaller than the size of the P-frame with the same temporal reference (TR).
However, this advantage is bought by having a similar latency time as the base layer has for a layered codec using B-frames, although the frame rate might be twice as high or even higher compared to the base layer.  Even worse, this assumption is only true if we consider both coder and decoder taking zero time for the coding of the B-frame, and that the B-frame takes zero time for transmission.  However,  we have to consider bandwidth-limited links, and codecs which are not much faster than their possible frame rate.  This is the case for most of today’s software and hardware based codecs.  In this non-theoretical case, the use of B-frames will often induce an additional latency time of one frame time of the base layer or even more.  This means that if our base layer is 15 fps, and the enhancement layer will be used to increase the frame rate to 30 fps, we may have an additional coding/decoding delay of 1/15th of a second or 62.5 ms in addition to the usual delay of 2 frames for P-frame sequences, which is 133 ms.  We see no way of avoiding this penalty, and our estimation is that the additional delay for using B-frames will often be even higher than the one stated above.  Even under optimal conditions, which are zero transmission time, zero additional transmission delay and unlimited processing power in both coder and decoder, we will not be able to improve the latency time of the whole system by using Annex O temporal scalability.
While the Annex O temporal scalability scheme is optimized for a higher coding efficiency at the cost of higher latency, our approach goes in the opposite direction.  The temporal scalability based on the Reference Picture Selection mode has a substantial bitrate penalty compared to the Annex O scalability, but allows the decreasing of the latency time to the theoretical optimum.  This is, if we calculate the latency time for a P-frame-based coding/decoding as 2 frames at a given frame rate, for example, 133 ms at 15 fps, we can achieve half of the stated time above, by introducing our temporal scalability.  For the example above, this would mean a latency of 62.5 ms by sending an enhancement layer which improves the frame rate to 30 fps.  Whether the additional latency of using Annex O, or the additional bitrate introduced by using our scheme are acceptable depends on the application.  We think, that for many scenarios especially on the Internet with its potentially high transmission delays, the latter is the case.
The new temporal scalability scheme
The basic idea of our new temporal scalability scheme can be easily shown in the following figure. The base layer is a usual sequence of frames, which can be either P- or I-frames. The enhancement layer consists only of P-frames and uses the frames of the base layer as anchors. Two schemes are shown: first the enhancement of a 15 fps base layer to 30 fps by an enhancement layer, and second a base layer of 10 fps enhanced to 30 fps.

Figure 3: Principle of temporal enhancement using the Reference Picture Selection mode

The base layer is a usual sequence of I- or P-frames with a fixed frame rate, which is substantially lower than the maximum frame rate of 25 fps or 30 fps. The enhancement layer uses the frames of the base layer as anchor frames and the usual P-frame mechanisms for generating the enhancement layer P-frames.  The rate control for the enhancement layer can use a numerically higher quantizer factor without much visible impact, especially for the last frame of each enhancement layer sequence, to decrease the bitrate penalty introduced by the enhancement layer.  In software based coders, it is also possible to limit the motion vector search range for the enhancement layer by a reasonable amount, because at the given higher frame rates long motion vectors are less probable.  This means, that for e. g. the first example above, the amount of CPU time is not necessarily twice as high as for the coding of the base layer only.  This stands in a strong contrast to the high processing power demands of true B-frames of the original Annex O temporal scalability.
Bitrate and latency time
As already stated above, the new temporal scalability increases the bitrate and decreases the coding/decoding delay.
Obviously, the coding/decoding delay cannot be estimated here in much detail, because it is highly dependent on the codec implementation.  Often the overall delay of using the enhancement and the base layer together should be the same as if using the same codec configuration at the frame rate of the combined base- and enhancement layer. 
For the bitrate the described scheme was implemented and tested for the sequences Foreman, Coastguard, and Paris, all of them at QCIF size.  The small image size was chosen to show the performance of the scheme at speeds, which come close to those of an ISDN connection.  The details of the simulation environment were similar to those of the VRC simulation above: fixed Quantizer of 10 (used for both P- and B-Frames), fixed frame rate of 10 fps for the base layer and a temporal enhancement to 30 fps in the enhancement layer.  The achieved quality was always the same (less than 0.1 dB SNR difference) for all types of scalability tested here.  This result was expected, because the same number of frames was coded with the same QP.

Streams are in QCIF format, fixed QP 10 for both base and enhancement layers, Values in kbit/s

Stream	Base 10 fps	Base 30 fps	True B	Total PBB	New Enh.
Layer	New P-PP	
Paris	99.7	194.2	88.2	187.9	125.9	225.6	
Coastguard	157.4	300.3	133.9	291.3	199.3	356.7	
Foreman	90.8	168.1	76.1	166.9	110.4	201.2	
Table 3: Performance of the new temporal scalability scheme

Discussion
The new scalability mechanism based on the Reference Picture Selection mode offers a better real-time characteristic including scalable coding latency time at a bitrate penalty of about total 20%, which is 43% for the enhancement layer only.  This is independent from the amount of movement in the scenes, since the differences of the values for the three sequences are insignificant and within the statistical inaccuracy.
We tend to believe that these results make the new scalability mode a useful means for any type of interactive communication, if low bitrate is not the ultimate criterion.  However, future research has to verify our results on a more broad range of coding characteristics, which should be chosen according to the network scenarios that can be found in today’s real world of networking.
List of Tables
Table 1: VRC simulation results	6
Table 2: VRC compared to other mechanisms	6
Table 3: Performance of the new temporal scalability scheme	9

List of Figures 
Figure 1: VRC with 2 threads and 3 frames per thread	4
Figure 2: VRC with a packet loss in thread 2	5
Figure 3: Principle of temporal enhancement using the Reference Picture Selection mode	8

References
[1]: S. Casner: “Frequently Asked Questions (FAQ on the Multicast Backbone (MBONE)“, available from ftp://ftp.isi.edu/mbone/faq.txt
[2]: RFC xxxx: RTP
[3]: ITU-T Recommendation H.323
[4]: RFC xxxx: RSVP
[5]: RFC xxxx: TCP
[6]: J. Bolot, A. A. Vega-Garcia: “The Case for FEC-Based Error Control for Packet Audio in the Internet“, to appear in ACM Multimedia Systems
[7]: RFC xxxx (Audio Redundancy Coding)
[8]: R. Frederick: “Experiences with real-time Video Compression“, Proc. 6th Packet Video Workshop, Portland, OR, USA, Sept. 1994
[9]: ITU-T Recommendation H.261
[10]: S. McCanne, M. Vetterli: “Receiver-driven layered multicast“, Proc. ACM Sigcomm ’96, Stanford, CA, USA, Sept. 1996
[11]: J. Bolot, T. Turletti: “Experience with control mechanisms for packet video in the Internet“, INRIA report, March 1996
[12]: S. Wenger: “Video Redundancy Coding in H.263+“, Proc. AVSPN 97, Aberdeen, U. K., 1997
[13]: G. Cote, B. Erol, M. Gallant, F. Kossentini: “H.263+: Video Coding for Low Bit Rates”, submitted for publication in the special 1998 issue of the Transactions of Circuits and Systems for Video Technology

Authors Addresses and Affiliations

Dr. Stephan Wenger 
Technische Universität Berlin
Sekr. FR 6-3
Franklinstr. 28-29
D-10587 Berlin
Germany
Tel.: +49-172-3000 813
Fax: +49 30 314 25156
Email: stewe@cs.tu-berlin.de

Gerd Knorr
Technische Universität Berlin
Sekr. FR 6-3
Franklinstr. 28-29
D-10587 Berlin
Germany
Tel.: +49 30 314 73160
Fax: +49 30 314 25156
Email: kraxel@cs.tu-berlin.de

Dr. Jörg Ott
Universität Bremen
Arbeitsgruppe Rechnernetze
Bibliothekstr. 1
D-28359 Bremen
Germany
Tel.: +49 421 218 2085
Fax: +49 421 218 7000 
Email: jo@tzi.uni-bremen.de