ITU – Telecommunications Standardization Sector
STUDY GROUP 16
Video Coding Experts Group (Question 15)
Fifth Meeting: Whistler, Canada, 21-24 July, 1998	Document  Q15-E-13
Filename: q15e13.doc
Generated: 22 July ’98	

Question:	Q.15/SG16	
Source:	Stephan Wenger
TU Berlin, Sekr. FR6-3
Franklinstr. 28-29
D-10587 Berlin
Guy Cote
University of British Columbia
Department of EE, SPMG
2356 Main Mall
Vancouver, BC
V6T 1Z4	
Tel:
Fax:
Email:
Tel:
Fax:
Email	
+1 415 297-2063
+1 604 736-7853
stewe@cs.tu-berlin.de
+1 604 822-4988
+1 604 822-5949
guyc@ece.ubc.ca	
Title:	A simulation environment and interface specification for video transmission over H.324 mobile channels 	
Purpose:	Proposal and Discussion	
_____________________________

1.	Summary

This document is an updated version of Q11-F-06.  Changes relative to the latter are
•	Update of document numbers
•	Deleting of the CRC-error flag (to make it consistent with Q15-E-12, see there for more details).
This document contains a description of a simulation environment for performance testing of video codecs for mobile channels, along with an informal interface specification between a video codec and the rest of the simulation environment.  It is identical to Q11-F-06.  It should serve as a start-point for the development of such an environment, which will later facilitate decision on whether or not to adopt new features into forthcoming ITU-T video coding recommendations.  Additionally, simulations based on this environment might be helpful when making decisions regarding new codepoints for video coding standards of other standardization bodies.  At the appropriate time, the authors will formally propose such a simulation environment as part of the common conditions for performance testing of both H.263++ and H.263L proposals.  This document should be read in conjunction with document Q15-E-12, “Ideas for a H.263+ Test model and H.324M-Interfacing for mobile video”.
2.	Background

During the Tampere meeting of Q.11 and Q.15 (Q15-D and Q11-E) a need for a simulation environment for the transmission of coded video was observed from both Q.15 and Q.11 experts.  Various reasons contributed to this conclusion:
•	Q.11 discussed a proposal for the adoption of codepoints for MPEG-4 video into H.245V4 (Q15-D-59).  Q.15 experts were asked to provide an estimation of the performance of MPEG-4 video with the reversible VLC codes (which are deemed to improve error resilience significantly).  Q.15 experts had no data readily available for the relative performance of MPEG-4 video versus H.263v2 video in error-prone environments.  The issue was postponed to the Cannes meeting of Q.11.
•	Documents (from UCLA/Samsung Q15-D-37, Q15-D-39) were presented which showed a significantly higher reproduced picture quality when using data partitioning techniques (within a codec optimized for error prone environments) relative to the H.263v2 test model codec.  Q.15 experts felt, however, that this was a somewhat unfair comparison, because the current error-resilience mechanisms of H.263v2 were not used at all, and the H.263v2 test model is not designed for the error-prone environment.

Q.15 experts plan to add test model descriptions for error-prone environments (namely H.323/LAN/Internet and H.324 mobile) to the test model specification.  Data and environment are available for the Internet-case (Q15-D-14) and will be adopted into the next test model revision.  Q.15 experts had, however, not enough expertise to accurately simulate an (error-prone) mobile channel.  The test-software publicly available from UCLA does not cover the bi-directional transmission case (use of feedback channels, Reference Picture Selection mode).  This is in the opinion of the authors and several other Q.15 experts working on error-prone video transmission an important technique for achieving good error resilience. 

This document describes in the following a model for the video transmission of a H.324 mobile system. Two cases are covered: uni-directional communication, and bi-directional communication which allows for the transmission of back-channel information.  The last two sections of this document describe an informal interface specification between the video codec and the transport simulation for the two cases above.  UBC/TU Berlin will make a H.263v2 video codec optimized for error-prone environments available, which will follow this specification.  Q.11 mobile experts are asked to provide a transport simulation environment.

3.	Outline of the uni-directional test model

We believe that a good approximation of this case can be implemented as a straightforward process without any feedback.  We do understand that the varying sizes of AL3 PDUs have impact both on the net bit-rate available for video and on the error characteristics of this virtual connection.  Nevertheless, we propose a simple mechanism as described in the following sections to gain a fast way to perform simulations, hopefully before the next Geneva meeting of SG16.

