ISO/IEC JTC1/SC29/WG11
MPEG94/331
October 1994

ITU-T Telecommunication Standardization Sector	Document AVC-688
Study Group 15	25 October 1994
Experts Group for Video Coding and Systems 
in ATM and Other Network Environments

Source:	RAPPORTEUR FOR Q.2/15 IN ITU-T SG15 (Sakae OKUBO)	
Title:	COMMENTS ON DRAFT ITU-T REC. H.222.0 | ISO/IEC 13818-1	
Purpose:	Proposal	

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

This document summarizes the comments on the Draft ITU-T Recommendation H.222.0 | ISO/IEC 13818-1 (DIS text dated 10 June 1994) which have been collected from the members of the Experts Group for Video Coding and Systems in ATM and Other Network Environments and the ITU-TSB translator for the French text.  It consists of the following two categories:

	- comments with some possible normative change or clarification (with T numbers)
	- comments requiring only editorial change (with E numbers)

This document, together with the Singapore meeting outcome, is also submitted to the Study Group 15 meeting in February 1995 as part of the approval process.

I	Comments with some possible normative change or clarification

#	Page	Section	Location	Comments	
T1	xii	0.1	3rd para.	'it is generally not possible' is not correct. This type of stream is no more difficult to make than any other.  The easiest fix is to remove the whole paragraph.

Otherwise provide a technical justification for the above statement.	
T2	xvii	0.8.1	2nd par	The only reference to the Transport Stream packet length of 188 bytes is in the introduction (5th par, page xi, and 2nd par, clause 0.8.1, page xvii).  Should not this information be included in clause 2.4.3 "Specification of the Transport Stream syntax and semantics"?

Include explanation of N, and the transport_packet() length, in semantics for data_byte, clause 2.4.3.3.	
T3	5
19	2.1.53
2.4.3.3		The DIS is ambiguous as to what fields are contained in a Transport Stream packet header.  An unambiguous definition of a Transport Stream packet header is required.  The ambiguous text should be cleaned up.

Assuming that the adaptation_field() is part of the Transport Stream packet header, then replace clause 2.1.53 with, 

2.1.53 Transport Stream packet header [system]:  The leading fields in a transport_packet(), up to and not including the data_byte fields.

In clause 2.4.3.3, page 19, transport_scrambling_control, change "... The Transport Stream packet header, including the adaptation field when present, shall not be scrambled. ..." to "...The Transport Stream packet header, which includes the adaptation field when present, shall not be scrambled. ..."

In clause 2.4.3.3, page 19, adaptation_field_control, change "... This 2 bit field indicates whether this Transport Stream packet header is followed by an adaptation field and/or payload." to "...This 2 bit field indicates whether this Transport Stream packet header includes an adaptation field, and whether this Transport Stream packet header is followed by a payload".	
T4	5	2.1.37	new entry	The term "PES packet header" is used frequently, but is undefined.  An unambiguous definition is required.  In clause 2.1. Definitions, insert the following:

2.1.37 PES packet header [system]:  The leading fields in a PES_packet() up to and not including the PES_packet_data_byte fields, where the stream is not a padding stream.  In the case of a padding stream the PES packet header is similarly defined as the leading fields in a PES_packet() up to and not including the padding_byte fields.	
T5	10	2.4.1	Second paragraph	Concerning definition of access unit, which must be clarified as it has two meanings within the document.  We propose to remove access unit definition from this paragraph.  Use replacement text for this paragraph and put access unit definition for STD purposes in section 2.4.2, as this definition is only needed for the STD; relevant text can be found in Annex 1.	
T6	13	2.4.2.1		The system clock frequency accuracy requirements are not relevant to and can not be tested for timeless instances of bitstreams, so these requirements should be moved to the RTI specification.	
T7	13	2.4.2.1		The system clock accuracy requirement of 20 ppm is too constraining. Considering the need for and the effect of the recording and subsequent play-back of coded material, practical implementations will require more accurate clocks than 20 ppm to meet this constraint. We suggest this constraint is changed back to 50 ppm.	
T8	14	2.4.2.2	2nd para.	The paragraph is confused as to the difference between the PCR fields in the bitstream, program_clock_reference_base and program_clock_reference_extension, and the names of the variables from which the fields derive their values i.e. PCR_base(i) and PCR_ext(i) respectively.  

The 2nd "input" in the third sentence is not necessary.  In "...encoded in the Transport Stream packet adaptation field of the program to be decoded. ..." a comma should be inserted after "field".  The structure of the 4th sentence is inconsistent, and confuses the reader.  The reference to equation 2-3 in the fourth sentence can be removed.

The following convention is proposed and should be adhered to throughout the text:

	  -  PCR_base(i), PCR_ext(i):  state variables at the encoder.
	  -  program_clock_reference_base, program_clock_reference_extension:  fields in the bitstream which carry the values at time t(i) of PCR_base(i) and PCR_ext(i) respectively.

Replace 2nd par, clause 2.4.2.2, with:

Data from the Transport Stream enters the T-STD at a piece-wise constant rate.  The time t(i) at which the ith byte enters the T-STD is defined by decoding the program clock reference (PCR) fields in the input stream, encoded in the Transport Stream packet adaptation field, of the program to be decoded.  The PCR field is encoded in two parts; one, in units of 1/300 times the system clock frequency, called program_clock_reference_base, and one in units of the system clock frequency, called program_clock_reference_extension.  The values encoded in these fields are computed by PCR_base(i) and PCR_ext(i) respectively, which are given in the following equations.  The value encoded in the PCR field indicates time t(i), where i is the index of the byte containing the last bit of the program_clock_reference_base field.	
T9	14	2.4.2.2		The byte delivery to the T-STD is defined by PCRs in the PCR_PID only.  A statement clearly indicating this should be added.  We suggest MPEG | ITU-T EG should consider the possibility that the PCR_PID is not known as the PAT has not yet been transmitted (currently no need to do this until just before the end of time).	
T10	14-15	2.4.2.2	Last para. on p.14, 1st para. on p. 15	PCR errors are meaningless for timeless bitstreams.  Delivery errors are subject to constraint by the RTI.  Remove the two paragraphs relating to PCR tolerance and PCR errors.	
T11	15	2.4.2.3		Update the description in accordance with the updated model.  Sentences which imply a different model to that which is defined should be removed; for example, '... is allocated for buffering to allow multiplexing'.	
T12	15	2.4.2.3		Add appropriate text that specifies T-STD parameters for constrained parameter MPEG-1 video bitstreams.	
T13	16	2.4.2.3		Add text to solve the R/P problem.  Our preferred solution is that referred to as 'Lionel's proposal'.  This constrains the buffer level to BSn + R/P, with R=15 Mbit/s and P=24 Hz for main profile @ main level, if removal times are delayed by 1/P.	
T14	21	2.4.3.5		When the discontinuity indicator is true, the byte delivery times to the T-STD are not defined for bytes between the last PCR of the old clock and the first PCR of the new clock.  A definition for the byte delivery times of these bytes must be provided.	
T15	21	2.4.3.5		The semantics for the discontinuity indicator are very unclear. The problems are outlined in Annex 2.  It is not clear: whether the discontinuity state applies to one PID at a time or one program at a time; how many PCRs are allowed within a discontinuity state; how PSI information is coded after a continuity counter discontinuity.  We suggest MPEG | ITU-T EG carefully consider this semantic definition, and try to separate semantic definition (what the indicator means and is intended for) and what else must happen when the bit is set.  The latter, as a set of constraints on multiplexed bitstreams, would be better placed in section 2.7.  It should be noted that some of this already appears in section 2.7.6.	
T16	21	2.4.3.5		There is no limit on how many PCRs can be discontinuous.  Decoders can not therefore rely on PCRs and time stamps for timing recovery.  A limit must be placed on the number of PCRs that can be discontinuous.  Section 2.7 is the correct location for such a constraint.	
T17	22	2.4.3.5		The PTS/DTS confusion issue should be solved.  This also affects the semantic definition of the random access indicator.  The problem and new semantics for random access indicator are given in Annex 3.  We strongly suggest, on grounds of interoperability, that the definition used in MPEG-1 be used.	
T18	24	2.4.3.5		It is not possible to test if the OPCR is correct.  The text should be modified to remove the semantic constraint and state that the definition is application specific or it should be modified to provide a complete definition.	
T19	24	2.4.3.5		We suggest that MPEG | ITU-T EG consider whether, in a repeated transport packet, the OPCR should be repeated or recalculated.  Our opinion is that it should be recalculated, rather than repeated as stated in the DIS.	
T20	24	2.4.3.5		Seamless splice flag, legal time window offset, piecewise rate splice type and DTS next AU all refer to a three buffer model.  These should be brought into line with the accepted buffer model.  If the accepted buffer model prevents a definition of such syntactic elements, then their definition should be stated as being application dependent.	
T21	29

35	Table 2-17

2.4.3.7	

pack_header_field_flag, program_packet_sequence_counter_flaG, pack_field_length, and program_packet_sequence_counter syntax and semantics	The two flags pack_header_field_flag and program_packet_sequence_counter_flag are mutually independent.  However the fields that they indicate the presence of are not.

The original_stuff_length field only has meaning when a pack_header() field is present.  However the presence of the program_sequence_counter, required for every PES packet, always includes the original_stuff_length field.  

pack_field_length, pack_header(), MPEG1_MPEG2_identifier and the original_stuff_length fields only have meaning in the Transport Stream i.e. when a Transport Stream carries a Program Stream or an MPEG-1 system stream.  None of these fields are relevant to a Program Stream.  The semantics for pack_header_field_flag correctly state that a pack_header() is never present in a PES packet when carried in a Program Stream.

