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

Source:	CHAIRMAN OF THE EXPERTS GROUP FOR ATM VIDEO CODING	
Title:	REPORT OF THE TWELFTH MEETING IN BOSTON AND NEW YORK (July 7-16, 1993) - Part III	
Purpose:	Report	

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

Part I	General (see AVC-553R)
Part II	Sole sessions in Boston (see AVC-553R)
Part III	Joint sessions in New York

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

1. Introduction

The joint sessions with MPEG were held at Columbia University in New York during 12-16 July 1993 at the kind invitation of Columbia University.  At the opening session on 12 July, Dr. Dimitris Anastassiou 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.

2. REQUIREMENTS sub-group (S. Okubo)

2.1 Introduction

The REQUIREMENTS sub-group met every day during the week (July 12-16) under chairmanship of Sakae Okubo to freeze all the profiles at this meeting.  We first reviewed all the documents on Monday and Tuesday to identify issues and spent the remaining days for discussing them.

In addition to our own sessions, we had joint sessions with other sub-groups as follows;

•	with VIDEO and IMPLEMENTATION, 9:00 - 10:00 on Tuesday to identify open issues regarding the Next Profile and to seek advice of the two groups regarding specific items,
•	with VIDEO and IMPLEMENTATION, 16;00 - 17:00 on Thursday to exchange views on the open issues.

In the following, relevant documents are first listed, then discussion and/or its conclusion are described.

2.2 Background

N0384	Convenor	Annex XV MPEG/Requirements meeting report (Sydney)	
93/535	Haskell	Report of adhoc group on profiles and levels	
93/540	Teichner	Report of adhoc group on requirements for verification test	

The meeting started this week discussion with a short review of what happened in the previous Sydney meeting and identified items to be worked out at this meeting.

2.3 Next Profile and Profile Architecture

93/454	Teichner	Profile for hierarchical HDTV	
93/467	Stevens	Information Technology (IT) profile	
93/497	USNB	Contribution to ISO/IEC JTC1/SC29	
93/514	Koster	Telecommunication requirements for the Next profile	
93/515	Koster	Telecommunication levels for the Next profile	
93/516	Sikora	Flexible Object Oriented Decoding Using Slice Identification	
93/548	ITU-TS/Japan	Considerations on the next profile	
93/549	ITU-TS/Japan	Practical examples of hierarchical coding	
93/574	Australian NB	Australian National Body position on development of NEXT profile-1	
93/575	Australian NB	Australian National Body position on development of NEXT profile-2	
93/597	NHK	Amendment to pel aspect ratio	
93/598	NHK, SONY	Syntax modification on subsampling ratio	
93/600	BTA	Comments on MPEG93/473, Profile architecture	
93/602	JNC Profile SG	Consideration on hierarchical profile architecture	
93/603	JNC	Comments for WG11 New York meeting	
93/642	AFNOR	Resolutions of the French National Body	
93/654	Erdem	10-bit/8-bit amplitude scalable coding	
93/659	NNI	Resolutions of the Dutch National Body	
93/687	McCann	WGDTVB contribution to "Next Profile" definition	
93/690	Fautier	Proposal of SIMPLE PROFILE parameters	
93/693	Challapall	Constraints on MPEG2 Syntax for the U.S. HDTV Standard	
93/707	Wilson	Discussion with SMPTE on professional applications	
93/720	NHK	Consideration on copyright management for video data	
93/726	McLaren	HDTV simulation results	

The discussion was focused on freezing all profiles and levels so that the structure of the generic standard be finalized at this meeting.  Most of the time was spent on specifying the Next Profile and defining higher levels than the Main Level.  This work was carried out with collaboration of Video, Implementation and Systems sub-groups; see Annex 2 to this report for the questions we asked each sub-group.  

The outcome is contained in WG11 N0489 which is attached to this report as Annex 3.  It should be noted that N0489 also indicates some open issues toward the Brussels meeting.

1) Definition of Level Parameters, particularly those of High

We decided to follow the practice for the Main Level; upper bounds are specified for pels per line, lines per frame, frames per second and the product for the three.  The decoder is also required to support pels per line and lines per frame in multiples of 16 (Note).

Note - In the joint sessions, it was pointed out that the number of lines per frame should be a multiple of 32 to support the field structure.  This aspect is yet to be sorted out.

