ITU-T Telecommunication Standardization Sector	Document AVC-599R
Study Group 15	November 5, 1993
Experts Group for Video Coding and Systems 
in ATM and Other Network Environments

Source:	RAPPORTEUR (Sakae OKUBO)	
Title:	REPORT OF THE FOURTEENTH EXPERTS GROUP MEETING IN DAEJEON AND SEOUL (October 27 - November 5, 1993) - Part III	
Purpose:	Report	

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

Part I	General (see AVC-598R)
Part II	Sole sessions in Daejeon (see AVC-598R)
Part III	Joint sessions in Seoul

Part III  Joint sessions in Seoul

Contents

A. 	Introduction
B. 	REQUIREMENTS sub-group
C. 	VIDEO sub-group
D. 	IMPLEMENTATION STUDIES sub-group
E. 	SYSTEMS sub-group

A. Introduction

The joint sessions with MPEG were held at Sheraton Walker Hill Hotel in Seoul during 1-5 November 1993 at the kind invitation of KBS.  At the opening session on 1 November, Prof. Jae-Kyoon Kim, KAIST, made a welcoming address on behalf of the hosting organization.  

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.

B. REQUIREMENTS sub-group (by Sakae OKUBO)

B1. Introduction

The Requirements sub-group met every day from 1-5 November 1993 under chairmanship of Mr. Sakae Okubo and co-chairmanship of Mr. Ken McCann.  The work programme for the week was as follows:

Monday: 	Meeting of Ad-hoc group established at the plenary.  All available input documents were reviewed briefly and a list of discussion items was drawn up.

Tuesday: 	Ordinary sub-group meeting started.  There was a joint meeting with Video and Implementation sub-groups to identify the items needing advice of the two sub-groups.  Consensus was reached on the discussion items and time schedule during the week.  National Body position papers were reviewed.

Wednesday:	There was a joint meeting with Test and Video sub-groups to exchange views on the priorities of the various video performance verification tests.  Consensus was reached on most of the CD related discussion items.  Editing of Chapter 8 and Annex E was carried out.  Updated Video draft was reviewed jointly with Video.

Thursday:	Comparison between the requirements and Video and Audio achievements was reviewed.  Responses to National Body papers were agreed.  Framework for verification test was discussed.

Friday:	Consensus was reached on the verification test framework consulting with Video.  Comparison between the requirements and Systems achievements was reviewed.  Extension procedures for Profile and Level were discussed.

B2. Input Documents Considered

WG11 N0535	Convenor	Report of the 24th meeting in Brussels	
MPEG93/855	Hitachi	Constraints on bits/macroblock and bits/slice to facilitate implementation and enhance interoperability	
MPEG93/848	Italian NB	Contribution to the 25th WG11 meeting	
MPEG93/856	US NB	Contribution on Profiles and Levels	
MPEG93/860	US NB	Contribution on MPEG-2 interoperability	
MPEG93/886	Schaefer	Statement of HDTVT to MPEG	
MPEG93/897	DIN	Position of the German National Body on the resolutions of the 23rd and 24th WG11 meetings	
MPEG93/906	Sezan	Report of Ad-hoc group on applications and testing of 10 bits and 4:2:2 extension	
MPEG93/907	Okubo	Report of Ad-hoc Group on Editing Profiles and Levels part of Video WD	
MPEG93/969	NNI	NNI resolutions for ISO/IEC JTC1/SC29/WG11	
MPEG93/970	DISC	UK NB recommendation to the 25th meeting of SC29/WG11	

B3. Discussion on Profile/Level

B3.1	Profile/Level structure [848-Italy, 856-US, 897-Germany, 969-Netherlands, 970-UK]

	1) Not more than 11 conformance points in the CD?
	2) 4P x 4L, 5P x 4L, 4P x 4L x 3C?

The views expressed are summarized as follows;

Item	D	GB	I	J*	NL	USA	
No more than 11 conformance points	11	11	11	11	11	>11	
4P x 4L	no	yes	yes	no	yes	no	
5P x 4L	yes	no	no	yes		yes	
4P x 4L x 3C	no	no	no	yes		yes	
Addition of conformance points in the future	yes	yes	yes	yes		yes	
Not necessarily onion ringed Profile/Level	yes	(yes)**	(yes)**	yes		yes	
* Not documented, but expressed verbally by the delegation.
** implicit in the document