However it is proper that the program_packet_sequence_counter mechanism be available for use in the Program Stream, as a method of detecting PES packet loss, particularly the PES packet header.  

In the pack_header_field_flag semantics there are incorrect uses of "an" in "... an Program Stream ...".  The flag values are explained inconsistently i.e. "set to '0'", and "set to a value of '0'".

In the pack_field_length semantics there is reference to "pack_header_field()".  There is no such field.

In the program_packet_sequence_counter_flag semantics both "PES packet" and "PES header" are used to mean the same thing.  The flag values are explained inconsistently i.e. "set to '1'", and "set to a value of '0'".

In the program_packet_sequence_counter semantics there are three incorrect uses of "an".  Commas would assist here.  

The current semantics for pack_header_field_flag, program_packet_sequence_counter_flag, pack_field_length, program_packet_sequence_counter, MPEG1_MPEG2_identifier, and original_stuff_length, and are written in a way that does not make clear the intended purpose of the fields.  Some of these semantics contain errors.	
				Proposals

Replace syntax in table 2-17 with the one in Annex 7.

On pages 35 and 36, arrange the order of the semantic definitions to match the syntax in Annex 7.

Replace pack_header_field_flag, program_packet_sequence_counter_flag, pack_field_length, and program_packet_sequence_counter, semantics on page 35 with,

pack_header_field_flag -- A 1 bit flag which when set to '1' in a Transport Stream indicates that an ISO/IEC 11172 pack_header() or a Program Stream pack_header() with associated fields is stored in this PES packet header.  In a Transport Stream when set to '0' it indicates that no pack_header() with associated fields is present in the PES packet header.  In a Program Stream if this field is present, then it shall be set to '0'.

program_packet_sequence_counter_flag -- A 1 bit flag which when set to '1' indicates that the program_packet_sequence_counter field is present in this PES packet header.  When set to '0' it indicates that this field is not present in the PES packet header.

pack_field_length -- This is an 8 bit field which indicates the length, in bytes, of the following pack_header() field. 

program_packet_sequence_counter -- The program_packet_sequence_counter field is a 7 bit field.  It is an optional counter that increments in successive PES packets from a Program Stream, or from an ISO/IEC 11172 System Stream, when these streams are carried in a Transport Stream.  This allows an application to retrieve the original PES packet sequence of a Program Stream or the original packet sequence of an ISO/IEC 11172 system stream.  It may also be used with successive PES packets associated with a single program definition in a Transport Stream, or with successive PES packets in a Program Stream.  The counter will wrap around to 0 after its maximum value. Repetition of PES packets shall not occur. Consequently, no two consecutive PES packets in the program multiplex shall have identical program_packet_sequence_counter values.  	
T22	30	2.4.3.7	Table 2-18	stream_id value 1111 0100 should be allocated for ITU-T auxiliary data.  A note attached to this table entry should read, "This stream_id only is allowed in streams with stream_type = 0x09 (table 2-35)."  See Annex 4.	
T23	30	2.4.3.7	Table 2-18	The description of stream_id 110x xxxx should be changed to read, "ISO/IEC 13818-3 or ISO/IEC 11172-3 or ITU-T audio stream number x xxxx".  See Annex 4.	
T24	30	2.4.3.7	Table 2-18	The description of stream_id 1110 xxxx should be changed to read, "ITU-T H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 or ITU-T video stream number xxxx".  See Annex 4.	
T25	31	2.4.3.7	data_alignment_indicator	The expression "... access unit data type ..." in this context is dangerous, since it is different from the formal definition of access unit as used in the STDs.  Change to "... video or audio elementary stream alignment type ..."	
T26	32	2.4.3.7		The semantic definition of PTS and DTS should be improved according to the solution to the PTS/DTS confusion issue Annex 3.  Suitable text is in Annex 1	
T27	40	2.4.4.5		It should be clarified how the PAT is updated, and when it becomes valid if composed of more than one section.  Do all sections need to be sent?  or just those that have changed?  When does the table become valid?  after one each section, or after all sections?	
T28	43	2.4.4.9		The choice of values for PCR_PID should be clarified.  For example, can it be set to the PMT PID for another program, which has a different timebase?  E-mail discussions suggest that some constraints should be applied to decouple programs with different timebases.  This may involve the addition of normative constraints; these, if considered necessary, should be located in section 2.7.	
T29	43	2.4.4.9		We do not support the mandatory coding of PSI: current wording suggests that one PAT indicating the presence of no programs is valid.  However, it should be clarified that such constraints as the T-STD can only be defined if PSI is present; for example, the T-STD constraints are only defined for programs defined in a PMT.  Data without a PMT has no defined constraint, and may not be decodable on standard decoders.	
T30	46	2.5.1	Line 1	It is suggested to change the line as follows;

"The Program Stream begins with a system header that optionally may be repeated."  ==>
"The Program Stream begins with a Pack that contains a system header.  The system header optionally may be repeated in other Packs."	
T31	46	2.5.1		Comments about the T-STD that have meaning in the context of P-STD and PES-STD also apply to those STDs.	
T32	47	2.5.2.2	1st para.	The text suffers from the same problem as the equivalent section in the T-STD:  there is confusion between the names of fields in the bitstream, and the names of the variables from which the fields derive their values.

The convention of T8 should be adhered to.

Replace paragraph with:

Data from the Program Stream enters the P-STD.  The time t(i) at which the ith byte enters the P-STD is defined by decoding the system clock reference (SCR) fields in the input stream , encoded in the pack header.  The SCR field is encoded in two parts; one, in units of 1/300 times the system clock frequency, called system_clock_reference_base, and one in units of the system clock frequency, called system_clock_reference_extension.  The values encoded in these fields are computed by SCR_base(i) and SCR_ext(i) respectively, which are given in the following equations.  The value encoded in the SCR field indicates time t(i), where i refers to the byte containing the last bit of the system_clock_reference_base field.	
T33	49	2.5.2.3		There is no text concerning trick modes for the P-STD and the PES-STD.  Assuming these modes are allowed, text should be added or a reference to the T-STD should be made.	
T34	49	2.5.2.4		As PES streams are not recognised as MPEG streams, it is best not to mention them.  The PES-STD is a means to constrain and define the ES_rate and ESCR parameters.  All that is necessary is a definition of the bytes to which it refers, and how it operates.	
T35	55	2.5.4.2	2nd and 3rd para.	program_stream_info_length and marker_bit should be changed in order.  (marker_bit appears first in the syntax.) 	
T36	55	2.5.4.2	Table 2-35	The description corresponding to value 0x09 should read: "ITU-T auxiliary".  See Annex 4.	
T37	58	2.6		It would be advisable to mention that Program and Elementary stream descriptors are included in the Program Stream map or Transport Stream program map section.	
T38	59	2.6	Table 2-39	In Page 42 Table 2-28 and 2.5.4.1 Page 54 Table 2-34, it is not clear which descriptors in Table 2-39 are described in the first descriptor() field (in the N times for{} loop) and which are in the second descriptor() field (in the N2 times for{} loop).  It is recommended to add two columns in Table 2-39 to clarify this point.  See a separate contribution from Japan AVC-691|MPEG94-???.	
T39	66	2.6.20		MPEG|ITU-T EG should consider the consequence of the system clock descriptor in the case of recording bitstreams on storage media.  When the bitstream is replayed the clock may not be as accurate as before storage.  This implies that either the recorder must modify the descriptor or that it will be incorrect.	
T40	70	2.7.1		The one second constraint is applied to still picture video, a concept that is not defined in the DIS.  MPEG | ITU-T EG should clarify what is meant by still picture video.  Also, we suggest that MPEG | ITU-T EG consider whether this one second constraint should be applied in the case of trick modes.	
T41	71	2.7.6		The paragraph about decoding discontinuities is unclear.  This should be related to the discontinuity indicator, and not relate to the decoding times, as this can be circular.  Two constraints seem to be implied: video discontinuities can only occur at the start of a video sequence; and a timestamp shall be encoded immediately after a discontinuity, except in low delay and trick modes.  MPEG | ITU-T EG should consider whether this is a correct interpretation.	
T42	78-83	A.2		The words "playback" and "retrieve" are used in the same meaning.  Use of these words should be unified.  Especially, on page 82, a name of the syntactic element should exactly correspond to each other in the Table and in the semantic meanings explanation.	
T43	78-83	A.2		It seems that plural flags which specify non-compatible mode can be set simultaneously in this DSM-CC control layer. To avoid this situation, the following statement should be added as a last constraint in "Constraints on setting flags in DSM CC control" in Section A.2.4 (p.79),

"Encoder shall avoid to set any combination of flags which specify  non-compatible modes simultaneously."	
T44	-	-		The RTI specification should be included as a normative annex to IS 13818-1, which would be incomplete without it.  It is beneficial to prevent the claim of compliance to ITU-T Rec. H.262|ISO/IEC 13818-1 when compliance with the RTI is not achieved.	

II	Comments requiring only editorial change

#	Page	Section	Location	Comments	
E1			all through the text	As a general editorial comment, in ITU standards we do not quote the page numbers for textual references (this is done only for Corrigendums or Amendments).  The page numbers quoted in the draft will maybe change after final editing.  We shall then have page numbers only in the Contents part.	
E2	ii	Contents	1.4	The title should be "Additional references".	
E3	ii	Contents	2.4.3, 2.5.3	Entries for 2.4.3 and 2.5.3 are incorrect.  They should also refer to semantics.  Correct as follows:

2.4.3 Specification of the Transport Stream syntax and semantics
2.5.3 Specification of the Program Stream syntax and semantics	
E4	vi	List of syntax tables	2.6	The entry for table 2-6 is "Transport Stream adaptation header".  The term "header" is incorrect and not defined.  Change "header" to "field".	
E5	vi-vii	List of syntax tables	2-44 through 
2-58	Table numbers should be shifted down by one such as 
2-44 ==> 2-43, 2-59 ==> 2-58.	
E6	viii	List of equations		The words "equation", "calculation", and "expression" all have the same meaning.  In any case, these words are not required.  The heading identifies the entries as being equations.  Remove these words from the list of equations entries.	
E7	viii	List of equations	2-12	Replace with "2-12 -- elementary stream clock reference base"	
E8	viii	List of equations	2-22
2-27	Add "(Program Stream) at the end.
Add "(Transport Stream)" at the end.	
E9	xii	0.1	1st para. Line 2	'dataaccording' should be two words	
E10	xv	0.2	2nd para.
Line 1	"The prototypical decoder accepts as input an Program Stream ..." ==> 
"The prototypical decoder accepts as input a Program Stream ..."	
E11	xv	0.3	1st para.	'It is possible and reasonable to convert between TS and PS'.  Possible yes, but not always reasonable: PS does not always have locked clocks, which makes this conversion unreasonable. Delete 'and reasonable'.	
E12	xv	0.3	1st para. Last sentence	'It is possible to identify the correct order of PES packets' only if the program packet sequence counter is present.  This mechanism CAN NOT work if an elementary stream is shared between two programs.  Replace with 'It may be possible...' or 'syntactic elements are defined to allow the identification...'	
E13	xv	0.3	2nd para. Last sentence	'Such data shall be available' looks like a normative constraint on information very vaguely defined. Any data present must be correct, but optional syntax elements may be absent.	
E14	xvi	0.4	2nd para. 2nd sentence	'When PES packets are used to form a PES stream, they shall' is a normative constraint on a format that is not for 'interchange and interoperability'.  We suggest that this sentence be removed.	
E15	xvi	0.5	1st para. 2nd sentence	'delays' should be added to the end of the second sentence.	
E16	xvii	0.8.1	2nd para.	In the first part of "Both fixed and variable PES packet lengths are allowed, but will be relatively long in most applications", there is no conjecture about packet length.

Replace "but" with "and".	
E17	xviii	0.9	Line 1	"Part  1 of ISO/IEC 13818" ==> This Specification, or "ITU-T Rec. H.222.0|ISO/IEC 138-1"	
E18	xviii	0.9	Line 5	Rec. H.222.0 | ISO/IEC 13818 ==>
Rec. H.222.0 | ISO/IEC 13818-1	
E19	xviii	0.9	Line 6
Line 7	'will forward play in normal speed on corresponding STDs' should be replaced by 'shall meet the appropriate STD's constraints'.	
E20	xviii	0.9	Line 6	a stream plays properly ==> a stream operates properly	
E21	xviii	0.10	2nd para.	ITU-T Rec. H.222.0 | ISO/IEC 13818 video and ISO/IEC 13818 audio ==>
ITU-T Rec. H.262 | ISO/IEC 13818-2 video and ISO/IEC 13818-3 audio	
E22	1	1.1	1st para., Line 1	This part of ITU-T Rec. H.222.0 | ISO/IEC 13818 ==> 
ITU-T Rec. H.222.0 | ISO/IEC 13818-1	
E23	1	1.1	1st para., Lines 2-3	in Part 2 and 3 of this Recommendation | International Standard ==>
in ITU-T Rec. H.262 | ISO/IEC 13818-2 and ISO/IEC 13818-3	
E24	1	1.1	2nd para., Line 1	An ITU-T Rec. H.222.0 | ISO/IEC 13818 multiplexed bit stream ==>
An ITU-T Rec. H.222.0 | ISO/IEC 13818-1 multiplexed bit stream	
E25	1	1.1	3rd para., Line 1	An ITU-T Rec. H.222.0 | ISO/IEC 13818 multiplexed bit stream ==>
An ITU-T Rec. H.222.0 | ISO/IEC 13818-1 multiplexed bit stream	
E26	1	1.1	3rd para.,
Last line	of this part  ==> of this Recommendation | International Standard	
E27	1	1.2	1st para.	In clause 1.2. make the following replacements. 

"...applying the most recent editions of the Recommendations and International Standards indicated below.  Members of IEC and ISO maintain registers of currently valid International Standards. ..."	
E28	3	2.1.8	Line 2	in Part 1  ==> in this Specification	
T29	3	2.1.16	Line 2	The word "and" appears twice, consecutively.  Remove one "and". 	
E30	4	2.1.27	Title	ITU-T Rec. H.222.0 | ISO/IEC 13818 (multiplexed)  ==>
ITU-T Rec. H.222.0 | ISO/IEC 13818-1 (multiplexed) 	
E31	4	2.1.27	Line 2	in Part 1 of this Recommendation | International Standard ==> in this Specification	
E32	4	2.1.28	Line 2	Parts 1 and 2 of this Recommendation | International Standard ==> 
ITU-T Rec. H.222.0 | ISO/IEC 13818-1 and ITU-T Rec. H.262 | ISO/IEC 13818-2	
E33	7-8	2.2.6		"ch" trough "switch_point_s" and "window" are for audio, hence should be removed.	
E34	10	2.4.1	3rd para.
Lines 6-7,
Line 9,
Lines 10-11,
Line 12	Part 2 of this Recommendation | International Standard ==>
ITU-T Rec. H.262 | ISO/IEC 13818-2	
E35	10	2.4.1		The heading "ITU-T Rec. H.222.0 | ISO/IEC 13818 multiplexed Transport Stream" serves no purpose.  Remove it.  If it remains, change "ISO/IEC 13818" to "ISO/IEC 13818-1" 	
E36	11	2.4.1	2nd para.	in table 2-27  ==>   in Table 2-28	
E37	12	2.4.2	PCR(i) notation	There is a reference to the PCR_base field.  There is no such field.  Correct the reference to be "program_clock_reference_base". 	
E38	13	2.4.2	notation	Repeating the numerical values of some buffer sizes and rates in the notation section is unconventional, and dangerous.  Numerical values should be stated once, and once only, in the appropriate semantic clause.  The notation section should be used for notation only.

Remove numerical values from the notation section.	
E39	13	2.4.2	6th para., 7tth para.	Descriptions of TBsys and TBSsys should appear after that of TBn and TBSn in accordance with the order of Bn, BSn, Bsys and BSsys.	
E40	13	2.4.2	Rxn and Rxsys	Rxn and Rxsys are defined but not used.  

Either:
	-  use the terms as replacements for Rx in clause 2.4.2.3 page 15.  They should also be shown in Figure 2-6 on page 12.
	or
	-  remove them, and insert a definition in the notation section for Rx.	
E41	14	2.4.2.2	1st para.	The reference to "...last bit of two successive PCR fields..." may not be incorrect, but should be made consistent with the other PCR field references i.e. the byte containing the last bit of the program_clock_reference_base field.

Replace with "...last bit of two successive program_clock_reference_base fields...".	
E42	14	2.4.2.2	3rd par following equation 2-4	"program_clock_reference base" ==> 
"program_clock_reference_base"	
E43	14	2.4.2.2	4th par following equation 2-4	Underlines do not work on the informal references to the PCR fields i.e. "...program_clock_reference base and extension fields..."

Replace with "...program clock reference base and extension fields...", or state the field names formally i.e. "...program_clock_reference_base and program_clock_reference_extension fields...".	
E44	14	2.4.2.2	equation 2-4 and equation 2-5	This section should be cleaned up as in Annex 5.	
E45	14	2.4.2.2	2nd par following equation 2-5	"program_clock_reference base"
==>
"program_clock_reference_base field".	
E46	15	2.4.2.3	3rd para. Line 1	Rx, shall be zero  ==>  Rx shall be zero
(but see E40)	
E47	15	2.4.2.3	3rd para. Line 2	for video	Rx = 1.2 x Rmax [p.l] where ==>
for video	Rx = 1.2 x Rmax [p.l.] where	
E48	15
49	2.4.2.3
2.5.2.4	notation [p.l.]	The expression for the maximum bit rate in each profile and level, Rmax[p.l.], is written inconsistently, and is unconventional.  The significance of square brackets is difficult to understand, as are the two dots used within.  Similarly for VBVmax[p.l.].

Use the terms, Rmax(profile,level), and VBVmax(profile,level), and place entries in the respective notation sections 2.4.2, 2.5.2	
E49	15	2.4.2.3	after "for video   Rx=..."	part 2 of this recommendation  ==> 
ITU-T Rec. H.262 | ISO/IEC 13818-2	
E50	15	2.4.2.3	after "for video   BSn=..."	part 2 of this recommendation  ==> 
ITU-T Rec. H.262 | ISO/IEC 13818-2	
E51	16	2.4.2.3	3rd para.	The paragraph relating to the removal of data from second buffers should be improved to be precise about when access units without timestamps are removed from the buffer.  Suitable text is in Annex 1, but may also need some equations relating decode times to differences in VBV removal times, as described in Annex 6.  Video stuffing bytes should be removed if present, else left until next time; the exact number should not be made to correspond to what the VBV would have done.	
E52	16	2.4.2.3	3rd para.
Line 6	ITU-T Rec. H.222.0 | ISO/IEC 13818-2 video ==>
ITU-T Rec. H.262 | ISO/IEC 13818-2 video	
E53	16	2.4.2.3	Trick mode 	Slow reverse should be treated in the same way as slow motion. The text should be clarified to state how to restart after freeze frame.	
E54	17	2.4.2.4	3rd para. Line 1	Part 2 of this Recommendation | International Standard ==> ITU-T Rec. H.262 | ISO/IEC 13818-2	
E55	17	2.4.2.4		This text confuses presentation units and access units: presentation units are reordered and not access units, as reordering is performed after decoding.  Suitable text is in Annex 1.	
E56	19	2.4.3.3	PID	The text states that "PID value 0x0??? is reserved for ...".  But the current status is as follows:
  