The following existing or planned HDTV formats were considered;

Format	Number of Y pels per frame	Number of Y pels per second	
1440x1040x30
(active lines: 1035)	1.50 million	44.9 million	
1920x1040x30
(active lines: 1035)	2.00	59.9	
1440x1152x25	1.66	41.5	
1920x1152x25	2.21	55.3	
1920x1088x30
(active lines: 1080)	2.09	62.7	
1440x1088x30
(active lines: 1080)	1.57	47.0	
2048x1152x25	2.36	59.0	
1280x720x60	0.922	55.3	

There was extensive discussion as to whether the number of HDTV related levels can be one (1920 pels per line) or it should be two (1920 and 1440 pels per line).  We adopted the two level solution since there were expressed sufficient application interests in both levels and since the advice of Implementation sub-group indicated possible significant difference of hardware impacts between the two levels.

In the course of this discussion, Mr. Gaggioni informed the meeting about the digital VTR for HDTV that minor changes to the existing 1125-line equipment (1035 active lines) easily allow accommodation of the 1920x1080 pels per frame picture format being considered in the US.

There was a request to include 960x496x30 as a new Level or as the Main Level of the Next Profile.  Though the Implementation sub-group's advice indicated that there may not be a threshold between 960x496x30 and 720x480x30, it was objected to define a new Level on the grounds that 960x496x30 is less likely to appear as the top layer of the hierarchical coding and that this causes an outstanding irregularity in the Profile/Level structure.  In conclusion, we agreed to extend the upper bound of pel rate to 11.6 million per sec for the Main Level of the Next Profile. to cover 483 active lines of the 525/60 television system and to minimize the irregularity of the Profile architecture.

2) Specifications for the Next Profile

Starting from the skeleton produced in Sydney, we refined the specifications according to the comments provided in MPEG93/600, 687 and expressed during the discussion.  The highlight functionality is scalability supporting;

•	up to 2 resolution scales
•	up to 4 scales in total as combination of resolution scales and SNR scales
•	up to 2 SNR scales at the upper resolution scale

at High and High-1440 Levels.

There was a request for flexible format relationship between the base layer and upper layer resolutions (MPEG93/598), which was agreed and conveyed to the Video sub-group for their action.

3) Necessity of Simple Profile and its specifications

There was some discussion as to whether we should define the Simple Profile at all.  The objective is to simplify the standard structure and allow interworking between different applications to the maximum extent.

Practical significance of less costly implementation in the near future, however, was also recognized.  The meeting concluded to define the Simple Profile, but with the following specifications;

•	Its functionalities should be those of the Main minus B-picture to ease migration to the Main in the future when implementation cost of B-picture become less significant.
•	The Simple Profile decoder should be able to decode the Main Profile bitstreams at lower levels as proposed by MPEG93/603.

4) Compatibility between different Profiles and Levels

Taking into account the above mentioned relationship between the Simple and the Main, the bitstreams each decoder must be able to decode was summarized as in the table/§4 of N0498.

5) Coding tools not included in defined Profiles

There are some coding tools (4:4:4, 10/8 bit scalability, data partitioning, etc.) which are defined in the syntax but not included in any Profile.  These tools may be included in one or other Profiles which can be added in the future according to the existing procedures (e.g. in form of Amendment) if found necessary.  Another possibility is that their use may be defined in application standards.  The November 1993 CD includes only Simple, Main and Next Profiles.

The procedures of adding new profiles have been clarified with the help of Convenor.

6) Pel aspect ratio

It was agreed to include three values; 0.7500, 0.7826, 1.0435.

7) Indication of objects

The meeting supported the idea proposed in MPEG93/516, leaving the syntax representation to the Video's description.

8) Copyright management indication

There was a proposal to include the indication in the video elementary stream (MPEG93/720).  Since it impacts the frozen syntax and the video should always be accompanied by the Systems layer for correct operation, we concluded that the indication should be supported by the Systems.

9) Progressive/interlace scalability

This requirement was reconfirmed in the joint sessions with Video and Implementation (see one of the open issues identified in Sydney - Annex XV to N0384).

10) Possibility of integrating spatial scalability and frequency scalability

