ITU Telecommunication Standardization Sector	Document AVC-579R
Study Group 15	September 10, 1993
Experts Group for ATM Video Coding	
(Rapporteur's Group on Part of Q.2/15)

Source:	RAPPORTEUR (Sakae OKUBO)	
Title:	REPORT OF THE THIRTEENTH EXPERTS GROUP MEETING IN BRUSSELS (September 2-10, 1993) - Part III	
Purpose:	Report	

-----------------------

Part I	General (see AVC-578R)
Part II	Sole sessions (see AVC-578R)
Part III	Joint sessions with MPEG

Part III  Joint Sessions with MPEG

Contents

1. 	Introduction
2. 	REQUIREMENTS sub-group
3. 	VIDEO sub-group
4. 	IMPLEMENTATION STUDIES sub-group
5. 	SYSTEMS sub-group
6.	ITU-T closing session

1. Introduction

The joint sessions with MPEG were held at Brussels Europa Hotel during 6-10 September 1993 at the kind invitation of the European Communities, DGXIIIB - Advanced Communication.  At the opening session on 6 September, Mr. Roland Hüber -Director of DGXIIIB Advanced Communications Technologies and Services- made a welcoming address on behalf of the hosting organization.  His welcome speech is found in MPEG93/841.

The Experts Group appreciated the support and hospitality of the hosting organization.

A list of documents considered during the joint sessions is attached to this report as Annex 1.

2. REQUIREMENTS sub-group (K. McCann)

2.1	Introduction

The Requirements Group met every day from 6-10 September 1993.  Ken McCann acted as Chairman in the absence of Sakae Okubo.  The work programme for the week was as follows:

Monday: 	All available input documents were reviewed briefly and a list of discussion items was drawn up.
	
Tuesday: 	Consensus was reached on the initial discussion items.  There was a joint meeting with Test Group to exchange views on the priorities of the various video performance verification tests. 
	
Wednesday:	Consensus was reached on most of the remaining discussion items.  There were joint sessions with Video and Implementation to discuss common issues and with DSM to review Requirements for DSM control command specification.
	
Thursday:	Consensus was reached on the final discussion items.  An editorial group was set up to document the decisions that had been taken in Chapter 8 and Annex D of the Video WD.  There was a joint meeting with Video and Test Groups to review priorities for video performance verification testing.  
	
Friday:	Draft versions of the Video WD chapter 8 and the part of Annex D dealing with Profiles and Levels were reviewed. Resolutions of the Requirements sub-group were agreed.  There was a brief joint meeting with Video (and Systems) to discuss verification testing of the complete MPEG system by simulation and hardware.	

2.2	Input Documents Considered

WG11 N0489	Requirements	Agreements on Profile/Level	
MPEG93/736	Erdem	Ad-hoc group on 10-bit Video	
MPEG93/738	Okubo	Ad-hoc group on editing syntactic elements	
MPEG93/741	Teichner	Ad-hoc group on requirements for verification tests	
MPEG93/742	Le Gall	Ad-hoc group on conformance testing	
MPEG93/762	Wise	Problems with specification of profiles	
MPEG93/763	Wise	Compliance in MPEG-2	
MPEG93/769	Biggar	Proposal for a profile incorporating minimum complexity scalability	
MPEG93/787	Koster	Next Profile parameters for 4:2:0 formats	
MPEG93/792	UK NB	UK National Body Position Paper	
MPEG93/818	Fernando 	Proposal for next Profile at Low Level	

2.3	Requirements Issues Discussed

2.3.1	Definition of the Next Profile

Some concern was expressed that a fully compliant Next Profile decoder would be very complex and expensive to implement, particularly in the initial years of the MPEG-2 standard.  However, as there was an application area represented by ITU-R which required all of the functionality of the Next Profile, the consensus was to leave the definition unchanged with one exception.  The upper bound for the total number of layers (SNR plus resolution) in the High and High-1440 Levels was reduced from 4 to 3 on the advice of the Video and Implementation sub-groups.

Support for H.261 decoding in the base layer of the Next Profile was an outstanding issue which needed to be clarified from the previous meeting.  In consultation with the ITU-T representatives, it was agreed that support for H.261 decoding of the base layer of Next Profile would not be an absolute requirement for a decoder to pass an MPEG compliance test, but the following sentence should be added to WD: "For multipoint video-conferencing, it may be required that for Next Profile at Main Level the base layer be an H.261 video bit stream".

2.3.2	Definition of a Main Plus Profile

Although there was a desire to restrict the number of Profiles to 3, as stated in New York, it was agreed after consideration of  MPEG 93/769 that a "Main Plus" profile would be created which is a superset of Main and a subset of Next.  The less desirable alternative would be the evolution of a number of potentially incompatible sub-profiles within the Next Profile.

The Main Plus Profile will support up to 2 layers of SNR scalability at all levels.  In addition, it will support up to 2 layers of Spatial Scalability (with a maximum total of 3 SNR + scalable layers) at the High-1440 level.  See Table 1 below.  There was consensus that it was more useful to treat the number of layers of spatial scalability as a parameter which may vary with level rather than as a syntax element which necessarily requires a new Profile, as a strict interpretation of the original definitions of Profiles and Levels might imply.

High Level	Total # of layers
 # Resolution layers
 # SNR layers	
X	3
2
2	
High-1440 Level	Total # of layers
 # Resolution layers
 # SNR layers	3
2
2	3
2
2	
Main Level	Total # of layers
 # Resolution layers
 # SNR layers	2
1
2	3
2
2	
Low Level	Total # of layers
 # Resolution layers
 # SNR layers	2
1
2	
X	
		Main Plus Profile	Next Profile	

Table 1  Upper bounds for Scalable Layers in Main Plus and Next Profiles:

2.3.3	Definition of a Profile including support for 4:4:4 and 10 bits

Following consideration of document MPEG93/736, it was agreed that there was not yet sufficient information to decide on whether or not there a need for a Profile which includes support for 4:4:4 formats and 10 bit resolution.  However, tools to support 4:4:4 and 10 bits should be retained in the WD syntax.  An ad-hoc group was formed to draft the requirements for such a Profile.  If found to be useful, the Profile would be a superset of the Next Profile and would be added to MPEG by means of an amendment.  It was noted that simulation results need to be provided by at least 2 independent organisations.

2.3.4	Names and Indication Codes for Profiles and Levels

There were no suggestions for alternative names for any of the Profiles or Levels and so they were left unchanged.  The Profile and Level indication codes shown in Tables 2 and 3 below were agreed.  For these Profiles and Levels the value of the Escape bit is 0.

Profile identification	Profile	
110 to 111	(reserved)	
101	Simple	
100	Main  	
011	Main Plus	
010	(reserved)	
001	Next	
000	(reserved)	

Table 2  Profile Identification

Level identification	Level	
1011 to 1111	(reserved)	
1010	Low	
1001	(reserved)	
1000	Main	
0111	(reserved)	
0110	High 1440	
0101	(reserved)	
0100	High	
0000 to 0011	(reserved)	

Table 3  Level Identification

It was agreed that the profile_and_level_indication value of 11111111 should be reserved for experimental use within MPEG.

2.3.5	Profile/Level Combinations defined as Compliance Points

It was agreed that the 11 Profile/Level combinations ticked in Table 4 below should be defined as compliance points within the November CD.  A decoder which is compliant to a particular level of a particular profile will be able to decode any bitstream which is compliant with that profile/level combination or a profile/level combination either below or to the left of it on the table.  As agreed at New York, a Simple Profile Main Level decoder is also required to be capable of decoding a Main Profile Low Level bitstream.   

High Level
		√		√	
High-1440 Level		√	√	√	
Main Level
	√	√	√	√	
Low Level
		√	√		
	Simple Profile	Main Profile	Main-Plus Profile	Next Profile	

Table 4  Profile/Level Combinations Defined as Compliance Points

2.3.6	Sample Rates

Following consideration of document MPEG93/787, the Implementation sub-group advised that there was unlikely to be any increase in implementation cost if the luminance sample rate in the Next Profile were allowed to be one third higher for 4:2:0 than for 4:2:2 chrominance formats.  This imposes a fixed limit on the total sample rate (luminance + chrominance) rather than just on the luminance sample rate.  It was agreed to adopt this approach as it would permit support for half SCIF at the Main Level of the Next Profile.  The upper bounds for the luminance sample rate were defined to be as specified in Table 5 below.

High Level	Upper resolution layer	X	62.7	X	62.7  (4:2:2)
83.6  (4:2:0)	
	Lower resolution layer	X	n/a	X	14.75  (4:2:2)
19.66  (4:2:0)	
High-1440 Level	Upper resolution layer	X	47.0	47.0	47.0  (4:2:2)
62.7  (4:2:0)	
	Lower resolution layer	X	n/a	10.4	11.06  (4:2:2)
14.75  (4:2:0)	
Main Level	Upper resolution layer	10.4	10.4	10.4	11.06  (4:2:2)
14.75  (4:2:0)	
	Lower resolution layer	n/a	n/a	n/a
	-
3.05  (4:2:0)	
Low Level	Upper resolution layer	X	3.05	3.05
	X	
	Lower resolution layer	X	n/a
	n/a	X	
		Simple	Main	Main Plus	Next	
		Profile	

Table 5  Upper bounds for luminance sample rate (Msamples/sec):

2.3.7	Sampling Density

Upper bounds for the number of samples per line, lines per frame and frame rate were agreed to be as defined in table 6 below.  Note that the upper bound for the product of these parameters is set by table 5 above.

High Level	Upper resolution layer	Samples/line
Lines/frame
Frames/sec	
X	1920
1152
60	
X	1920
1152
60	
	Lower resolution layer	Samples/line
Lines/frame
Frames/sec	
X	
n/a	
X	960
576
30	
High-1440 Level	Upper resolution layer	Samples/line
Lines/frame
Frames/sec	
X	1440
1152
60	1440
1152
60	1440
1152
60	
	Lower resolution layer	Samples/line
Lines/frame
Frames/sec	
X	
n/a	720
576
30	720
576
30	
Main Level	Upper resolution layer	Samples/line
Lines/frame
Frames/sec	720
576
30	720
576
30	720
576
30	720
576
30	
	Lower resolution layer	Samples/line
Lines/frame
Frames/sec	
n/a	
n/a	
n/a	352
288
30	
Low Level	Upper resolution layer	Samples/line
Lines/frame
Frames/sec	
X	352
288
30	352
288
30	
X	
	Lower resolution layer	Samples/line
Lines/frame
Frames/sec	
X	
n/a
	
n/a	
X	
			Simple	Main	Main+	Next	
			Profile	

Table 6  Sampling Density

2.3.8	Bit Rates

The upper bounds of the bit-rates were agreed to be as given in Table 7 below.  Following discussion of MPEG93/762, it was also agreed that the ratio of bitrate to picture rate should be bounded so as to ensure that the picture rate is greater than or equal to 23.976Hz when the bitrate is at its maximum value.

High Level	
X	
80	
X	100 all layers
80 mid + base layer
25 base layer	
High-1440 Level	
X	
60	60 all layers
40 mid + base layer
15 base layer	80 all layers
60 mid + base layer
20 base layer	
Main Level	
15	
15	-
15 both layers
10 base layer	20 all layers
15 mid + base layer
4 base layer	
Low Level	
X
	
4	
4 both layers
3 base layer	
X
	
	Simple Profile	Main Profile	Main+ Profile	Next Profile	

Table 7  Upper Bounds for bit-rates

2.3.9	VBV Buffer Size

In consultation with the Implementation sub-group, values for the VBV buffer were calculated by scaling from the value of 1,835,008 @ 15 Mbit/sec already defined for Main Profile, Main Level.  These are as given in Table 8 below.

High Level	
X	
9,786,709	
X	12,233,386
9,786,709
3,035,346	
High-1440 Level	
X	
7,340,032	7,340,032
4,893,354
1,835,008	9,786,709
7,340,032
2,446,677	
Main Level	
1,835,008	
1,835,008	-
1,835,008
1,223,338	2,446,677
1,835,008
489,335	
Low Level	
X
	
489,335	-
489,335
367,001	
X	
	Simple Profile	Main Profile	Main+ Profile	Next Profile	

Table 8  VBV Buffer size requirements (Mbits)

2.3.10	Sample Aspect Ratio

At the previous meeting, Requirements had requested the inclusion of three values of sample aspect ratio not previously in the WD but had not made it clear how this was to be accomplished.  The table of values of sample aspect ratio was re-examined and the values shown below in Table 9 were agreed upon.  The values were chosen to correspond more closely to actual or proposed video formats.  Note that the term sample aspect ratio was used in preference to the previous term of pel aspect ratio to bring the terminology in line with that used by ITU-R.

sample_aspect_ratio	height/width	accurate numbers	example 	
0000	forbidden			
0001	1.0000	1920x1080 16:9	VGA etc. (square pel)	
0010	0.6855	1440x1152 16:9	1440x1152	
0011	0.6867	702x575 16:9	16:9 13.5MHz 625line	
0100	0.75	1440x1080 16:9	1440x1080 16:9	
0101	0.7826	1440x1035 16:9	1440x1035 16:9	
0110	0.8280	711x483 4:3	16:9 13.5MHz 525line	
0111	reserved			
1000	0.9157	702x575 4:3
936x575 16:9	ITU-R 601, 625line
16:9 18MHz 625line	
1001	reserved			
1010	1.0435	1920x1035 16:9	1920x1035 16:9	
1011	reserved			
1100	1.1040 	711x483 4:3
948x483 4:3	ITU-R 601, 525line
16:9 18MHz 525line	
1101	reserved 			
1110	reserved 			
1111	reserved 			

Table 9  Sample Aspect Ratios

2.3.11	MPEG-2 Verification Testing 

In a joint session with Video (and Systems), the following four stages of verification testing were identified:

1.	syntax verification by independent bitstream exchange for Audio, Video and Systems, aspects
2.	performance verification by formal subjective tests of quality and demonstrations of functionality for Audio, Video and Systems aspects (based on simulation results)
3.	software simulation of complete system functionality
4.	hardware verification of complete system functionality

It was agreed that only elements of the video syntax which had passed stage 1 would be included in the CD in November 1993.  The timescale for the completion of stages 2 to 4 was November 1994, when the IS was due to be produced.  The Test sub-group was taking care of stage 2 (see 3.12), but only CCETT indicated that it was working on stage 3.  Only C-Cube was prepared to indicate that it was likely to have some results on stage 4 by November 1994. More discussions on this subject will be needed at the Seoul meeting.

2.3.12	Priorities for MPEG-2 Video Quality Verification Testing

In joint sessions with Video and Test, the priorities for video quality verification testing were agreed to be as given below:

1.	MP@ML full test programme (quality over a range of bit-rates, multiple MPEG encode/decode, 723 codec, PAL codec, channel hopping, etc.)
2.	M+P@ML quality over a range of bit-rates
3.	NP@ML quality over a range of bit-rates
4.	SP@ML quality over a range of bit-rates
5.	MP@H-1440 and MP@HL quality over a range of bit-rates

2.3.13	Application of the concept of Profiles and/or Levels to Systems

Subsets of MPEG-2 Systems already exist due to the distinct Transport and Programme streams.  The view was expressed that this may not be all that will be needed, but it was agreed that it would not be practical to include more in the November CD.

2.4	Video Working Draft

It was agreed that the normative part of the Profiles/Levels definition should be in Chapter 8 of the Video CD, plus an informative section within Annex D.  The following editorial comments were raised after Chapter 8 was printed and distributed as MPEG93/844:

1.	Sample rates may be rounded (e.g. should it be 10.368 instead of 10.4 Msamples/s ?)
2.	VBV buffer values may be rounded
3.	Vector ranges need discussion
4.	Terminology for 2-layer SNR scalability is confusing (top and middle layers)
5.	Limit on ratio of maximum bitrate to minimum picture rate needs to be inserted (see 3.8 above)
6.	P10, L39:	should read "<0:489335]"
7.	P11, L2:	Intra_dc_precision should be 8, 9, 10 or 11 bit for Next Profile
8.	P13, L35	should read "Low Level" not "Main Level"

An ad-hoc group was set up under the chairmanship of Sakae Okubo to edit the parts of Video WD relating to Profiles and Levels.

3. VIDEO sub-group (G. Bjøntegaard)

3.1	Bit stream verification

Bitstreams have been exchanged and checked.  15 companies have provided bitstreams to the ad. hoc. group.  All the bitstreams are for MP@ML.  This is of great concern - specially concerning NEXT profile which need to be verified before the next meeting.  Some minor problems detected during crosschecking of bitstreams were reported and fixes proposed.

3.2	Scalability

In connection with the new profile - MAIN+ - which includes SNR scalability, some time was spent on clarifying and defining SNR scalability.  The result is seen in the WD.

A proposal for simplifying the MB type table for spatial scalability was also worked out.

3.3	Data partitioning

This was an issue specially raised from the ATM side.  It was accepted to include data partitioning in the WD.  The syntax is there and the description is in the informative part.  The definition is based on the document AVC-577 - giving room for changing PBP at the slice level.  It should be pointed out that DP is not part of any profile.  It is in the WD for possible future use as requested from the ATM side.

3.4	VBV

The problem with first picture addressed in AVC 563 was solved - although in a different way than proposed in AVC 563.

The bit to signal low delay that we requested in Sydney was now accepted!  It is in the sequence extension and is set if the sequence contains no B-frames.  The introduction of this bit was felt to be necessary to solve the problem with picture skipping (or decoder buffer underflow).  The decoder buffer is now allowed to underflow only if this bit is set.

The definition of VBV is now extended to cover also the case of VBR.

3.5	Compatibility with H.261

Video discussed the use of spatial scalability with H.261 in the lower layer and with low delay.  Problems were foreseen concerning time reference since both the layers might have skipped frames - but not necessarily the same pictures.

Generally the status of H.261 compatibility seems unclear at the moment.

3.6	Resolution concerning untested tools

Video made a resolution stating that tools not tested can not go into the standard.  This specially important for all scalability items.  A list of volunteers to exchange bitstream involving  SPATIAL SCALABILITY, SNR scalability and DATA PARTITIONING was produced.  However the number of labs in that list is on a minimum level and it is therefore very important that the labs that have committed themselves to exchange scalable bitstreams do so before Korea. Otherwise some of the scalable tools may drop out just because they have not been tested properly.

4. IMPLEMENTATION STUDIES sub-group (G. Morrison)

There was no meeting of the Implementation Studies subgroup.  Instead there was a short joint session of Requirements, Video and Implementation.  The main issue put to Implementation was the claim that decoder complexity was more related to the total number of luminance and colour difference samples than just to the number of luminance ones.  The joint meeting agreed to the proposal originally made by PTT NL, at the ITU-T sole session, to change the picture size definition to take account of the colour subsampling ratio and thus encompass half rate SCIF at 4:2:0. within Main Level.

5. SYSTEMS sub-group (D. Schinkel)

5.1	Introduction

The systems sub group met for five days to update the WD produced in New York.  Most time was spent on details, omissions and ambiguities, but some time was spent on ATM transmission.

5.2	PES semantics for PES_packet_length field

AVC-730 which proposed support PES_packet_length undefined for PES of any elementary stream type in the case when neither Program Stream nor Transport Stream delivery is used was discussed in the MPEG Systems sub-group.

The proposal did not receive a "warm welcome" by the groups for the following reasons:

•	PES is intended primarily as a building block for Program Streams or Transport Streams and a convenient mechanism for constructing one from the other. Only secondarily is the PES intended to be an end-to-end delivery mechanism. Relaxation of the semantics of the PES packet would complicate PS to TS conversion and would hinder interoperability.

•	Audio and private data streams may emulate start codes. For these streams, PES length indicator is required.

•	The Transport Stream has a PES header indicator bit to assist in PES parsing which is not present in the Program Stream.

•	Due to the large encoder and decoder delay of the video relative to the audio elementary stream, (the audio will likely have to wait for the video).  Therefore, the delay introduced to audio by computation of PES length is not a problem.

•	The MPEG Systems group recommends that the ITU-T working group 15 re investigates the use of the Transport Stream for their applications.

Later discussion on the issue lead to the conclusion that:

The semantics will not be relaxed unless but the sub group is willing to reopen the issue in the November 93 meeting if required , when there is contribution specific to use of MPEG systems of PES_packet_length = 0 within a transport stream or program stream environment  

5.3 Mapping of TS onto AAL

The paper on the mapping of MPEG Systems onto AAL was brought to the attention of the Systems Group.  Due to the large number of pressing issues on the Systems sub-group agenda, this subject was not discussed at any length.

It was indicated that some of the participants are seriously working on ATM implementations (for the short term).

5.4 Possible mappings of MPEG bit streams onto AAL

A small group digestion of the reviewed papers and the answers from the systems group lead the following analysis:

1)	Why would utilisation of the PES as an MPEG stream be beneficial?