0x0000 is allocated to Program Association Table
0x0001 is allocated to Conditional Access Table
0x0002 - 0x000F is reserved
0x0010 - 0xFFFE is defined by the user
0x1FFF is allocated to Null packets	
E57	19	2.4.3.3	2nd last para.	ITU-T Rec. H.222.0 | ISO/IEC 13818-1 ==>
ITU-T Rec. H.222.0 | ISO/IEC 13818-1	
E58	22	2.4.3.5	randam_access_indicator
Line 5	of hte next ...==> of the next ...	
E59	23	2.4.3.5	program_clock_reference_base; program_clock_reference_extension	The words fail to adequately express what equations 2-1, 2-2, and 2-3 have satisfactorily expressed.  "program_clock_reference" should not have underscores as it is not a syntactic element.  The meaning of the term "... a 90 kHz start. ..." is not clear.  The expression "...the least significant bit of the program_clock_reference_base field will increment by 1. ..." is unacceptable.  (What about the other bits?)

The DIS is unclear as to the relationship between the PCR fields program_clock_reference_base and program_clock_reference_extension, and the state variables at the encoder PCR_base(i) and PCR_ext(i), from which the fields obtain their values, respectively.

The convention proposed in T8 should be adhered to.

There is no reason why the SCR in the Program Stream and the ESCR fields in the PES packet should not be identically worded, where appropriate.  OPCR should be consistent.

The semantics for the PCR fields on page 23 become:

program_clock_reference_base; program_clock_reference_extension -- The program clock reference is a 42 bit field coded in two parts.  The first part program_clock_reference_base, is a 33 bit field whose value is given by PCR_base(i), as given in equation 2-1 on page 14.  The second part program_clock_reference_extension, is a 9 bit field whose value is given by PCR_ext(i), as given in equation 2-2 on page 14.  The PCR field indicates the intended time of arrival of the byte containing the last bit of the program_clock_reference_base at the input of the system target decoder.  The presence of the PCR field is indicated by the PCR_flag.

If a PCR field is present in a Transport Stream packet containing data from a video or audio elementary stream, it shall be valid for that elementary stream.  Refer to clause 2.7.3 for frequency of coding requirements for PCR.
	
E60	24	2.4.3.5	semaless_splice_flag
Line 1	The sentence "...This is a 1 bit field which when set to '1' shall satisfy the following conditions." is nonsensical.
Replace with "...This is a 1 bit field which when set to '1' indicates that the following conditions are true."	
E61	25	2.4.3.5	Line 2	,until the the splice  ==> ,until the splice 	
E62	26-27	2.4.3.5	Table 2-15	A page break separates the rows of the table.  Keep the rows of the table together.	
E63	27	2.4.3.6	3rd last line	PTS[32.30] ==> PTS[32..30] 	
E64	27	2.4.3.6	Last line	PTS[29.15] ==> PTS[29..15]	
E65	30	2.4.3.7	Table 2-18 Note 2	ITU-T Rec.H.220.0|ISO/IEC 13818-2 ==> 
ITU-T Rec.H.262|ISO/IEC 13818-2	
E66	32	2.4.3.7	Eq. (2-11)
last line	2.4.2 on page 11 ==> 2.4.1 on page 10	
E67	32-33	2.4.3.7	PTS, DTS, ESCR, ES_rate	In the semantics for the fields PTS, DTS, ESCR, ES_rate, bracketed explanations are given for the mnemonic names.  The explanations contain underscores for no apparent reason.

Remove underscores in bracketed terms.	
E68	33-34	2.4.3.7	ESCR
ES_rate	The current definition of ESCR and ES_rate is a little unclear, it should be more precise about referring only to PES streams.  This also relates to the text for the PES STD which could be expanded to make it clearer.