Mr. Holtzman provided a thought containing examples of using various combinations of spatial domain, frequency domain and SNR scalability.  The meeting requested him to raise his thought in the Video and Implementation sub-groups for their consideration.  Eventually the frozen syntax allowed simultaneous use of spatial scalability and SNR scalability, while excluding frequency domain scalability entirely.

11) Table relating syntactic elements and Profiles

This is to be worked out through correspondence toward the next meeting in Brussels.

2.4 Requirements for Audio

497	USNB	Contribution to ISO/IEC JTC1/SC29	

It was raised whether non-backward compatibility with MPEG-1 be considered as part of the MPEG-2 requirements.  The meeting concluded that the normative requirements for the MPEG-2 audio had just been finalized in Sydney stipulating the backward compatibility, thus how to handle the non-backward compatible mode in the course of future activities should be resolved in the Audio sub-group.

2.5 Verification

488	Nasse	Revision of MPEG-2 verification procedure proposed by MPEG adhoc "test"	
490	Hidaka	Method of MPEG-2 verification test	
525	Hidaka	Report of adhoc group on MPEG-2 verification test	
556	Hidaka	Method of subjective assessment for MPEG-2 verification test	
640	Teichner	Issues for verification test	

Unfortunately we could not deal with this topic due to time limitation.  We will continue this work through correspondence toward the next meeting in Brussels.

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

The video group met throughout the whole week.  There were joint meetings with requirements and implementation.  Besides there was parallel work going on concerning update of the video WD.

The areas of work in the video group were:

	- Performance of MP@ML.
	- MPEG2 extensions and elements for NEXT  profile.
	- Freezing if technical tools to fulfil the requirements.
	- Production of the 3rd WD.
	- Conformance testing.

3.1 MPEG2 extensions and tools for NEXT profile.

	AC leaky prediction:

There was a proposal from the Grand Alliance (US) to include AC leaky prediction as an alternative to achieve regular update and error resilience.  The proposal was rejected because it failed to show significant benefits over the existing tools.

	8x1 DCT and 16x8 motion compensation for proscan:

Those tools have been considered several times before and were brought up again.  Both were rejected because they failed to show significant benefits over the existing tools.

	Scalability:

The main activity is on spatial scalability.  Tests are still being performed on optimizing scaling filters.  Concerning the number of spatial levels, it was agreed that 2 was enough.  If more levels were needed this could be met by using SNR scalability in addition.  Data Partitioning is another way of obtaining one sort of scalability.  It was agreed that this tool works mainly for error resilience.  The pictures resulting from the different layers are not considered suitable for presentation separately.  There was a strong view in the group that DP was an unnecessary tool.  The only area where it was felt useful was with ATM transmission and different priorities.  It is therefore up to the ATM group to reconsider if DP is of significant benefit.

	FF/FR:

It was realized that this was largely a pure VCR concern and that general "bitstream producers" would not have to do any effort to facilitate FF/FR in a VCR.  The interaction between Video and Systems needs more work on this item.

3.2 Production of the 3rd WD.

Several documents concerning inconsistencies/errors in the WD were presented.  At the same time editorial work on the WD was going on during the whole week.

	Skipped pictures.

This item was of particular interest for low delay.  The ATM group had an input document on this issue.  This document was merged with another document on VBV operation and 3:2 pull down.  The result will appear in the WD.

3.3 Conformance testing.

There was a strong urge for activity on conformance testing for the coming meetings!

3.4 New experiments.

Since most of the elements are frozen, there is little need for more experiments.  However, there are still a few items left for optimization.  This is concerned with:

	- Spatial scaling filters.
	- Block type VLC optimization.

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

The IMPLEMENTATION STUDIES sub-group met on 13th, 15th and 16th of July during the WG11 meeting at Columbia University, New York.  Core participants were:

Geoff Morrison	BT Labs (chair)
Richard Bramley	SGS-Thomson
Peter Borgwardt	Tektronix
Sam Narasimhan	Singapore Institute of Microelectronics
Marco Gandini	CSELT
Fathy Yassa		Thomson Consumer Electronics Components
Barth Canfield	Thomson Consumer Electronics
Tom McCarthy	IBM

The topics discussed were:

4.1 AC Leak

Though we had previously expressed a dislike of AC Leaky prediction at the Sydney meeting we considered new inputs addressing the implementation aspects which had been the reasons for that stance.