We agreed to keep the current 11 conformance points for the CD, but to split the current Main Plus Profile into two to make the specifications strict to the definition of profile, which is based on coding tools to be used.

High Level
		√			√	
High-1440 Level		√		√	√	
Main Level
	√	√	√		√	
Low Level
		√	√			
	Simple Profile	Main Profile	SNR Scalable Profile	Spatially Scalable Profile	High Profile	

We considered the USA proposal to apply the 3D structure for our purpose and renewed the recognition that the Profile/Level is of multidimensional nature.  We reached the above compromise solution maintaining the 2D model due to the facts that;

•	more dimensions than three would be needed to accurately model the subsets; e.g. 8/10 bit accuracy, B-frames, DP,
•	total number of possible conformance points would be increased to 48 including some impractical Profile/Level/Chroma format combinations,
•	whatever structure we may adopt, the compatibility between decoders and bitstreams should be tabulated as in Table D-30 for precise specifications to cope with either hierarchical or non-hierarchical subsets. 

	3) Naming?

Profile naming is modified as follows;

•	Simple and Main Profile are kept intact.
•	Main+ is split into SNR Scalable Profile (SNRP), Spatially Scalable Profile (SSP).
•	Next Profile is renamed as High Profile (HP) in line with other functionality oriented naming for Profile.

B3.2	Compatibility for bitstreams of a conformance point to be added in the future
	[§5.3 2)/907 - AHG]

	1) How to encode profile_level_id?
	2) Required resource indications in the bitstream?

Our guideline for the definition of Profile and Level is to make it hierarchical as far as practical and the current conformance points are in line with this.  However, we can foresee a possibility that we may define a new subset of the standard which is inside an existing subset.  In this case the existing decoder may not accept the newly defined subset bitstream due to the new value of profile_and_level_indication.

One agreed solution to ease the problem is;

•	to assign the value in order of hierarchy so that the existing decoders can identify decodability of future bitstreams,
•	to use the escape bit = 1 for encoding non-hierarchical Profiles and Levels.

For example, suppose Intra only profile was introduced in the future.  If its Profile id value is set to 110 or higher, then Simple (101), Main (100), SNR Scalable (011), Spatially Scalable (010) and Next (001) can be programmed to identify the decodability even at this moment.  This is workable as far as hierarchy is maintained.

In order to cope with more general cases which arise in the future, we agreed to prepare for introduction of optional indications in the video bitstream to make the bitstream self describing.  We propose to define a sequence extension code specifically reserved for this indication purpose.  Its content should be defined at the time when new conformance points are added.  The CD should include this place holder together with specification that the decoders conforming to the current version of the standard should be able to ignore this reserved extension until its syntax contents are defined.

B3.3	Products (decoder or bitstream) which lies between defined conformance points in the 
	Profile/Level space [860-US]

	1) What conformance point it can claim?
	2) More conformance points we should define?

We recognize the purpose of defining conformance points in form of Profile/Level is to facilitate bitstream interchange among different applications.  Though the standardization body encourages to produce decoders and bitstreams corresponding to those defined conformance points, actual products may be mapped into an intermediate point in the Profile/Level space as illustrated in the figure below.

To help to make this situation clearer, we propose to modify the first sentence of Chapter 8/WD as follows;

from

Profiles and levels provide a means of defining subsets of the ISO/IEC xxxxx syntax and semantics and thereby the required decoder capabilities.

to

Profiles and levels provide a means of defining subsets of the ISO/IEC xxxxx syntax and semantics and thereby the decoder capabilities required to decode a particular bitstream."

This matter of product compliance with the standard should be fully addressed in Part 4.

B4. Elaboration of the Video draft

B4.1	Temporal scalability in Spatially Scalable + and High Profiles? 
	[D.7/WD, 897-Germany]

Since applications which would use this tool is not clearly visible at the moment, we agreed to handle it as a tool which may be included in a future profile.

B4.2	Flexibility in sampling density; number of macroblocks bounded? [907-AHG]

At the joint consideration of IMPLEMENTATION, VIDEO and REQUIREMENTS, this matter was left to the discretion of REQUIREMENTS.  Since we do not identify strong needs for this extended flexibility in the decoder, we agreed to keep the current specification.

B4.3	H.261 compatibility in Next [897-Germany]

According to the following decision in Brussels;

"The video syntax contains tools that are needed to implement H.261 compatibility that ITU may need for possible future use, however, this is currently not supported by any profile (§10.1/N0535)"