There is no 90 kHz system clock.  The form of the ESCR semantics should match those of PCR and SCR.  Write ESCR semantics using the same form as that of PCR and SCR (see E59).	
E69	33	2.4.3.7	trick_mode_control	2nd line after Table 2-20
In " ..... elementary stream data to be incorrect in.", the last word "in" is spurious.	
E70	34	2.4.3.7	5th and 6th para.	fast_reverse ==> fast reverse
slow_reverse ==> slow reverse	
E71	34	2.4.3.7	intra_slice_refresh Line 3	part 2 of this Recommendation|International Standard==> 
ITU-T Rec.H.262| ISO/IEC 13818-2	
E72	35	2.4.3.7	PES_extension_flag_2	There is no such element as "PES_extesnion_filed".  This should be expressed as "PES extension field"?  Or alternatively we should say "... when set to
'1' indicates the presence of PES_extension_length_field and any associated fields.  When set to a value of '0' this indicates that they are not present."	
E73	37	2.4.4	Table 2-23
"Reserved PID#" column	Reserved PID# ==> PID#
Assigned ==> Assigned by the user
See E56.	
E74	38	2.4.4.2	pointer_field	The semantic description of pointer_field is syntax in text form.  The use of the pointer_field and the mapping of PSI data into transport packets could be clarified by use of syntax rather than words, as everywhere else in the MPEG standard.  MPEG | ITU-T EG should consider whether it would be beneficial to make this change.	
E75	39	2.4.4.5		The semantic definitions for PAT are repeated for CAT, PMT and private sections.  Repeated text requires close scrutiny to verify that it is the same, as it suggests that something is subtly different.  Such repetition can be eliminated by combining the common syntax, and providing a single set of semantics for this.  MPEG | ITU-T EG should consider whether it would be beneficial to make this change.	
E76	40	2.4.4.5	current_next_indicator	It may be beneficial to clarify the meaning of current next indicator.  This is understood to mean, when set to '1', that the PSI is applicable to the first and subsequent transport packets after the transport packet containing the end of the section, and if the PSI has just changed, that the previous PSI is applicable to transport packets up to and including the one immediately before the transport packet containing the end of the section.	
E77	42	2.4.4.9	program_number	Informative Annex C ==>
Clause C.6 of Informative Annex C	
E78	46	2.5.2	1st para. Line 1,
Line 2	clause 2.5.4 on page 54 ==> clause 2.5.3 on page 49	
E79	47	2.5.2	2nd para.
SCR(i)	SCR_base ==> system_clock_reference_base	
E80	48	2.5.2.2	Eq. (2-20)
in the notation for i'	system_clock_reference base field ==>
system_clock_reference_base field	
E81	48	2.5.2.2	Eq. (2-20)
in the notation for SCR(i')	It says "... is the time encoded in the system_clock_reference base and extension fields".  There is no "system_clock_reference" syntactical element. 

Either make the field reference explicit, or remove the underscores to make an informal reference to the fields.	
E82	48	2.5.2.2	Eq. (2-20)
Last line	clause 2.5.3.3 on page 49 ==>
clause 2.5.3.4 on page 51	
E83	49	2.5.2.4	1st para.
Line 3	Elementary System Clock Reference ==>
Elementary Stream Clock Reference	
E84	49	2.5.2.4	after "For video, BSn= ..."	part 2 of this Recommendation|International Standard==> 
ITU-T Rec.H.262| ISO/IEC 13818-2	
E85	49	2.5.2.5	Line 2	in clause 2.4.3 on page 11. ==> in clause 2.4.2.4 and 2.4.2.5 on page 17, respectively.	
E86	50	2.5.3.4	2nd para.
SCR semantics	The SCR semantics suffer from the same problems as those of the PCR (see E59).  The form of the SCR semantics should match those of PCR.

Write SCR semantics using the same form as that of PCR (see E59).  The SCR semantics become:

system_clock_reference_base; system_clock_reference_extension -- The system clock reference is a 42 bit field coded in two parts.  The first part system_clock_reference_base, is a 33 bit field whose value is given by SCR_base(i), as given in equation 2-17 on page 48.  The second part system_clock_reference_extension, is a 9 bit field whose value is given by SCR_ext(i), as given in equation 2-18 on page 48.  The SCR field indicates the intended time of arrival of the byte containing the last bit of the system_clock_reference_base at the input of the system target decoder.	
E87	51	2.5.3.4	pragram_mux_rate 
Lines 2-2	measured in units of 50 bytes/second ==>
measured in units of 50 bytes/second rounded upwards	
E88	51	2.5.3.6	rate_bound	program mux_rate ==> program_mux_rate	
E89	52	2.5.3.6	system_audio_lock_flag
Line 3	Clause 2.5.2 on page 46 ==> Clause 2.5.2.1 on page 47	
E90	52	2.5.3.6	system_video_lock_flag
Line 3	Clause 2.5.2 on page 46 ==> Clause 2.5.2.1 on page 47	
E91	53	2.5.3.6	stream_id	There are three syntactical elements with the same name.  Each have different semantics.  They are stream_id in the PES_packet(), stream_id in the sytem_header(), and stream_id in the Program Stream directory.  Is that reasonable?

It is noted that the Program Stream Map uses the name map_stream_id.  It is also noted that ISO/IEC 11172 uses stream_id in the system_header().

Use stream_id in the PES packet header.  There may be justification for using stream_id in the system_header().  

However stream_id in the Program Stream directory should be changed to "directory_stream_id" (see E96).	
E92	53	2.5.3.8	1st para. Lines 4-5	ITU-T Rec. H.222.0 | ISO/IEC 13818-1 Pack Header Field ==>
ITU-T Rec. H.222.0 | ISO/IEC 13818-1 pack_header()	
E93	53	2.5.3.8	1st para., last but one line	" ... pack_header field is no longer present the PES packet header." ==>
" ... pack_header() field is no longer present in the PES packet header."	
E94	53	2.5.3.8	2nd para. Lines 1-2	"pack_header" and "system_header" should be referred to as "pack_header()" and "system_header()". 

Either add the brackets to make the reference formally correct, or remove the underscores, and make the reference to these syntactical elements informal.	
E95	55	2.5.5		The term "access unit" is used extensively in this clause.  Does the term have the same meaning as used in the STDs, or are only I pictures required to be referenced?

Confirm that "access unit" is correct.  "random access unit" may be a better term.	
E96	55
56
57	2.5.5
2.5.5.1
2.5.5.2	1st para.
Table 2-36
2nd para.	"directory_stream_id"  in the second line of 2.5.5 is undefined.  However the use of "directory_stream_id" is preferable to "stream_id" in the Program Stream Directory, since "stream_id" is already used in the PES packet (see E91).

Change "stream_id" to "directory_stream_id" in table-36 and clause 2.5.5.2.	
E97	55	2.5.5	2nd para. Lines 1-2	defined in part 2 of this Recommendation | International Standard and ISO/IEC 11172 ==> 
defined in ITU-T Rec. H.262 | ISO/IEC 13818-2 and ISO/IEC 11172-2	
E98	55
56	2.5.5
2.5.5.1		The use of the mnemonic "PES" in relation to the Program Stream Directory is bad.  The Program Stream Directory is no more a PES packet than is a pack_header().  The only syntax in common with the PES packet, is the first three fields, as with all packet structures in the Program Stream.

Remove all references to PES in the text in clause 2.5.5.  Add an introductory sentence stating the purpose of the Program Stream directory.  Replace the first paragraph in clause 2.5.5 with,

The Program Stream directory provides a means of identifying random access points in a Program Stream.  The Program Stream directory consists of all occurrences of program_stream_directory_section(), the syntax of which is shown in clause 2.5.5.1.

The title of clause 2.5.5.1, and the title of table 2-36 become "syntax of the program_stream_directory_section".

The name of the syntax element described in table 2-36 becomes "program_stream_directory_section()". 	
E99	56
57	2.5.5.1
2.5.5.2	Table 2-36
	Does the PES_header_position_offset field in the Program Stream directory table syntax, always point to the start of a PES packet?  May not it also point to the beginning of a pack_header()?

References to PES in relation to the naming of fields in the Program Stream directory should be removed.  Appropriate names should be chosen.

The second sentence of the PES_header_position_offset semantics says "The offset address is relative to the 1st byte of the start code of the PES packet containing this PES_header_position_offset field".  The meaning of this sentence is unclear.

If the first part of above is true, then remove references to PES in the field names to reflect the general nature of the pointer e.g. packet_position_offset, random_access_unit_position_offset?  Rewrite the field semantics to accurately reflect the purpose of the field.	
E
100	57	2.5.5.2	PES_header_position_offset	"This 44 bit unsigned integer gives the byte offset address of the 1st .." ==> 
"This 44 bit unsigned integer gives the byte address offset of the 1st .."?	
E
101	58
59	2.6
2.6.1	2nd para.
able 2-39	Table 2-39 and the preceding paragraph are misplaced.  They relate to the descriptor_tag semantics, and should be included there.

Move the last paragraph on page 58 and table 2-39 to the descriptor_tag semantics in clause 2.6.1.	
E
102	63	2.6.11	Table 2-48	Description  ==> description	
E
103	64	2.6.13	pel_aspect_ratio	See Part 2 of this Recommendation | International Standard ==> See ITU-T Rec. H.262 | ISO/IEC 13818-2	
E
104	67	2.6.22	Table 2-55	multiplex_delay variation  ==>  multiplex_delay_variation	
E
105	68	2.6.25	copyright_identifier	SC29 ==> ISO/IEC JTC1/SC 29	
E
106	70	2.7.1	1st para. Line 2	clause 2.4.2 on page 11 and clause 2.5.2 on page 46 ==> clause 2.4.2.3 on page 15	
E
107	70	2.7.1	1st para.	References to the T-STD and P-STD clauses on buffering are vague, and can be made more explicit, as clause numbers exist for each of these sections. 

Change to "...

An exception to this condition is that the buffers Bn may underflow when skipped pictures occurs; see clause 2.4.2.3 and clause 2.5.2.3.	
E
108	70	2.7.2		In the final sentence i is incorrectly referred to as a byte.  It is a byte index.  In the first and last sentences there is no such syntactical element as "system_clock_reference".  It should be "system_clock_reference_base".  The underscores on "system_clock_reference" in the title should be removed.

Change the first sentence to,

The Program Stream shall be constructed so that the time interval between the bytes containing the last bit of the system_clock_reference_base fields in successive packs shall be less than or equal to 0,7 seconds.

Change the last sentence to,

for all i and i', where i and i' are the indexes of bytes containing the last bit of consecutive system_clock_reference_base fields.	
E
109	70	2.7.3		Similarly to E107. 

Change title to "2.7.2 Frequency of coding the program clock reference".

Change the first sentence to,

The Transport Stream shall be constructed so that the time interval between the byte containing the last bit of the program_clock_reference_base fields in successive occurrences of the PCRs in Transport Stream packets of the PCR_PID for each program shall be less than or equal to 0,1 seconds.

Change the last sentence to,

for all i and i', where i and i' are the indexes of bytes containing the last bit of consecutive program_clock_reference_base fields in the Transport Stream packets of the PCR_PID for each program.	
E
110	70	2.7.4		Similarly to E99. 

Change the first sentence to,

The Program Stream and Transport Stream shall be constructed so that if the ESCR field is coded in any PES packets containing a given elementary stream the time interval between the bytes containing the last bit of successive ESCR_base fields shall be less than or equal to 0,7 seconds.

Change the last sentence to,

for all i and i', where i and i' are the indexes of bytes containing the last bit of consecutive ESCR_base fields.	
E
111	71	2.7.6	1st para.
Line 4	(see Part 2 of this Recommendation | International Standard ==> (see ITU-T Rec. H.262 | ISO/IEC 13818-2	
E
112	72	2.7.9	Equation 2-25	The units are incorrectly placed in brackets, and may be interpreted as being a multiplying factor in the equation.  Refer to the equivalent clause in ISO/IEC 11172 as to how it should be written.

Change to,

    Rmax = 8x50xrate_bound   bits/sec	
E
113	72	2.7.9	Equation 2-25
tm(i) and tm(i')	There is reference to "system_clock_reference".  No such syntactical element is defined.

Change to "system clock reference" or "SCR".	
E
114	72	2.7.9	Last line	The paragraph "Rvmax is the peak video bit rate" is incorrectly placed.  It should be moved up two paragraphs, and be preceded by "where".  Refer to the equivalent clause in ISO/IEC 11172 as to how it should be written.

BSadd is specified as 

     BSadd <= MAX[6x1024, Rvmax x 0.001]       bytes 

where Rvmax is the peak video bit rate.	
E
115	72	2.7.10	title	It should read "2.7.10 - Sample rate locking in transport streams".  "Transport Stream" just after the clause number
is spurious.	
E
116	73	2.7.10	Line 2	in Part 2 of this Recommendation | International Standard  ==> in ITU-T Rec. H.262 | ISO/IEC 13818-2	
E
117	74	A.0	1st para.
Line 2	"... specific to managing a ITU-T Rec. H.222.0 .." ==> 
"... specific to managing an ITU-T Rec. H.222.0 .."	
E
118	74	A.0 	Last line	==> 4.	it is independent ....	
E
119	76	A.1.2	Lines 2 and 3	a ITU-T Rec. H.222.0 | ISO/IEC 13818-1 bitstream ==>
an ITU-T Rec. H.222.0 | ISO/IEC 13818-1 bitstream	
E
120	76	A.1.2	Line 4	figure A-1 ==> Figure A-1	
E
121	76	A.1.2	Figure A-1	"System Target Decoder" ==> "System Decoder"	
E
122	76	A.1.3	1st para.
Line 3	a ITU-T Rec. H.222.0 | ISO/IEC 13818-1 Systems bitstream ==> an ITU-T Rec. H.222.0 | ISO/IEC 13818-1 Systems bitstream	
E
123	76	A.1.3	2nd para.
Line 2	figure A-2 ==> Figure A-2	
E
124	77	A.1.3	2nd para.
Line 2	packetized element stream (PES) ==> 
packetized elementary stream (PES)	
E
125	77	A.1.3	2nd para. Line 3	clause 2.4.3.6 of this Recommendation | International Standard ==> clause 2.4.3.6 of this Specification	
E
126	77	A.1.3	2nd para.
Last line	Figure 3 ==> Figure A-3	
E
127	77	A.1.3	Last para.
Line 3	page 30 of the System part of the IS ==>
page 30 of this Specification	
E
128	78	A.2.1.1	Lines 1-2	by this International Standard ==> by this Specification	
E
129	78	A.2.1.3		Program Stream or Transport stream ==> ITU-T Rec. H.222.0|ISO/IEC 13818-1 Program Stream or Transport Stream	
E
130	79	A.2.3	DSM_start_code	DSM_start_code ==> DSM_CC_start_code
The DSM_start_code is  ==> The DSM_CC_start_code is	
E
131	86	C.2	1st para.
Last line	see Annex D ==> is this reference correct?	
E
132	87	C.2	1st para.
Line 5	a meaning may be defined by ISO ==>
a meaning may be defined by ITU-T|ISO/IEC	
E
133	89	C.8	Line 1	Figure 1-C-1 ==> Figure C-1	
E
134	95-104	Annex D		D.0.1 ==> D.1,  D.0.2 ==> D.2,  D.0.3 ==> D.3
D.0.4 ==> D.4,  D.0.5 ==> D.5,  D.0.6 ==> D.6
D.0.7 ==> D.7,  D.0.8 ==> D.8,  D.0.9 ==> D.9 	
E
135	95	D.0	Line 1	The ITU-T Rec. H.262 | ISO/IEC 13818-2 Systems ==>
The ITU-T Rec. H.222.0 | ISO/IEC 13818-1 Systems	
E
136	96	D.0.1	Last para.
Line 4	this International Standard ==> this Specification	
E
137	97	D.0.2	1st para. Line 7	this International Standard ==> this Specification	
E
138	97	D.0.2	1st para. Line 8	as the System_Clock_Frequency ==> 
as the System_Clock_Frequency in clauses 2.4.2.1 and 2.5.2.1	
E
139	97	D.0.2	2nd para. Line 3	44,100  ==>  44 100	
E
140	98	D.0.2	2nd para. Lines 5-6	this International Standard ==> this Specification	
E
141	98	D.0.3	1st para. Line 3	27,000,000  ==>  27 000 000	
E
142	98	D.0.3	2nd last line	SCR_base ==> system_clock_reference_base field	
E
143	101	D.0.4	2nd para. 2nd last line	this International Standard ==> this Specification	
E
144	102	D.0.6	1st para. Line 4	this International Standard ==> this Specification	
E
145	112	H.0	1st para. Line 2	this International Standard ==> this Specification	

Annex 1 to AVC-688

To:	mpeg_sys@eikona.eng.monash.edu.au
Title:	PTS/DTS Confusion: New text
Purpose:	Discussion
Author:	Mike Nilsson, BT Labs
Date:	1 August 1994

 Introduction
This contribution contains new text that makes careful and minimal use of the term access unit. It is suggested that it is best to define the term access unit as early as possible in the text and then simply use it later, rather than trying to define its meaning every time it is mentioned. The text is given for both interpretations of where an access unit commences as far as time coding of timestamps is concerned.

ITU-T Rec. H.222.0 | ISO/IEC 13818 multiplexed Transport Stream

A Transport Stream consists of one or more programs each containing one or more elementary streams and other streams multiplexed together. Each elementary stream consists of the coded representation of presentation units. The presentation unit for a video elementary stream is a picture. The presentation unit for an audio elementary stream is the set of samples that corresponds to samples from an audio frame: an audio frame is defined in ISO/IEC 13818-3 and ISO/IEC 11172-3.

2.4.2 Transport Stream system target decoder

The term access unit is defined as follows. For video elementary streams, an access unit is the same as picture data defined in subclause C.5. of annex C of ITU-T Rec. H.262 | ISO/IEC 13818-2 for streams of stream type 2 and in subclause C.1.4  of ISO/IEC 11172-2 for streams of stream type 1. For audio elementary streams, an access unit is defined as an audio frame (see ISO/IEC 13818-3 and ISO/IEC 11172-3). The definition of access unit for other streams is outside the scope of the Recommendation | International Standard.

2.4.2.3 Buffering

For each elementary stream buffer, Bn, all the data for the access unit that has been in the buffer longest, An(j), is removed instantaneously at its decoding time tdn(j).

The decoding time tdn(j) is specified in the DTS field. If a DTS is not available, but a PTS is present, then tdn(j) is equal to tpn(j). When PTS and DTS are not present, the decoding time is derived from information in the elementary stream. In the case that stream type equals 2, the decoding time shall be derived from the time tn defined in subclauses C.9 to C.11 of annex C of ITU-T Rec. H.262 | ISO/IEC 13818-2, and in the case that stream type equals 1, the decoding time shall be derived from the time tn defined in subclause C.1.4 of annex C of ISO/IEC 11172-2. In the case that stream type equals 3 or 4, the decoding time shall be derived from information in the audio stream (see ISO/IEC 13818-3 and ISO/IEC 11172-3). 

In addition to the above, all PES packet headers that are stored immediately before, or embedded within, an access unit are removed at the same time as that access unit. As the data is removed, it is instantaneously decoded to a presentation unit.

Decoding

[Note that presentation units are reordered and not access units, as reordering is performed after decoding.]

Elementary streams buffered in B1 through Bn are decoded instantaneously by decoders D1 through Dn and may be delayed in reorder buffers O1 through On before being presented to the viewer at the output of the T-STD. Reorder buffers are used only in the case of a video elementary stream when some presentation units are not decoded in presentation order. These presentation units will need to be reordered before presentation. In particular, if Pn(k) is an I-picture or a P-picture decoded before one or more B-pictures, then it must be delayed in the reorder buffer, On, of the T-STD before being presented. Any picture previously stored in On is presented before the current picture can be stored. Pn(k) should be delayed until the next I-picture or P-picture is decoded. While it is stored in the reorder buffer, the subsequent B-pictures are decoded and presented.

The time at which a presentation unit Pn(k) is presented to the viewer is tpn(k). For presentation units that do not require reordering delay, tpn(k) is equal to tdn(j) since data are decoded instantaneously; this is the case, for example, for B-frames. For presentation units that are delayed tpn(k) and tdn(j) differ by the time that Pn(k) is delayed in the reorder buffer, which is a multiple of the nominal field period. Care should be taken to use adequate re-ordering delay from the beginning of video elementary streams to meet the requirements of the entire stream. For example, a stream which initially has only I- and P-pictures but later includes B-pictures should include re-ordering delay starting at the beginning of the stream.

Part 2 of this Recommendation | International Standard explains reordering of video pictures in greater detail. 

[Note, timestamps indicate the actual rather than the intended time of an event in the STD.]

PTS (presentation_time_stamp) -- The PTS  is a 33-bit number coded in three separate fields. It indicates the time of presentation, tpn(k), in the system target decoder of a presentation unit k of elementary stream n. The value of PTS is specified in units of the system clock frequency divided by 300.  The presentation time is derived from the PTS according to equation 2-10.

Pn(k) is the presentation unit corresponding to the first access unit that commences in the packet data. [For the purpose of this paragraph, an access unit is defined to commence in the packet data if the first byte of the access unit is contained in the packet data.] or [For the purpose of this paragraph, an audio access unit is defined to commence in the packet data if the first byte of the audio access unit is contained in the packet data, and a video access unit is defined to commence in the packet data if the first byte of the picture start code in the video access unit is contained in the packet data. Picture start code is defined in ITU-T Rec. H.262 | ISO/IEC 13818-2 and ISO/IEC 11172-2.]

[The paragraph beginning 'For I/P pictures ...' is partly a repeat of definitions in the STD and partly unclear]

DTS (decoding_time_stamp) -- The DTS is a 33-bit number coded in three separate fields. It indicates the time of decoding, tdn(j), in the system target decoder of a presentation unit j of elementary stream n. The value of DTS is specified in units of the system clock frequency divided by 300.  The decoding time is derived from the DTS according to equation 2-11.

tdn(j) is the decoding time for presentation unit Pn(j).

Pn(j) is the presentation unit corresponding to the first coded presentation unit that commences in the packet data. [For the purpose of this paragraph, an access unit is defined to commence in the packet data if the first byte of the access unit is contained in the packet data.] or [For the purpose of this paragraph, an audio access unit is defined to commence in the packet data if the first byte of the audio access unit is contained in the packet data, and a video access unit is defined to commence in the packet data if the first byte of the picture start code in the video access unit is contained in the packet data. Picture start code is defined in ITU-T Rec. H.262 | ISO/IEC 13818-2 and ISO/IEC 11172-2.]

In the case of hierarchical encoding, the associated DTSs shall be identical for the corresponding presentation units throughout all hierarchical layers. Refer to clause 2.7.6 on page 72.

2.7.6 Conditional coding of timestamps

For each elementary stream of a Program Stream or Transport Stream, the presentation timestamp (PTS) shall be encoded in the PES packet in which the first access unit of that elementary stream commences. A PTS shall only be present in a PES packet header if an access unit commences in the packet data of that PES packet. The definition of whether an access unit commences in a PES packet is [given in section xxx] or [repeat that chunk of text here]

A DTS shall only be present in a PES packet header if a PTS is present in the packet header and the decoding time differs from the presentation time.

[The unintelligible text about decoding discontinuities present in this section needs attention.]

END

Annex 2 to AVC-688

To:	mpeg_sys@video.eng.monash.edu.au
Title:	Discontinuities
Purpose:	Discussion
Author:	Mike Nilsson, BT Labs
Date:	5 Augsut 1994

Dear MPEG (compliance) members,

I've been looking at the discontinuity indicator and related issues. It seems to me that the text in the DIS is not quite in agreement with the text in the compliance document. This may be due to hurried typing of the compliance document or there may be a problem in the DIS.

To try to clarify the situation, I have created the pseudo-code below which combines compliance tests for the discontinuity bit and the continuity counter. Can an expert in this area check it? The production of pseudo-code like this is in line with the philosophy that pseudo-code is a good way to describe bitstream verification tests and its generation may reveal inadequacies in the DIS.

discontinuity_test(bitstream, PID_under_test)
{
  discontinuity_state = false
  discontinuity_length = 0
  pcrs_found = 0
  discontinuity_of_cc_count = 0  /* cc = continuity counter */

  Loop for each transport packet with PID_under_test, or new PID if updated in PMT
  {
    if (discontinuity_indictator == 1)
    {
      discontinuity_state = true
      discontinuity_length++
      if discontinuity_length >= 2 and not PCR_PID then INVALID BITSTREAM
    }
    else
    {
      if PCR_PID and pcrs_found==0 then INVALID BITSTREAM
      discontinuity_state = false
      discontinuity_length = 0
      discontinuity_of_cc_count = 0
      pcrs_found = 0
    }

    if PCR_PID and PCR_flag==1 and discontinuity_state==true
    {
      pcrs_found++
      This PCR may be a sample of a new time base
    }

    if discontinuity_state==true
    {
      if (cc == previous_cc) and payload present then duplicate packet
      if (cc != previous_cc) and ((cc+1)%16 != previous_cc) and payload present
      {
        discontinuity_of_cc_count++
        if discontinuity_of_cc_count > 1 then INVALID_BITSTREAM
        if elementary_stream then first byte of that data is an access point
        if PSI packet
        {
          version number discontinuity allowed
          First section shall have length 13
        }
      }
    }
    else  /* Normal cc check */
    {
      if (cc == previous_cc) and payload present then duplicate packet
      if (cc != previous_cc) and no payload present then INVALID BITSTREAM
      if (cc != previous_cc) and ((cc+1)%16 != previous_cc) and payload present
          then INVALID BITSTREAM
    }
  }
}

There are some things that are not quite clear, can someone help?

1) The DIS is not clear whether the discontinuity state applies to one PID at a time or to a program at a time. The compliance document seems to suggest it applies to each PID independently, and is what I have assumed in the code.

2) The DIS is not clear whether the number of PCRs allowed within a discontinuity state for PCR PIDs is limited to one, that is if pcrs_found >= 1 is invalid, whereas the compliance document is quite clear that this restriction exists.

3) In the DIS, for PSI information after a continuity counter discontinuity, after coding the 'short 13 byte section', it states 'This shall be followed by ...'. When shall this be followed? In the same transport packet? or the next transport packet of that PID which may occur at some indefinite time in the future?

4) Concerning the T-STD, how is the time of arrival of bytes between the last byte of one PCR and the last byte of the next PCR defined, when a discontinuity exists between the PCRs? Normally linear interpolation is done, but that is clearly inappropriate here.