Document MPEG93/581 proposed the use of 4 by 4 groups of pixels (instead of one 8 by 8 group) for computing the DC value to be subtracted from pels to obtain the AC values which would then be subjected to the leak.  We considered that though this initially appeared to reduce the size of on-chip RAM it did not eliminate it nor would the accompanying control circuitry be much reduced.  However, it was subsequently realised that as a 4 by 4 block is not a natural nor desirable structure for use after the leak, an extra conversion stage would be required, probably to raster scan or 8 by 8 block.  Therefore any simplification in the vicinity of the leak would be outweighed elsewhere.

Document MPEG93/581 also proposed an alternative of using a quasi average (of the pixels already available) as the DC value to be subtracted.  This would completely eliminate any requirement to temporarily store pels while an average is being computed on an entire block.  However, this proposal requires division by 2, 3, 4, 5, ....64 which we considered more complex than the 64 byte buffer we had disliked in Sydney.

Document MPEG93/587 proposed a rearrangement which eliminated the 64 byte buffer by effectively combining it with the FIFO buffer normally needed to interface writing to the frame memories of the predictor loop.  We were not convinced that this sharing could be accomplished without increasing the size of the FIFO.

At this point, where we had no reason to change the opinion we formed at the previous meeting in Sydney, we learned that AC leak had been withdrawn.

4.2 Data Partitioning for VCRs

An ad-hoc group had concluded that data partitioning would aid fast forward and fast reverse modes for video recorders.  We were asked to comment on the cost savings that would result if "dumb" recorders were only presented with coded bitstreams which were partitioned.  Incorporating extra circuitry to take non-partitioned coded data and partition it would make "smart" VCRs more expensive.

We assessed the extra requirement on a "smart" VCR as being a Variable Length Decoder and counters but no extra buffer, to produce high priority data.  On the replay side, no recombining is necessary if the VCR records non-partitioned and high priority versions.

The cost of the "dumb" VCR approach falls on the TV with integral MPEG-2 decoder.  This cannot be Main Profile at Main Level (because MP@ML does not include data partitioning) and the decoder has extra buffer management.

We concluded that on the grounds of equipment cost, both are relatively small and the difference between them would be very small and of uncertain sign.  We recommended that the decision be made on other considerations and posed the following questions:

	- Is the data partitioning split for FF/FR exactly the same as broadcasters would wish for error resilience?
	- Is it feasible to define a unique data partitioning split which will be the same across all storage devices and generations of them?
	- How desirable is operation with MP@ML?
	- Is it important to permit product differentiation through various qualities or speed-up factors of FF/FR, including none?

We recommended the "smart" VCR as the solution because:

	- No constraints on the bitstreams it can record so no conflicts between VCR manufacturers and broadcasters, ATM network providers etc.
	- New VCR formats can be developed over time with split ratios which are appropriate to each format.
	- Full operation with MP@ML.

4.3 Implementation considerations for definition of HIGH LEVEL

We were requested by the REQUIREMENTS sub-group to provide guidance in the definition of HIGH LEVEL.  In particular we were asked to comment on the impact of scanning formats and where they fell in relation to breakpoints of memory size etc.

Widespread use of a HIGH LEVEL will depend on low cost decoders and these need to have only a small number of memory devices.  As sufficiently large and fast devices are not available we had to make an assumption.  We based our analysis on hypothetical Synchronous DRAMs operating at 100 MHz.

We had been given a table of possible formats by the REQUIREMENTS sub-group and added the Main Profile @ Main Level for reference purposes.  We computed the required memory size required for two cases.  The first is without B frames and without Dual Prime.  The second is with B frames and Dual Prime.  These memory sizes are listed in Table 1.  The additional [1]s and [2]s in the boxes indicate which will fit in 32 Mbytes at 64 bits bus width and 64 Mbytes at 128 bits bus width respectively.  As some will fit in neither a third marker, [3], shows those which will fit in 64 Mbytes if B frames are not used but Dual Prime is retained.

Table 1