The advantage of utilising PES directly onto AAL would enable a natural parsing of video bit stream, since PES can have an arbitrary length.  This could be beneficial for reducing the effect of cell loss.

Alignment of PES and ATM cells should be provided by the AAL.

2)	Would other mechanisms (like utilisation of PS or TS) have drawbacks?

There are two possibilities; the program stream and the transport stream.

•	PS would give:
•	an arbitrary length, so alignment with video slices can be maintained
•	increase of overhead due to program stream overhead (see fig S1)

•	TS would give:
•	Alignment with video slices is possible, but might increase the overhead, due to stuffing
•	other mechanisms to reduce spreading of errors like the convention that in a TS the PES starts at a TS packet boundary.
•	increase of overhead due to program stream overhead (see fig S2)

As an initial start for the comparison the following figure was made (fig S3):

	figure S.3 generalised MPEG systems versus. AAL mapping

The figure describes tree ways to map onto AAL.

1.	From PES to PS to AAL
2.	From PES  to AAL
3.	From PES to TS to AAL

There is no specific AAL type mentioned. The percentages are averages for 4 Mbit/s video, 25 frame/s and 44 rows per picture.

Conclusion

•	The choice for utilisation of PES, PS and TS still has many open issues. 
•	MPEG systems WD defines only PS and TS as streams; PES is not a defined end-to-end delivery.
•	Both PS and TS are good candidates for H.22x.
•	Alignment with ATM cells is possible using PS or TS, with the cost of an increase in overhead