5) How often can PCRs be discontinuous? It seems possible to have a transport stream with the discontinuity bit set in all transport packets that carry a PCR, and therefore to have each PCR as a sample of a different clock. This would prevent clock regeneration, prevent a test being done on a stored bitstream for the frequency of coding PCRs, and prevent testing for compliance to the jitter limits in the RTI. Although this is an extreme case, there is a continuous range of possible bitstreams between this and a stream with no discontinuities, so what can the decoder maker rely on when doing his design? A constraint saying something like no two consecutive PCRs can be discontinuous would make the problem go away.

6) Is the decoding discontinuity referred to in section 2.7.6 related to the discontinuity indicator? This paragraph seems a bit circular: tdn(j) is either explicitly defined by a PTS or DTS, or is calculated using the picture period (for example) and the previous value. The calculated value can not be out of range, and in the other case the time stamp is coded anyway. Help.

I hope that some can help to clarify the situation for me.

Have a good weekend!

Mike

Annex 3 to AVC-688

To:	mpeg_sys@eikona.eng.monash.edu.au
Title:	PTS/DTS Confusion
Purpose:	Discussion
Author:	Mike Nilsson, BT Labs; Peter Sarginson, BBC Research and Development
Date:	27 July 1994

 Introduction
This contribution is about a change of text that was made during the Paris meeting concerning the definition of which data timestamps relate to. This was first noticed by Mike Perkins.

 History