we agreed to move relevant description from normative Chapter 8 to informative Annex D.

B4.4	frame_rate_extension semantics

This syntactic element was defined at this meeting.  We discussed how this is to be specified in Profile and Level.  Considering 

•	that its use in MP@ML is not appropriate since the specifications frozen in Sydney are affected, 
•	that its use is accompanied by implementation cost,

we agreed not to use this element in any of five Profiles at the joint consideration of REQUIREMENTS and VIDEO.

B4.5	Naming for scalable layers

Consultation with VIDEO, we use the following naming for consistency;

	first layer with layer_id = 0	base layer
	second layer with layer_id = 1	enhancement layer 1
	second layer with layer_id = 2	enhancement layer 2

B4.6	Representation of VBV buffer size specification [§3.9/Brussels Report]

In consultation with IMPLEMENTATION, the value is represented in unit of 1024 bits rounded up to a nearest integer.

B4.7	Another restriction to number of bits/macroblock, slice? [855-Hitachi]

No restriction was adopted in the normative part of Video CD, but the informative part states that a normative limit will be included in the Conformance Part of the standard.  This decision, however, did not affect the Profile and Level specification. 

B4.8	Representation of the bound for ratio of bitrate to picture rate [§3.9/Brussels Report]

In consultation with IMPLEMENTATION, unit of 1k (1000) bits is used; e.g. for MP@ML 
15 000 000 / 23.976 = 625625.625... is rounded to 626k.

B4.9	Table numbers in D.7 be adjusted in the order of reference

This editorial improvement was acted.

B4.10	Handling of D-pictures [907-AHG]

Based on the agreement in Brussels and confirmation at the joint IMPLEMENTATION, REQUIREMENTS and VIDEO meeting on Tuesday, we included relevant specification in Chapter 8.

B4.11	Vector range for dual-prime [907-AHG]

This was sorted out in VIDEO, but did not affect the specification of Profile and Level.

B4.12	Vertical vector range for high resolution pictures [907-AHG]

At the joint consideration of IMPLEMENTATION, VIDEO and REQUIREMENTS, we agreed to apply the current [-128:+127.5] specification to all Profiles and Levels.

B4.13	Quantizer matrix loading is Level independent ? [907-AHG]

We confirmed that the quantizer matrix loading is Profile dependent but Level independent, and reflected this in Annex E.

B4.14	Simplification of the tables in D.7? [907-AHG]

For completeness and due to informational nature of Chapter D.7, we decided to keep the current full description.

B4.15	Completion of Chap 8 and Annex E

Mr. J. Williams and Mr. C. Birch volunteered to edit Chapters 8 and Annex E by incorporating the above agreements.  The outcome was reviewed by REQUIREMENTS and VIDEO on Wednesday.

B5. Work plan for verification test requirements [§3.12/Brussels Report]

	1) What should be tested for Profile/Level other than MP@ML?
	2) Volunteers for Stages 3, 4

We made a framework as documented in WG11 N0605.  Comments on the test items and indication of commitments are requested.

B6. Comparison between CD 13818 and the requirements

After review of Systems, Video and Audio in each sub-group together with REQUIREMENTS, an integrated document has been produced as WG11 N0606.  Respective parts were kindly drafted by Mr. C. Holborow, Mr. T. Sikora and Mr. I. Rabowsky.

B7. Procedures to add conformance points through the amendment 
        [856-US, 897-Germany]

It has been agreed that amendments should be used to introduce new Profiles and Levels of MPEG-2.  We made a preliminary analysis for possible methods, and listed the following guidelines;

•	Amendments should be timely but not too frequent - 1 to 2 yeas?
•	New Profiles and Levels should follow the "onion ring" structure already established wherever practical.  It is recognised that this may not always be the case.
•	Wherever practical, new profiles and levels should be chosen to serve a cluster of applications and so encourage the interworking between applications.

This matter will be further studied through correspondence in an adhoc group chaired by S. Okubo.

B8. Profiles for Systems [897-Germany, 969-NL]

	1) All decoders should be able to decode both PS and TS?
	2) Other subsets?
	3) Work method toward DIS

Since this study need involvement of Systems experts, it will be further studied through correspondence in an adhoc group chaired by K. McCann.

B9. Responses to National Body papers

We reviewed a drat response produced by Mr. J. Williams on those items of our responsibility (see §3, §4, §7, §8 above) and forwarded this to the plenary.

C. VIDEO sub-group (by Kiyoshi SAKAI)