Format	Y pels per frame
(106)	Y pels per sec
(106)	Memory reqd without B frames, without Dual Prime
(106 bit)	Memory reqd with B frames, with Dual Prime
(106 bit)	
ML@MP		10.4	<8	16	
1440x1040x30
(1035 active lines)	1.50	44.9	28.1 [1]	61.9 [2]	
1920x1040x30
(1035 active lines)	2.00	59.9	34.9 [2]	79.9 [3]	
1440x1152x25	1.66	41.5	30.1 [1]	67.7 [2]	
1920x1152x25	2.21	55.3	37.5 [2]	87.6 [3]	
1920x1088x30
(1080 active lines)	2.09	62.7	36.0 [2]	83.2 [3]	
1440x1088x30
(1080 active lines)	1.57	47.0	29.0 [1]	64.4 [2]	
2048x1152x25	2.36	59.0	39.4 [2]	92.9 [3]	
1280x720x60	0.922	55.3	21.0 [1]	41.1 [2]	

[1] 32 Mbit, 64 bit wide
[2] 64 Mbit, 128 bit wide
[3] 64 Mbit, 128 bit wide, NO B FRAMES but with Dual Prime

Assumptions

	- 100 MHz Synchronous DRAM devices
	- all formats are 4:2:0
	- vertical motion vector magnitude <128
	- without B frames, needs 1 frame + 128 lines + coded data buffer
	- with B frames, needs 3 frames + coded data buffer
	- coded bit buffer is 8x106 bit for all except MP@ML

Concerning the maximum coded data rate for HIGH LEVEL, we were of the opinion that rates up to about 80 Mbit/s would not be unduly difficult.

4.4 HIGH LEVEL decoding with parallel architectures

There was general agreement that parallel processing of sub-pictures may be an attractive method of handling larger formats and that this would be greatly eased by having more slice headers than the current minimum.

4.5 Oddification for IDCT mismatch control

Some problems had come to light with the oddification method agreed at the Sydney meeting and solutions discussed in an ad hoc group.  We endorsed the sequence of first limiting coefficients to be within the range -2048 to 2047 and then toggling the LSB in twos complement notation of the 64th coefficient subject to the summation criterion agreed in Sydney.  We also endorsed the proposal in Document MPEG93/595 that in frequency scalable schemes, oddification only be performed in the 8 by 8 case.

4.6 Upsampling filters for Spatial Scalability

We were requested by the VIDEO sub-group to comment on polyphase filters required for upsampling in spatial scalability.  We suggested the use of bilinear interpolation filters with output positions quantised to the nearest of sixteenth of input sample spacing.

4.7 Interworking between elements in profile/level matrix

We recognised that the capability of actual implementations of MPEG-2 video will not map directly unto rectangular areas of the profile/level matrix.  It is likely for example that a decoder for a certain level of the next level would have enough processing power to handle a higher level in the main profile.  Consequently we recommended that MPEG should take this into account as had been requested by the Japan National Body and mandate such interworking between suitable entries in the profile/level matrix.

4.8 Gaps between slices in intra frames

We saw no reason why gaps between slices in intra frames should be prohibited.

4.9 Implementation impact of number of layers of spatial scalability

We were requested by the REQUIREMENTS sub-group to advise on the implementation impact of the number of layers of spatial scalability.

For the version of SNR scalability which is prone to drift in the lower layers, the memory size and speed is independent of number of layers.  Each layer requires input coded data buffer management, VLD/parser and inverse quantiser.  The hardware may be multiplexed but speed required increases linearly with number of layers.

The other version of SNR scalability (which is drift free), when used with frame based coding and interlaced display, needs an additional half frame memory to interlace the higher layer.  However, we understood that this version was no longer being considered by the VIDEO subgroup.

For spatial scalability the memory size, memory speed, parser/VLD speed, inverse quantiser speed, IDCT speed increase with total number of pels in all layers.  Adding one lower layer downsampled by 2:1 vertically and horizontally causes 25% increase.  Adding another takes 6.25% more (31.25% total above one layer).  A third layer needs another 1.5625%.  The limit for any number of such 2:1 downsampled layers is 33.333%.

Resolutions

We prepared resolutions on the above topics.  They are contained in §3.5 of Document ISO/IEC JTC1/SC29/WG11 N0460.

5. SYSTEMS sub-group (S. Dunstan)

5.1 Introduction

An MPEG Systems Ad Hoc Group to Recommend Revisions to the Systems Working Draft meeting was held at Columbia University on the weekend immediately prior to the 23rd meeting of MPEG.  At the Sunday meeting the liaison document from the SG15 Experts Group was presented [1].