5.5 Other issues

Most time was spent on the details of the draft working draft. The main issues were:

•	Reshuffling of PES field flags
•	PSI segment alignment
•	Program table

Joint meeting of Video and Systems

The syntax to accommodate layered coding was modified.  MPEG systems is capable to support hierarchical coding for all layered techniques that are in the video syntax.  Simulcast was not considered  for this descriptor.

User multiplexing (e.g., MPEG Program Stream, Transport Stream Single Program or Transport Stream Multi-program) or Network multiplexing (e.g., ATM VC or VP multiplexing).

6. ITU-T closing session (G. Morrison)

The ITU-T closing session took place at 1130-1230 on 10 September.  The agenda was as below:

Agenda for closing session 10 September 1993.

1.  Review of TD-9 version 2.

2.  Reports back

•	Systems: Dolf Schinkel.  Response to AVC-570.

•	Video: Gisle Bjoentegaard.  VBV (AVC-563) and 3:2 pulldown.  Data partitioning (AVC-577).  Spatial scalability.  Upsampling filters.  Corrections to AVC-564.

•	Requirements: Barry Haskell.  Response to AVC-574 (level parameters for NP).  New Main Plus profile.  H.261 (embedded and simulcast).

•	Liaison: Mike Biggar. To ITU-T from WG11 regarding Systems and Audio.

•	Implementation: Geoff Morrison.

3.  Approval of Video WD (including profiles and levels chapter).

4.  Actions for Seoul meeting.

5.  Other business.

There were verbal reports from Haskell, Bjoentegaard, Biggar and Morrison.  Schinkel had a written report on the Systems meeting.

A correspondence group was suggested to continue with ATM transport of MPEG.

Item 3 was to remind participants that approval at the afternoon MPEG plenary would include the profiles and levels.
 
Actions for the next meeting were identified as:

•	AVC-578R §6.1(3)
•	AVC-578R §6.2.2  "Members are requested to react to this proposal ......"
•	AVC-578R §8.2  "The meeting concluded to make efforts ...."
•	AVC-578R §8.3  "Mr Morrison requested       .  As a first action      "
•	Bit stream exchanges, especially scalability.

Mr Nam reiterated the need to make Daejeon hotel reservations by 26 September.

END

*    *    *

Annex	List of Documents for the Joint Sessions in Brussels