3.1.	Algorithm description

Video is coded and packetized according to Q15-E-12 (unidirectional case).  This process can be summarized as follows: use GOBs with headers, and use sufficient INTRA-MB updates to achieve error resilience.
After packetization, AL3 SDUs are delivered to the mobile channel simulator.  This is done by the means of an input file, which consists of variable length records of a data structure as specified below.  Please note that later this file-interface might be replaced by a procedural interface of some kind.
The mobile channel simulator works by simulating the Mux layer and H.223 annexes in conjunction with error patters as chosen by Q.11 experts.  The output of the simulator is again a file with the same data structure.
This file is read by the de-packetizer and decoder.  It is interpreted according to the rules provided in Q15-E-12, which can be summarized as follows: any AL3-SDUs containing errors of any kind, are discarded.  It is understood, that this police might lead to a lower reproduced picture quality than using the (still available, although conspicuous) information available in the data.  But, for now, this model is easy to implement and provides, in conjunction with INTRA MB update still acceptable video quality.  Later versions of this model might describe more effective mechanisms for handling erroneous packets.
The de-packetized GOBs are fed into a standard H.263v2 decoder, after any lost GOBs left empty by the de-packetizer.  This will result in a non-compliant but decodable H.263v2 bit stream.  However, it will allow for an easy implementation of an error concealment technique since the missing GOBs are easily identified.  The error concealment technique described in H263v2 TMN-8 (TCON) will be used.

3.2.	File format

The file format and the C-structures (in future after integrating codec and simulator) are similar for both the interface between coder and channel simulator and the interface between channel simulator and decoder.

struct AL3SDU {
	uchar *payload;		// <length> bytes of H.263v2 payload
	int length;		// of the payload, in bytes
	int EI;			// 0 if no error (Mux or CRC), 1 otherwise
} 

EI, are set by the mobile channel simulator only.  They are left undefined by the encoder.  Both the length field and the payload are set by the encoder to identify the AL3 SDU, and might be patched during the channel simulation process.  The mobile channel simulator might also add or delete SDUs, or change their length.  Data area referenced by *payload is allocated by the producer, and is freed by the consumer.  That is, the encoder allocates data for *payload and the channel simulator frees this data.  After applying errors, the channel simulator allocates data again, which is later freed by the decoder.

The single record of the data file is as follows:

int length
uchar payload[length]
int EI  // 0 ifno error, 1 if error

Semantics are similar to the structure description above.
4.	Outline of the bi-directional test model

4.1	  Interface specification between codec/packetizer and transport simulator

Video is coded and packetized according to Q15-E-12 and is identical to the uni-directional case summarized in section 3.1.  As for error resilience modes, Annex N with an external back channel is used independently for each GOB.  The transport simulator delivers H.223 AL3 PDUs with an error pattern chosen by Q.11 experts applied to the packets.  No retransmission of AL3 PDUs will be used.  The de-packetization process follows the same procedure as described above in section 3.1.  The delivery of the packets follows the file format described in section 3.2. 

Please refer to document Q11-E-12 for a more detailed description of the proposed bi-directional simulation structure.  The back channel operation has to be kept simple and will be simulated by means of Callback functions through external means (i.e. the videomux mechanism of H.263v2 Annex N will not be employed).  Q.11 experts are asked to provide a back channel message delay simulation in the form of a Callback function to the video encoder and the video decoder will provide a Callback function to this delay simulation block with ACK/NACK information on GOBs base on AL3 PDUs information received from the de-packetizer. The minimum structure of the back channel message required by the encoder is (see section N.4.2 of H.263v2 for more details):

struct BCM {
	int BT;			// Back-channel message Type: 0 ACK, 1 NACK
int TR;			// Time reference for which the BM message is sent		
	int GN;			// GOB number
int RTR;	// Requested Temporal Reference:  TR of the last correctly decoded 
// video picture segment of the corresponding position at the decoder
} 

This information is passed by the decoder to the Back-channel message delay simulation block.  This module passes it to the H.263v2 encoder after the simulated delay has elapsed to close the loop.  The encoder then uses this information and can employ Annex N mechanisms on the corresponding GOBs.