The coding of picture start codes, group of pictures start codes and sequence start codes, as well as the coding of audio access unit headers, is asynchronous to the creation of packets in MPEG1 and PES packets in MPEG2. Consequently, a relationship between a timestamp in the PES layer and a corresponding  entity in the elementary stream must be defined.

At one point in the development of MPEG1, a packet consisted of all the data for an integral number of presentation units; the timestamp definition was easy: it applied to the first or only presentation unit in the packet. Packets, containing data to be presented at about the same time, from different elementary streams were 'packed' together into packs. This allowed most applications to ignore the timestamps and achieve synchronisation implicitly from the way the data was packed. This unnecessary constraint on the formation of packets was eventually removed, and the current problem arose.

The solution, at least in principle, was simple: timestamps present in a packet header would refer to the first picture that started in the packet. Although the eventual definition in MPEG1 is far from well written, mostly due to the unnecessary insistence on using the words 'access unit', it was clear at the time that in this context pictures began with picture start codes.

 Problems with the MPEG1 definition
The main problem with the MPEG1 definition is that it has two different interpretations of an access unit. In the case of the application of timestamps to elementary stream data, a video access unit starts with a picture start code, and sequence and GOP data are irrelevant; while in the STD definition, sequence and GOP data can not be ignored, and there is little choice but to add them to the start of the access unit as defined above.

This is purely a matter of documentation and should not pose enough problems to enforce a change of definition.

There is another problem related to the random access indicator. This definition currently seems to suggest that the bit can be set only if a PTS and a sequence header are present in the next PES packet. Clearly this, together with the MPEG1 definition of where timestamps are, would prevent otherwise acceptable random access points from being identified.

However, the semantic definition and constraints on the random access indicator are themselves poorly written, and should be addressed as part of the same debate. This is discussed in more detail below.

 Problems with the Paris definition
The main problem with this approach is the almost unlimited number of bytes that may occur between the sequence start code and the picture start code: the amount of user data that may be present here is constrained only by the video VBV.

Consequently, this complicates the parser required for establishing the connection between timestamps and pictures.  In the MPEG1 approach, the parser only needs to look for picture start codes.  In the Paris approach, the parser needs to be aware of sequence, gop and picture start codes, and the parser needs to have memory.

It is possible, for example, for a sequence start code to precede the start of a timestamp-bearing PES header, while the picture start code of the immediately following picture is entirely contained in the portion of the bitstream that follows the PES header.  The parser would have to know to NOT apply the timestamps to this picture, but, instead, to apply them to the next picture in the bitstream.

 The random access indicator bit
As mentioned above, the definition of the random access indicator is quite seriously ill. For example, 'When set to '1', it indicates that the next PES packet of the same PID shall contain a PTS field ... ': PES packets do not have PID. More importantly, it does not specify that the PTS must be the PTS for the first picture after the sequence header: it may be the PTS for the last picture of the previous 'segment' of video. Also, there is no guarantee that a PCR is present, even if a discontinuity has just occurred.

The following is alternative text for what the current definition states, with the addition of the words 'or a subsequent', to allow for the MPEG1 definition of the location of timestamps, and with the fix to ensure the desired PTS is present.

The random_access_indicator is a 1 bit field that indicates the current and subsequent transport packets with the same PID, or the updated PID if modified by program map table information, contain some information to aid random access at this point. Specifically, when the bit is set to '1':

The next PES packet to start in the payload of transport packets with the current PID, or the updated PID if modified by program map table information, shall contain the first byte of a video sequence header if the PES stream type is 1 or 2 (video) and shall contain the first byte of an audio frame if the PES stream type is 3 or 4 (audio). In addition, in these cases, a presentation timestamp will be present in this or a subsequent PES packet for the first picture following the sequence header or for the audio frame.

When the current PID is equal to the PCR_PID, the PCR_flag shall be set to '1'.

In a program with one video and one audio stream, where the video stream carries the PCRs, a random access point in the audio will guarantee no more than a timestamp and an audio header: the video sequence header could be anywhere, as could the PCR's and the relevant PSI information. Although it may be considered that this definition allows the bit to be set too freely or frequently, discussion of this is outside the scope of this contribution.

 Conclusion
An editorial change was made during the Paris meeting that resulted in a normative change to the use of timestamps. This was compounded by poor definitions in the original text, originating from MPEG1.

This contribution has clarified the intention of the MPEG1 text, and described some problems with the Paris version.

Modified text for the semantic definition of the random access indicator has been given so that this bit can be used as flexibly if it is decided to revert back to the MPEG1 definition as it can with the Paris definition.

MPEG should decide which of these two definitions to include in the IS. The definition in the DIS is most certainly not broken, and can not be changed on the these grounds. However, if it does not state what is thought to have been the group's agreement, then it should be changed back to the MPEG1 definition.

It is hoped that this contribution will help MPEG to make progress on this issue.

END

Annex 4 to AVC-688

ITU-T SG15 Experts Group	ISO/IEC JTC1/SC29/WG11	
TD No.7 rev (Grimstad)	MPEG94/262	
July 18, 1994	July 18 1994	

Source:	ITU-T SG15 Experts Group for Video Coding and Systems in ATM and Other Network Environments
Title:	Support for ITU-T Control and Indication Signals
Purpose:	Discussion/Proposal
Relevant sub-group: Systems

1.	Background

To accommodate the requirements of audiovisual communications systems in ATM environments (ITU-T Rec. H.32X), ITU-T Rec. H.222.0 | ISO/IEC 13818-1 and ITU-T Rec. H.222.1 should provide the following in addition to the generic functionalities already covered by ITU-T Rec. H.222.0 | ISO/IEC 13818-1:

•	provision of a control channel for audiovisual communication control,
•	use of audio and video coding algorithms other than ISO/IEC 13818 and ISO/IEC 11172,
•	inclusion of control and indication signals synchronized with the presentation of audiovisual frames,
•	change of audio coding and other communication modes during communication.