The Systems Working Draft was frozen at the end of the New York meeting.  However some technical issues remain to be resolved and further editing of the Working Draft is required.  An Ad Hoc Group to Verify the Working Draft was established.

5.2 H.32X terminal

With respect to the H.32X terminal the interests of the Experts Group, as contained in [1], can be summarised as,

•	the Packetised Elementary Stream (PES) is seen as a likely candidate for H.22X.  (The Program Stream may also be suitable).
•	H.22X should not substantially increase end to end delay.
•	H.22X should not prohibit alignment between structure in elementary streams and H.22X structure i.e. a PES packet.
•	a H.32X terminal requires only one time base.

With respect to the PES stream, the Elementary Stream Clock Reference remains in the PES header.  The PES stream is thus capable of supporting MPEG-2 timing, without use of the Program Stream or the Transport Stream.

The low end to end to delay requirement had impact upon

•	the PES_packet_length field.
	this field is contained in the PES packet header.  Concern was expressed about the delay that this field introduces when the packet length is known only after coding is complete.  The result was that where the PES packet length field is zero, the packet length is undefined.  However it may be undefined only where the following conditions exist
	-	the PES packet carries MPEG video
	-	the PES packet is part of a Transport Stream
	This later condition may be unsatisfactory to the Experts Group, given the low delay requirement and the desire to use the PES layer for H.22X.  This should be addressed.
•	the PES previous_PES_packet_CRC  field
	this field is contained in the PES packet header, and its purpose is that of error monitoring.  The field is not intended to be used as a mechanism to accept or reject PES packets at the decoder.  The CRC result of the current PES packet is placed in the header of the next PES packet.  This avoids delay that would occur if the result was contained in the header of the current packet.

Alignment between elementary stream structure and the PES packet was not only prohibited, but actively supported as follows

•	a one bit field data_alignment_indicator in the PES packet header indicates if an elementary stream structure begins at the start of the PES payload.  Compliant decoders however must not require this bit to be set.
•	in the Program Specific Information (PSI) table a data_stream_alignment_descriptor indicates the type of structure in the elementary stream to which the PES packet is aligned e.g. slice start code.

It was noted in the meeting that both the PES packet_start_code_prefix (24 bits) and the PES_packet_length (16 bits) fields may be redundant in some applications, since the preservation of the PES packet may be carried out by a lower layer function e.g. Transport Stream, AAL etc.  It was agreed that the packet_start_code_prefix  field should remain for the sake of compatibility with the Program Stream, for which it is required.

5.3 Transport Stream and ATM/AAL

The transport packet length has been fixed at 188 bytes.  The following reasons were put forward to justify this length

•	scrambling
	the length suits scrambling algorithms
•	ATM mapping
	this length allows mapping of one Transport Packet to four ATM cells, with one byte per cell reserved for AAL functions.  MPEG says nothing about what these functions are or should be.
	The packet length decision is based on the assumption that there should be alignment between the start of a Transport Packet and the ATM cell payload.  The use of AAL type 1 however does not preclude other packet lengths; packet structure is maintained through use of the pointer field, and protection against cell loss is provided by Reed Solomon coding and byte interleaving.
•	buffering, packet loss
	a packet length of 188 bytes is preferable to a longer packet length for reasons of buffering requirements, and to minimise the effects of errors in the case of packet loss.

5.4 Other MPEG System issues

Other issues dealt with by MPEG Systems included the following,

•	definition of a System Target Decoder for the Transport Stream
•	compatibility
	the PES header has an optional field that carries an MPEG-1 systems pack header or an MPEG-2 Program Stream pack header.  This mechanism allows an MPEG-2 Program Stream to decode an MPEG-1 System, and supports conversion between MPEG-2 Program and MPEG-2 Transport Streams.
•	Program Specific Information (PSI)
	for the Transport Stream, syntax is defined that associates the elementary streams into complete programs.  Transport Stream packets with the PID field set to zero carry the Program Association Table.  This table is a list of PIDs, each of which carry a Program Map Table.  The Program Map Table lists the PIDs of the elementary streams for that program, and may contain a set of descriptors for the program, as well as a set of descriptors for each elementary stream within the program.
	There is an intention to use the PSI syntax also in the Program Stream.