C1. Introduction

The video sub-group met for five days and discussed issues for finalizing the video WD.  The discussion centered upon the report from the ad-hoc group on video bitstream verification.  The meeting clarified the ambiguities remained from the 4th Video WD and fixed any other inadequacies. 

C2. Verification of the tools

According to the agreement made in the Brussels meeting, the tools unsucessfully verified by bitstream exchange are not included in the CD, the video group examined the work done by the ad-hoc group.  The group approved all the tools which are included in the currently defined profiles, however, some tools seemed to be not yet fully tested.  The video group decided to continue the work on bitstream exchange based on the final WD, especially focusing on the scalable syntaxes.  Related to this issue, there was an opinion that the precise verification of scalable schemes was only possible in the form of system bitstream.

C3. Picture skipping ("big picture" issue)

There were extensive discussions on this issue together with scalable schemes.  Main discussion in the video group was how to realize a loosely-coupled scalable system (spatial scalability) with skipped pictures in the base layer.  However, there was an input from the systems group not in favor of supporting skipped pictures even in the main profile.  The video group thoroughly reviewed the encoder/decoder operation in the presence of skipped pictures including non-scalable scheme.

1) Non-scalable scheme

The video group clarified the operation of vbv_buffer together with STD_buffer in the system layer to support picture skipping and this case was agreed to be supported in both video and systems group.
 
2) Scalable scheme

The following three alternative solutions were discussed to cope with the "big picture":

i)	Allow picture skipping by ensuring end-to-end timing relation between pictures in respective layers. 
ii)	Allow picture skipping, but cut the link between layers when picture skipping occurred in the lower layer. 
iii)	Not allow picture skipping, but emulate picture skipping by using dummy pictures which consist of skipped MBs.

The proposed method from ITU-T/EG(solution 1, MPEG93/966) was recognized as a possible solution.  However, there was a strong opinion that the solution is not fully investigated nor proved and may not always work well, for example, when re-multiplexing is done in-between encoder and decoder.  As a result of extensive discussions, the group decided not to allow picture skipping in any scalable schemes in the WD.

C4. VBR operation

The proposal from ITU-T/EG(MPEG93/965) which pointed out the inadequacy of vbv_delay  definition for VBR operation was accepted and the definition was kept as it had been before the Brussels meeting (shall be set as "FFFF" in case of VBR).  However, as for bit_rate definition, the video chairman required to utilize the field to have some regulation for VBR-coded bitstreams.  The revised definition after the discussion is as follows:

If the bit-stream is a variable bit-rate stream, the STD specifications in ISO/IEC 13818-1 supersede the VBV, and the bit-rate specified here is used to dimension the transport stream STD (2.4.2 in ISO/IEC 13818-1).

The bit-stream is a variable rate bit-stream if and only if the vbv_delay field has the value 0xFFFF.

Given the value encoded in the bit-rate field, the bit-stream shall be generated so that the video encoding and the worst case multiplex jitter do not cause STD buffer overflow or underflow.

According to the above definition, an encoder which wishes to generate a VBR bitstream conforming to MP@ML may set :

vbv_delay:	FFFF
bit_rate:	15[Mbps]
STD_buffer_size:	vbv_buffer_size+4[ms]*15[Mbps]

where the value for vbv_buffer_size is encoder's choice. 

C5. Chroma format

The discussion point was which of the two commonalities 4:2:2/4:2:0 or MPEG-1/MPEG-2 should be taken.  As a result of the discussion, the group chose the former concept.  This means that a decoder has to switch the chroma processing method between MPEG-1 mode and MPEG-2 mode to precisely reproduce the chroma posision.

D. IMPLEMENTATION STUDY sub-group (by Geoff MORRISON)

There was no dedicated meeting of this sub-group in Seoul.  The sub-group, however, assisted in determining the following items in the joint meeting with Requirements and Video (see Requirements sub-group report); 

•	representation of VBV buffer size specification,
•	representation of the bound for ratio of bitrate to picture rate,
•	vertical vector range for high resolution pictures.

E. SYSTEMS sub-group (by Stuart DUNSTAN)

E1.	Introduction
The MPEG-2 Systems Working Draft ISO/IEC JTC1/SC29/WGll N0601 was submitted to the closing MPEG plenary in Seoul for consideration as a Committee Draft.  The document dated 04 Nov 1993 was accompanied by a delta document "N0601 Corrigendum 1".