This document discusses and proposes necessary provisions in ITU-T H.222.0 | ISO/IEC 13818-1 to allow the above functions.

2.	Introduction

At the June 1994 Atlanta MPEG Systems meeting, a "stream type" was reserved in ISO/IEC 13838-1 table 2-35 (p. 56) for "ITU-T auxiliary data." Stream type value 0x09 identifies streams that carry control-type information such as ITU-T control and indication messages, closed-caption data, etc.  Stream_type values are used in the TS_program_map_section() and program_stream_map() to identify elementary stream types within Transport Stream and Program Stream PSI tables.

The execution or use of some ITU-T auxiliary information must be synchronized with the presentation of audiovisual data [1, 2, 3].  This contribution suggests that the ITU-T define syntax for ITU-T auxiliary information that uses the MPEG-2 PES Packet structure to achieve this synchronization.  A benefit of this approach is that it supports the transmission of ITU-T auxiliary information in Program Streams as well as in Transport Steams.

We propose that ISO/IEC and ITU-T allocate one stream_id in ITU-T H.222.0 | ISO/IEC 13818-1 table 2-18 (p. 30) for ITU-T auxiliary information: the suggested codeword is the currently-reserved value "1111 0100".  This table entry should include a note that refers to ITU H.222.1, will define the syntax of elementary streams with this stream_id value.  Suggested text for the note is, "This stream_id only is allowed in streams with stream_type = 0x09 (table 2-35)."

It would be possible to carry ITU-T auxiliary information in elementary streams that use stream_id values of 1011 1101 or 1011 1111 (private_stream_1 or private_stream_2), but the use of a separate stream_id value helps ensure that decoders recognize the type of such elementary streams.  Further, the availability of a unique stream_id value for ITU-T auxiliary data allows decoders to distinguish between elementary streams that carry true control/indication information from ITU-T auxiliary streams that carry ITU-T audiovisual data such as H.261 video or G.711 audio.  To enable the transmission of ITU-T encoded audio and video data in elementary streams with stream_type = 0x09, we recommend that:

•	the description of stream_id 110x xxxx be changed to read, "ISO/IEC 13818-3 or ISO/IEC 11172-3 or ITU-T audio stream number x xxxx"
•	the description of stream_id 1110 xxxx be changed to read, "ITU-T H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 or ITU-T video stream number xxxx"

3.	ITU-T Auxiliary Data Syntax

We propose that H.222.1 define ITU-T auxiliary elementary streams to follow the same PES packet format as private_stream_1.  This syntax allows the execution of ITU-T control and indication messages to be synchronized with the presentation of audiovisual data, by use of the PTS and DTS fields.  We recommend that in ITU-T auxiliary elementary streams, the following fields in the PES packet header be set to fixed values:

•	data_alignment = 0
•	copyright = 0
•	original_or_copy = 1
•	DSM_trick_mode = 0
•	additional_copyright_info = 0

The syntax and semantics for the PES packet payloads in an ITU-T auxiliary elementary stream will be determined by the elementary stream descriptors used to describe the elementary stream.  (Section 2.6 of ISO/IEC 13818-1 explains elementary stream descriptors.) ITU-T H.222.1 should define descriptors for ITU-T auxiliary elementary streams.  H.222.1-defined descriptors will use "user private" descriptor tag values (ISO/IEC 13818-1 table 2-39).  These descriptors will not be used in the ISO/IEC 13818-1 program_stream_map() or TS_program_map_section() to describe entire programs, but only will be used to describe elementary streams.

Benefits of this proposed syntax include:

•	minimal modifications are needed to the ITU-T H.222.0 | ISO/IEC 13818-1 DIS,
•	the existing PTS/DTS mechanism is used for synchronization of ITU-T auxiliary information with audiovisual data,
•	the format of auxiliary data as its own stream allows ITU-T auxiliary streams to be added and dropped from ITU-T H.222.0 | ISO/IEC 13818-1 programs easily, solely via entries in the TS_program_map_section() or program_stream_map(),
•	much of this syntax can be parsed in the same way as other components of ITU-T H.222.0 | ISO/IEC 13818-1 streams.

Drawbacks of this method include:

•	Possible inefficient use of bits to transmit auxiliary information.  However, H.222.1 could define "packed" formats that combine several control and indication messages within a single PES packet.

Although it is beyond the scope of this proposal to define the ITU-T auxiliary elementary stream descriptors and the syntax of ITU-T auxiliary elementary stream data, we feel that the adoption of the syntax presented above would allow decoders to know where within the ITU-T H.222.0 | ISO/IEC 13818-1 syntax to look for auxiliary information.

4.	Example of ITU-T Auxiliary Information

H.222.1 could define a video_control_descriptor, following the syntax of ITU-T H.222.0 | ISO/IEC 13818-1 section 2.6.  This descriptor, applied to an elementary stream, indicates that the elementary stream carries video display control signals.  An elementary stream referenced by this descriptor could carry directives such as "freeze_frame_release" in its PES packet payloads.  The time at which a directive should be implemented is carried in the PTS field of the header of the PES packet that carries the directive.

5.	Summary of Suggested Changes to DIS 13818-1

•	In table 2-35, the description corresponding to value 0x09 should read: "ITU-T auxiliary".
•	In table 2-18, stream_id value 1111 0100 should be allocated for ITU-T auxiliary data.  A note attached to this table entry should read, "This stream_id only is allowed in streams with stream_type = 0x09 (table 2-35)."
•	In table 2-18, the description of stream_id 110x xxxx be changed to read, "ISO/IEC 13818-3 or ISO/IEC 11172-3 or ITU-T audio stream number x xxxx"
•	In table 2-18, the description of stream_id 1110 xxxx be changed to read, "ITU-T H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 or ITU-T video stream number xxxx"

6.	References

[1]	AVC-656 | MPEG94/214	Necessary provision for applying H.222.0 to the H.32X terminals (Japan)
[2]	AVC-668	Video conferencing Control and Indication signals for H.262 (AT&T)
[3]	AVC-665 | MPEG94/220	Closed caption in ITU-T H.262|ISO/IEC 13818-2 (Bellcore)

Annex 5 to AVC-688

                        PCR(i")                         i - i"
    tm(i) = ----------------------------  +  --------------------------  (2-4)
               system_clock_frequency              transport_rate(i)

where
                          (i' - i") X system_clock_frequency
      transport_rate(i) = ---------------------------------------        (2-5)
                                PCR(i') - PCR(i")
and
     i       is the index of any byte in the Transport Stream
     i"      is the index of the byte containing the last bit of the 
             program_clock_reference_base field of the program being decoded.
     i'      is the index of the byte containing the last bit of the following
             program_clock_reference_base field, of the program being decoded
     i" < i < i'
     PCR(i)  is the time encoded in the program_clock_reference_base and 
             program_clock_reference_extension fields at time index i.

Annex 6 to AVC-688

To:    		mpeg_sys@video.eng.monash.edu.au
Title: 		Decoding time
Purpose:  	Discussion
Author:   	Mike Nilsson, BT Labs
Date:  		3 August, 1994

This is continuing Ralf's discussion on decoding times.

The   paragraph  concerning  this  in  the   contribution 'PTS/DTS Confusion: New text' was intended to be the same as  that  in the DIS, but with the definition  of  access unit  removed from the paragraph. It did occur to me that something  was  missing  from that  text  concerning  the decoding  time of access units that did not  have  decode time stamps, and so the reference to tn appeared.

In  MPEG-1, it was quite easy to state the decoding  time for  access  units without timestamps: all pictures  were progressively scanned and were removed from  the  VBV  at fixed  regular intervals equal to the picture period.  In fact, I can't find any text in MPEG-1 that tells you  the decoding  time  of  an access unit without  a  decode  or presentation timestamp.

The  problem in MPEG-2 is that access units,  well  video ones,  are  not  removed from the VBV  at  fixed  regular intervals.  There are field pictures, frame pictures  and pictures with repeat first field. This is why a reference is  needed to the VBV text. But is it good enough to  say that  when  timestamps are not available  for  an  access unit, use some information in the elementary stream,  and for video streams you had better read about the VBV?

Pseudo-code  to  calculate or  specify  the  decode  time tdn(j) might look like this.

If DTS(j) exists
{
  tdn(j) found from the DTS equation 2-11
}
else
{
  if PTS(j) exists
  {
    tpn(j) found from PTS equation 2-10, tdn(j) = tpn(j)
  }
  else
  {
    tdn(j) = tdn(j-1) + something
  }
}

But what is the something? For audio and MPEG-1 video  it is constant and therefore easily specified. For MPEG-2 it depends  on the factors above, and needs a few  pages  of VBV  text to specify it. We obviously don't want to  copy that text, but can we make use of their terminology?

The  VBV  defines  tn  as the time when  the  n'th  coded picture is removed from the VBV.

Is  the value of 'something' in the above equal to  tn  - tn-1? If so, the code is complete:

    tdn(j) = tdn(j-1) + tn - tn-1

Any thoughts?

Mike Nilsson
BT Labs

Annex 7 to AVC-688

Proposed change to Table 2-17

	if (pack_header_field_flag == '1' ) {			
		marker_bit	1	bslbf	
		MPEG1_MPEG2_identifier	1	bslbf	
		original_stuff_length	6	uimsbf	
		pack_field_length	8	uimsbf	
		pack_header()			
	}			
	if(program_packet_sequence_counter_flag== '1'){			
		marker_bit	1	bslbf	
		program_packet_sequence_counter	7	uimsbf	
	}