•	timestamp discontinuity
	a flag is contained in the adaptation field of the Transport Stream packet to indicate that the PCR value contained in this packet may be discontinous in relation to previous values.
•	Transport Stream redundancy
	the continuity_counter field in the Transport Stream packet header has the semantics that if the value in a particular PID is the same as the previous value in the same PID, then this packet is a duplicate of the previous packet.
•	splicing point
	a splice_countdown  field is available in the Transport Stream adaptation field that indicates the number of packets before a suitable splice point occurs.  The current semantics of this field may need to be qualified with "... non-redundant number of packets ..." (see Transport Stream redundancy above).
•	DSM trick mode support
	a one byte field is available in the PES header for DSM trick mode control.  The semantics of this field are to be defined in Brussels.
•	scrambling constraints
	in the Transport Stream the Transport Stream packet header, including the adaptation field,must not be scrambled.  In the Program Stream the pack header and the PES packet header must not be scrambled.
•	copy control
	the PES header contains a one bit copyright flag and an original_or_copy flag for copy control.  An additional_copy_info_flag is also available that opens up a one byte field.

5.5 MPEG-2 timing model

TD7 from the Boston meeting of the Experts Group was concerned with the MPEG-2 timing model and clock recovery, where the Transport Stream was transported by AAL type 1.  TD7 was presented to the Systems meeting for clarification.  Figure 1, and the following text, attempt to reflect the MPEG-2 timing model as described in the Systems working draft, and as discussed in the Systems meeting.

Figure 1.  Illustration of MPEG-2 timing model using Transport Stream and AAL type 1 (TD7).
•	system clock
	a program is defined as a collection of elementary streams with a common system clock, or time base.  The system clock frequency is nominally 27 MHz.  Time stamps and clock references are snapshots of this system clock.
•	time stamps
	Presentation Time Stamps (PTS) are snapshots of the system clock but with a resolution of 90 kHz.  They refer to the time that an access unit (video or audio frame) is to be presented by the system target decoder.  Decoding Time Stamps (DTS) are similar but refer to the time that an access unit is to be decoded.  DTSs are only required in elementary streams in which the access unit decoding order differs from the presentation order e.g. I, P frames.
•	clock references
	clock references are snapshots of the system clock, and have a base resolution of 90 kHz with an extension to 27 MHz resolution.  They refer to the time that the last byte of the clock reference field enters the system target decoder.  Table 2 identifies the name and location of clock references for each of the MPEG-2 streams.

stream	clock reference	location	
Elementary Stream	ESCR	PES header	
Transport Stream	PCR	TS adaptation field	
Program Stream	SCR	pack header	
Table 2.  MPEG-2 streams and clock references.
	The ESCR field is not required where the PES packet exists as part of the Program Stream or Transport Stream.
•	lock flags
	the audio and video sampling clocks may be locked to the system clock.  In this case the appropriate indicator bits may be set in the system header and in the PSI area of the Program Stream and Transport Stream respectively.
•	rate flags
	in the Program Stream the program_mux_rate in the pack header indicates in bytes/sec the rate of the data in the pack in which it is carried.  This field is used in the calculation of arrival time of the next byte in the system target decoder.  In the Transport Stream the equivalent value transport_rate is not coded in a field, but derived from the number of bytes received between two successive PCR values.  An Elementary Stream rate field ES_rate is also available.  It is used to derive the time of arrival of the next byte at the system target decoder for PES streams. 
In response to TD7,
•	the Transport Stream carries multiple PCRs, one for each program carried.
•	the audio and video sampling clocks can be derived from the system clock, when the respective lock flags indicate this.  When lock does not occur, it is the decoder's responsibility to deal with this situation.
•	AAL type 1 takes part in jitter removal for the whole Transport Stream.  However the decoder might further remove jitter for each program, in order to accurately reconstruct each program's system clock.

Further discussion may be required to answer all the issues raised by TD7.

References
[1]	ISO MPEG 93/698,  "Report of discussion on ATM/AAL and MPEG-2 Systems", ITU-TS SG15 Experts Group on ATM Video Coding.

END

*    *    *

Annexes

Annex 1	List of Documents for the Joint Sessions in New York
Annex 2	Questions to the Video and Implementation sub-groups
Annex 3	Agreements on Profile/Level