E2.	SG15 EG issues
A presentation of the SG15 EG discussions in Daejeon was made on Friday morning, after more immediate issues affecting the Working Draft (WD) were resolved.  

E2.1.	Use of PES
MPEG 93/968 [1] raised ambiguities in the Brussels WD with respect to the use of the PES stream as an interface point.  The revised WD text largely corrects this.  Specifically:

•	section 0.4 has been revised.  The final paragraph states "The PES stream is a logical construct that may be useful within implementations of this standard; however it is not defined as a stream for interchange and interoperability".
•	in section 0.10 reference to the PES stream has been removed.
•	section 2.4.5 an STD is defined for a PES stream.  It is the same as the STD for the Program Stream.

There was a general feeling in the meeting that no conformance point would be defined for the PES stream.  However it was felt that this did not prohibit a user from using a PES stream if desired.

It was pointed out that the Program Stream may be used in a similar manner to the way in which it was anticipated the PES stream might be used.

There were a number of computer manufacturer representatives in the meeting who also expressed interest in using the PES stream.  Concern was also expressed that the driving force behind MPEG-2 Systems has been the broadcast application; the suitability of MPEG-2 for computer environments was questioned, since the quality demands may be less e.g STD clock accuracy.

These issues are to be addressed in an ad-hoc group titled "Ad-hoc group on Network Applications" (see below).

E2.2.	Timing
It was generally agreed that ATM cell jitter removal is an AAL function; the AAL should have mechanisms to bound the jitter on user data.  It was suggested that SCR (or PCR) fields could be carried in AAL fields.  Meeting participants were encouraged to quantify timing issues, and solutions to deal with jitter removal, in their particular application.

E3.	Program Specific Information
Major work was done to the tables that make up the Program Specific Information (PSI) in the Transport Stream (TS).  A common syntax was applied to the leading fields of these tables so that common decoding mechanisms could be applied.  An informative annex describes the PSI structure.

An attempt was made to apply this common syntax to the equivalent table in the Program Stream (PS), the Program Stream Map.  However since the PS does not allow start code emulation, the common syntax could not be applied.  Start code emulation is allowed in the TS.  

E4.	Digital Storage Media Control Command (DSM CC)
References to DSM CC can be found in Part 1 of the CD as follows:

•	Annex A is a normative annex describing DSM CC
•	in the PES header there are optional fields which describe the mode of operation of the DSM e.g fast forward, slow motion etc
•	in Table 2-10 a stream_id value has been allocated to identify PES packets carrying DSM CC.

E5.	Locking of audio and video sample clocks in TS
In the TS the audio sampling rate and the video picture rate have defined and fixed relationships to the system clock frequency, for one particular program.  The justification for this is as follows:

•	decoder design is simplified.  Where the audio sampling clock and the video picture rate are not locked then individual elementary stream clock synchronisation, using PTSs, is required.  Where locking is used synchronisation for the whole program can be done on the basis of PCRs.
•	all known MPEG1 bit streams have a fixed relationship between audio sampling rate and video picture rates.

In section 2.4.10 "Constrained System Parameter Stream" an allowed set of ratios are defined.

E6.	Skipped Pictures
There was some opposition to allowing skipped pictures, since this is the one and only condition which violates the TS and PS STD timing models.  However picture skipping was agreed to and reference is made to it in the sections describing the STD for each stream.

E7.	Transport Stream System Target Decoder
The TS STD was considerably revised.  The time at which a transport packet is removed from the transport buffer is defined in terms of a latency.  

An informative annex on the MPEG-2 systems timing model is included in the CD.

E8.	Response to Requirements Group
It was the feeling of the meeting that the initial list of requirements set by the Requirements Group had been more than adequately met.  A response document was written.

E9.	General
The WD underwent considerable re organisation and editing.  A quick look at the document reveals that further editing will be necessary.

E10.	Ad hoc groups
The following ad hoc groups were formed to continue work towards the Paris meeting:

•	Ad-hoc group on Bit Stream verification - chairman: Tony Wasilewski
•	Ad-hoc group on Conformance Testing - chairman: Jan van der Meer
•	Ad-hoc group on Network Applications - chairman: Stuart Dunstan

References
[1]	ISO/IEC MPEG 93/968,  "Use of Packetised Elementary Streams as an interface point", TD 11 (Daejeon), ITU-T SG15 Experts Group for Video Coding and Systems in ATM and Other Network Environments.

END