- 1 -
19 June 1995, 16:00 Document AVC-800R
ITU Telecommunication Standardization Sector Document AVC-
800R
Study Group 15 18 May 1995
Experts Group for Video Coding and Systems
in ATM and Other Network Environments
Source: RAPPORTEUR (Sakae OKUBO)
Title: REPORT OF THE NINETEENTH EXPERTS GROUP MEETING IN
HANINGE (15-18 May 1995)
Purpose: Report
Status Confirmed by the participants
-----------------------
1. General
The nineteenth meeting of the Experts Group was held under
chairmanship of Rapporteur (Mr. Sakae Okubo) during 15-18 May
1995 in Telia Research, Haninge, Sweden, at the kind
invitation of Telia Research AB. At the start of the
meeting, Mr. Leif Bengtsson, Manager of Image Technology,
gave a welcoming address on behalf of the hosting
organization. A list of participants appear at the end of
this report.
It is noted that the discussion session for H.222.1, H.245,
H.321 & H.310, H.322, H.22Z, H.323 was co-chaired by
Rapporteur and each Editor; Mr. Stuart Dunstan, Mr. Mike
Nilsson, Mr. Hayder Radha, Mr. Geoff Morrison, Mr. Gary Thom,
Mr. Dale Skran.
In addition to the meeting sessions at large, we had three
small group discussions regarding network adaptation,
communication procedures and LAN matters in the Tuesday
evening, and two small group discussions regarding
communication procedures and LAN matters in the Wednesday
evening.
At the end of the sessions, Rapporteur thanked the hosting
organization for providing us excellent facilities and
services to support the meeting.
2. Documentation and tape demonstration (TD-2)
For this meeting, 57 AVC-numbered documents and 23 Temporary
documents have been made available as listed in Annex 1. On
Tuesday, 16 May, the following tape demonstration was given:
Organization Content Document
Telia Research Low-delay simulations for MPEG-2 ML video
at 1.5 Mbit/s -
KPN Research VADIS hardware processed pictures at 9
and 4.5 Mbit/s using AAL1 and TS -
AT&T Bell Labs Concealment of bit errors AVC-774
AT&T Bell Labs Error resilience at high packet loss
rates AVC-775
3. Review of the previous meetings
3.1 Experts Group January meeting in Kamifukuoka (AVC-743R)
Rapporteur drew attention of the members to several annexes
which contain major achievements at the previous meeting.
3.2 SG15 meeting in February (AVC-749, 750)
Rapporteur drew attention of the members to the items needing
action of this Experts Group.
3.3 LBC meeting in March
Rapporteur reported that the harmonization between H.245 and
H.246 was agreed at the LBC meeting in March and that we make
a single Recommendation H.245 regarding communication
procedures for packet based audiovisual communication
systems. The meeting appreciated the efforts of Mr. Mike
Nilsson and Mr. Keiichi Hibi.
3.4 SG13 Rapporteur meeting in May
Rapporteur summarized the outcome of the SG13 Rapporteur
meeting in the preceding week:
¥ the choice of AAL is left to the user,
¥ some functions which have been allocated to AAL CS can
be in the H.222.1 layer.
3.5 Meetings of related organizations
The outcome of the following meetings were briefly presented
by the members of this Experts Group:
¥ MPEG in March by Mr. Sakae Okubo
¥ SA&A in February and April by Mr. Jeff Lynch
¥ DAVIC in March and May by Mr. Olivier Poncin
3.6 List of open issues (AVC-752)
Rapporteur suggested to use AVC-752 as a check list for the
discussion at this meeting.
4. Common text Recommendations
4.1 Amendment and corrigendum
The meeting agreed from the ITU-T perspective on the
following amendments and corrigendum which were produced at
the MPEG meeting in March 1995 :
H.222.0|ISO/IEC 13818-1 Systems
¥ Amendment for format_identifier (AVC-759)
¥ Amendment for copyright_identifier (AVC-760)
H.262|ISO/IEC 13818-2 Video
¥ Amendment for copyright_identifier (AVC-761)
¥ Amendment for the 4:2:2 Profile (AVC-798)
¥ Corrigendum (AVC-762)
We submit white contributions after the MPEG meeting in July
for the consideration of the SG15 meeting in November.
4.2 Defect report
Members are requested to report their finding for corrections
to the publication version of H.222.0 and H.262 texts through
the reflector. We will make a list and input to the SG15
meeting in November according to the procedure defined in
Section 7.11 of Annex A to WTSC Recommendation A.23 "Guide
for ITU-T and ISO/IEC JTC1 Cooperation".
Rapporteur's note: - Chairman of SG15, Mr. Probst, agreed in
his letter to Rapporteur dated 12.5.95 that the Experts Group
act as Defect Reviewing Group for the two common text
Recommendations, pending the approval of SG15 in November
1995.
5. RTI and DSM-CC
5.1 Real Time Interface (AVC-756, 763, 777, 793)
The meeting first discussed whether RTI-LJ with t_jitter=25
microsecond be appropriate for our use in ATM audiovisual
communication terminals. We concluded that the current
specification is not useful for the applications in ATM
environments.
The next question was what t_jitter value is to be specified
for our purpose. A proposal of "RTI-NJ" with t_jitter=500
microsecond was presented in AVC-777. The underlying issues
are what is the jitter value at the input and how to cope
with this input jitter inside the terminal. The meeting
concluded that how to absorb the jitter incurred at the input
of the receiver should be left to implementation since it is
not relevant to interoperability. This conclusion will be
reflected in H.222.1 by qualitative description as part of
its functionality with a note containing some specific values
for information purpose.
The meeting further discussed the usefulness of generic
specifications of RTI to conclude that we support the
framework standard without specific values of t_jitter as
proposed in AVC-793 and this is appropriate for a common text
Recommendation (H.222.2).
Based on the above conclusion, the meeting decided to send a
correspondence to MPEG as in Annex 2 with an attachment of
proposed wording. Review of the attachment is requested by
the end of June for submission to MPEG.
5.2 DSM-CC (AVC-754, 755, 779, 783; ¤6.1.3/AVC-743R)
The meeting briefly discussed the relevance of DSM-CC to
H.245 (capability, C&I) whether they are duplicating or
compensating. In case of H.310 bi-directional terminals, use
of Q.2931 and H.245 is straightforward. In case of H.310
uni-directional terminals or H.310 bi-directional terminals
functioning as receive only terminals, the meeting recognized
that the two specifications may have some overlap and we need
synergy between them.
Mr. Mike Nilsson kindly volunteered to present Draft H.245 at
the MPEG DSM-CC Adhoc Group meeting which is held during 22-
25 May in Boston. The meeting appreciated this action
towards reaching the above mentioned synergy solution.
6. Network adaptation
6.1 H.222.1 functions
6.1.1 FEC (AVC-753, 765, 771, 773, 774; AVC-781)
The meeting discussed how FEC should be handled in the
audiovisual communication terminals for ATM environments;
whether they should be mandatory or optional for each of AAL1
and AAL5 solutions and where it should be allocated in the
protocol reference model. Choice of FEC parameters was also
considered.
Based on the network performance scenario (see ¤6.4.1 of this
report) and experimental results, we concluded as follows:
¥ The error resilience approach using the CRC32 error
detection is practical for the AAL5 solution while FEC is
required for the AAL1 solution.
¥ H.310 specifies that the use of FEC is optional.
¥ As to the FEC specification, RS(128,124) without
interleaving is adopted for harmonization with the J.82
solution. The FEC framing is through use of CSI for every
47 FEC frames (128 cells).
¥ This FEC without interleaving is to be defined as part of
AAL1 CS. We will send a correspondence to SG13 requesting
definition of this FEC as in Annex 3.
Information on the FEC characteristics is given in Annex 4.
6.1.2 Jitter due to FEC framing (AVC-766, 771)
AVC-766 and 771 discusses jitter due to FEC framing and its
relevance to PS/TS packet boundary and AAL-SDU. The meeting
appreciated the input and recognized that FEC framing can be
a source of jitter.
Some implementation examples for jitter removal inside the
receiver are shown in Annex 5 as information. Note that this
list is not exhaustive.
6.1.3 Extension to VBR (AVC-771, 794)
The meeting reviewed whether handling of PCBR (Piecewise
Constant Bit Rate) should be in H.222.1 at this stage. Since
we need more study to clarify the requirements and
characteristics of PCBR, we concluded not to include it in
the November version of H.222.1. This should be further
studied towards a next phase Recommendation or revision of
the first phase Recommendation.
6.1.4 Jitter removal (AVC-778)
AVC-778 presented a descriptor method for indicating which
parts of the data stream may be used for recovering the
Decoder System Clock. During the discussion, it was
clarified this descriptor has no relevance to the existing
system clock descriptor. The method was refined during the
meeting and contained in Annex 6. This proposal was agreed
for inclusion in H.222.1.
6.1.5 Conclusion of the network adaptation discussion
(TD-9)
The meeting asked Mr. Roel ter Horst to organize a small
group to draft the agreements on the network adaptation
issue. The approved report is contained in Annex 7.
6.2 AAL (AVC-794, 796)
Considering the two AAL solutions on the table for the CBR
coded MPEG stream, the meeting discussed what should be the
position of this Experts Group for AAL1 and AAL5. We
concluded to maintain the previous decision that H.222.1
define tools and that H.310 specifies the use of AAL1 and/or
AAL5 solutions for each of the terminal types.
Rapporteur raised a question that even the same AAL1 is
mentioned in SG9 and SG15, choice of CS functions has been
different, thus compatibility between the two systems may not
be obtained. The meeting agreed to seek a harmonized
solution with J.82 in H-series Recommendations.
AVC-796 pointed out necessity to define and describe the
selected option for jitter removal in terms of AAL5
convergence sublayer. It was a common understanding of the
meeting that the jitter removal is left to implementation
(see ¤5.1 of this report).
The meeting took note of the SG13 advice to study phase (or
clock) integrity when a cell loss has taken place. This
matter is yet to be considered.
6.3 Communication procedures (AVC-767, 769, 787; AVC-751,
788)
AVC-767 discussed allocation of audiovisual communication
procedure functions among H.222.1, H.245 and H.310. The
meeting supported to align the three Recommendations
according to the function partitioning described in ¤2 of
AVC-767.
All of the listed contributions addressed the choice of
channel for the logical channel signalling message. After
extensive discussion at the main meeting and small group
meetings organized by Mr. Stuart Dunstan, we reached a
conclusion to send the logical channel signalling message as
part of the H.245 messages. This is with a view to
harmonizing with the LBC protocol stack. Since the current
version of H.245 does not include SDLs such as in H.222.1,
they will be worked out before the submission of its SG15
white contribution. The meeting agreed to the SDL precedence
to description if discrepancy happens inside the
Recommendation.
AVC-789 proposed to define default logical channels and their
PIDs at the start of communication. The meeting accepted
this proposal considering that the propagation delay may not
allow quick start of a negotiated mode of communication.
6.4 Network aspects
6.4.1 Network performance (AVC-781)
AVC-781 provided an updated ATM network performance scenario
which incorporated SG13 advice and other information obtained
after the issue of AVC-635. The meeting confirmed to
continue the approach in the lack of definitive network
performance information.
During the discussion there was a suggestion that the "Best
Case" may mean an error free case, thus it should be reworded
as "Above Average Case". The SG13 Rapporteur meeting on
Q.6.1 in the previous week also suggested to list performance
according to the reference point in the table. The meeting
accepted these suggestions.
As to the particular performance values, the meeting decided
to send this update to SG13 for comments and seek their
advice on error patterns referring to the particular FEC
mentioned in ¤6.1.1 above.
6.4.2 Q.2931 signalling (AVC-780, 783; ¤10.2/AVC-743R)
AVC-780 and 783 raises a question whether B-HLI or B-LLI be
appropriate for the "Correlation ID". Mr. Tomoaki Tanaka
informally advised the meeting that SG11 would revisit the
issue at its meeting in February 1996. It was recognized
that we should review Annex 5 to AVC-743R according to the
current H.310 discussion and take necessary actions to SG11.
6.5 H.310 network adaptation protocol reference model (Annex
9 to AVC-743R)
Mr. Stuart Dunstan undertook to update the model according to
the achievements obtained at this meeting. This will be
submitted as a separate document AVC-801.
7. Draft Recommendations to be decided in November
7.1 Draft H.222.1
7.1.1 Text (AVC-744, 750, 752, 786, 787, 789)
After the meeting at large gave an overview to the available
materials, small groups coordinated by Mr. Stuart Dunstan
thoroughly discussed the open issues regarding H.222.1 as
well as H.245 and produced resolutions to each item. The
outcome is contained in Annex 8 with action items for the
white contribution. This was approved at the review session
which took place on the final day of the meeting. The text
will be completed by the end of June through correspondence.
It was clarified that though most of the communications will
use the acknowledged procedures, H.310 may specify the use of
unacknowledged procedure for some type of uni-directional
communications. In any case, H.222.1 defines the two
procedures as tools.
7.1.2 Error resilience (AVC-775)
AVC-775 proposes an error resilience method by use of H.262
Data Partitioning syntax in the environments where no
priority is provided. It was noted that the proposed
correction to H.262 had already been discussed and agreed at
the MPEG meeting in March 1995. The meeting agreed on
inclusion of the proposed text in H.222.1 except for the last
paragraph in AVC-775.
7.1.3 Timing recovery (AVC-778)
See ¤6.1.4 above.
7.1.4 Capability descriptor (AVC-788)
AVC-788 proposes to add a descriptor indicating a capability
set of the remote terminal to judge the acceptance of the
requested logical channel establishment. According to the
resolution to the logical signalling message issue (see ¤6.3
of this report), this addition is no more required.
7.2 Draft H.245
7.2.1 Harmonization with H.246 (AVC-751)
AVC-751 raised the need to harmonize H.245 and H.246 which
was agreed by the LBC group in March 1995. The meeting
confirmed that this Experts Group also support the
harmonization approach integrating the two into a single
Recommendation H.245.
7.2.2 Text (AVC-745, 750, 752, 772, 788, 790)
See ¤7.1.1 for the resolution to the H.245 open issues. The
text will be refined through correspondence.
Furthermore, the meeting agreed on the principle to make
H.245 generic so that various communication environments such
as ATM, GSTN, LAN can be covered by a single Recommendation .
It is anticipated that some additions may be needed for H.323
as its work progresses. This addition will be requested from
the October Experts Group meeting to the November SG15
meeting. Rapporteur will consult with TSB regarding the
acceptance of this procedure.
7.2.3 Jitter control (AVC-764)
AVC-764 proposes additional H.245 messages to assist the
encoder to control its coded data generation so that the
decoder buffer does not underflow nor overflow. The meeting
agreed on the inclusion of additional syntax and semantics in
H.245 as contained in Annex 9. During the discussion, some
concerns were expressed with potential problems involved in
the delayed feedback.
7.2.4 Multipoint video (AVC-776)
AVC-776 proposes additional specifications in H.222.0 and
H.245 which allow for simultaneous multiple video displays by
merging multiples streams at the MCU or decoder. Members are
requested to review this proposal by the next meeting.
7.2.5 Error free transfer protocol (AVC-791, TD-13)
AVC-791 raised a question regarding the possible use of SSCOP
in the error free transport of H.245 messages through an
H.222.1 logical channel. Mr. Keiichi Hibi clarified the
background for the choice of current protocol stack, also
referring to the SG8 view. The meeting confirmed to maintain
the current protocol stack as in Annex A to H.245,
concluding, however, that its content is more appropriately
to appear in H.222.1.
7.3 Draft H.321 (AVC-747, 750, 752, 772)
The meeting reviewed modifications which were made after the
Kamifukuoka meeting. Except for further editorial
improvements, the meeting recognized it necessary to define a
communication mode for supporting more than 64 kbit/s
communication (typically 2B communication) in a single VC for
the case of "H.321 - B-ISDN - H.321". There are two
possibilities that FAS/BAS being contained only in the first
timeslot or in every timeslot. Since its resolution needs
some more careful thought, it should be worked out through
correspondence by the time of white contribution submission.
The text will be completed by the end of June through
correspondence.
7.4 Draft H.322 (AVC-748, 750, 752, 772)
Document AVC-748 (version dated May 1995) was presented by
the H.322 editor (Mr. Geoff Morrison). The main body of this
document was a revised version of the Draft Recommendation
H.322. The changes since the version produced at the
Kamifukokua Experts group meeting in January 1995 were to
address the comments from the SG15 WP1 meeting in February.
The first part of AVC-748 listed these comments (also
appearing in AVC-750 sourced by the Rapporteur) and
summarised the updates made by the editor in response.
Document AVC-772, section 4 contained three comments from
AT&T concerning the Kamifukokua draft and two were still
relevant to the more recent version. The meeting accepted
the intentions behind these two and the editor agreed to
formulate and add clarifying text concerning:
i) the H.322 gateway
ii) the underlying requirement of H.322 that the ISDN
clock is somehow conveyed to the H.322 terminals.
The clock issue prompted further discussion during which
doubts were expressed whether the FDDI LANs listed as
examples in the Draft Recommendation H.322 really are
suitable for use with it. The editor proposed to remove them
on the basis that it would be a serious error to include them
if they are technically unsuitable whereas it would only be
unfortunate if they were not listed in the examples despite
being suitable. Any of them could be reinserted if evidence
of their suitability was presented before the cut-off date
for preparing the version for the next WP1 meeting (see
¤7.5). The meeting agreed to this.
It was questioned whether further specification was necessary
to ensure terminals on the same LAN but from different
manufacturers would interwork. The editor remarked that this
would depend on the specific LAN. In the case of IEEE 802.9a
the specification is quite complete and there is likely
little possibility of open choices leading to
incompatibility. The meeting expressed no enthusiasm for the
ITU-T to examine other LANs and produce further individual
specifications where they might be found necessary.
The text will be completed by the end of June through
correspondence.
7.5 Refinement through correspondence
The meeting decided the following work schedule for the
submission of white contributions towards the "decision" at
the SG15 meeting in November 1995:
¥ Distribution of an updated draft by Editor by 7 June
¥ Comments to the draft by 21 June
¥ Second update by Editor by 30 June
The following members volunteered to review the updated
draft:
H.222.1 Yuichiro Nakaya (Hitachi), Barry Haskell (AT&T),
Roel terHorst (KPN Research)
H.245 Keiichi Hibi (Sharp), Jeff Lynch (IBM)
H.321 Tomoaki Tanaka (NTT), Geoff Morrison (BT)
H.322 Toshihisa Nakai (Oki), Dale Skran (AT&T)
Comments of these members and any other contributors as well
as responses should be posted at the AVC reflector
(sg15.avc@research.ptt.nl) for open discussion. Comments to
Draft H.245 should also be posted at the LBC reflector
(sg15.lbc@research.ptt.nl) for review of the LBC members.
8. Draft Recommendations to be determined in November
8.1 Draft H.310
8.1.1 B-ISDN and LAN terminals (AVC-770, 782, 784; TD-4)
The three contributions addressed audiovisual communication
terminals in B-ISDN and ATM LAN environments. There was some
discussion on difference between the two environments from
the terminal perspective. It was felt that they are the same
with respect to the user - network interface, but thorough
review (e.g. clocking aspect) is required to make a firm
conclusion.
The meeting recognized it necessary to make a neat ITU-T
framework for various type of conversational terminals,
particularly ATM LAN terminals. This framework should be
consistent with the approach to the H.320/H.322/H.323.
Efforts toward this direction are found in ¤8.1.3 of this
report.
8.1.2 Transfer rate (AVC-768)
AVC-768 discussed the representation of H.310 transfer rate
in terms of nx64 kbit/s and values of n for mandatory
support. Mr. Haskell raised a question whether the transfer
rate be related to the 27 MHz system time clock instead of
the 8 kHz based network clock. This needs further
consideration.
8.1.3 Text (AVC-746, 750, 752, 772)
New Editor of H.310, Mr. Hayder Radha, presented the updated
draft AVC-746, highlighting the modifications made after the
Kamifukuoka meeting, particularly Table 2 indicating
mandatory/optional capabilities. These are in response to
the WP1/15 and other comments. The Editor also proposed a
direction of H.310 based on his analysis of available
contributions and the above discussion (¤¤8.1.1, 8.1.2).
The meeting focused on discussing the scope of Recommendation
H.310 and agreed on the following points in defining Receive-
and-Send Terminal (RAST) types :
1) Interworking between H.310 RAST terminal types and
H.320/H.321 terminals is mandatory.
2) Interworking among the different H.310 RAST terminal
types is mandatory.
3) Recommendation H.310 will define two classes (or
profiles) of RAST terminal types:
(a) H.310 RAST terminal type for (Public) B-ISDN (RAST-
P), and
(b) H.310 Terminals for ATM LAN (RAST-L).
4) For interworking with H.320/H.321 terminals, both H.310
RAST-P and RAST-L terminal types will support the
following modes (mandatory):
(a) H.261 CIF/QCIF
(b) G.711 (G722 and G728 optional)
(c) H.221/H.242-H.230
(d) 1B, 2B and H0 transfer modes
(e) Two ATM VCs (for supporting the 2B communication
mode with H.320)
5) The support of ALL-1 (for the transfer of H.222.1 and
H.221 audiovisual signals over B-ISDN) is mandatory for
H.310 RAST-P terminals. The support of audiovisual data
over AAL5 by H.310 RAST-P terminals is optional.
6) Recommendation H.310 will define an AAL5 based H.310
RAST-L terminal type. The support of AAL1 by H.310 RAST-
L is optional.
7) A gateway (not inside the network but in the customer
premises) between a B-ISDN and an ATM LAN needed to
provide interworking functions between:
(a) ALL5 only RAST-L and RAST-P (which do not support
the optional AAL5 mode) terminals,
(b) AAL5 only RAST-L and AAL1 only RAST-L terminals, and
(c) AAL5 only RAST-L and H.321 terminals.
Similarly, a gateway between an N-ISDN and an ATM LAN is
needed to provide interworking functions between RAST-L
and H.320 terminals.
8) An H.310 RAST-P terminal, which supports the optional
ALL-5 mode, can communicate with an H.310 AAL5 only RAST-
L terminal using ALL-5.
9) H.310 RAST-P terminals (with and without the optional
AAL5 support) can be deployed on (or interface with) both
B-ISDN and ATM LANs. However, H.310 RAST-L terminals can
only interface with ATM LANs.
10) An AAL1 only H.310 RAST-L terminal is the same as a
RAST-P terminal (without the ALL-5 option). Therefore,
there is no need for Recommendation H.310 to define an
AAL1 only H.310 RAST-L terminal.
It was also agreed to complete the action items shown in
Annex 10 by the next AVC meeting in October.
8.2 Draft H.22Z (AVC-757, 752)
The meeting at large and small group meetings coordinated by
Editor (Mr. Dale Skran) discussed the guiding principles and
study items towards determination at the SG15 meeting in
November 1995. It was clarified that H.221 is not
appropriate for H.22Z purpose because it can not cope with
packet losses encountered in the non-guaranteed QoS LANs.
AVC-757, the draft H.22Z for Media Stream Synchronization and
Time Base Recovery on Non-guaranteed bandwidth LANs was
discussed. A number of decisions were taken:
1) FEC is not needed on the LAN, and will thus be terminated
at the H.323 gateway, and generated for outgoing (to
H.320 WAN) calls. A choice must be made between the
following options:
(a) Passing the FEC bits onto the LAN to help in video
rate matching
(b) Not passing the FEC bits onto the LAN, and requiring
the gateway to insert FEC bits.
2) FEC or CRCs are not needed in the H.22Z layer; these are
assumed to be provided on the LAN, with the assumption
that the LAN will not pass up errored packets. Thus,
errors will be rare, but when they do they will occur at
the packet level. Thus, H.22Z should specify a
packetization scheme for each media that is robust in the
face of packet loss.
3) The term "unreliable" protocol will be replaced with
"non-guaranteed delivery."
4) It was agreed to separate H.22Z into two layers [the
location of SAR remains to be determined, but it will
most probably be in layer (a)]:
(a) An upper layer that is concerned with jitter
removal, timing recovery, and media-specific
processing. A timestamp on this level will represent
the capture time.
(b) A lower layer that is concerned with QOS and media
stream association. The timestamp for this level is
based on when the packet is sent.
5) Media capture sequence numbers should increment per media
to aid in recovery processing.
6) It was agreed to consider whether a shorter sequence
number (8 bits?) would be sufficient.
7) There is no need for a CRC on the PDU header.
8) It was agreed to consider using a smaller time stamp than
RTP uses. As two timestamps are being used, this issue
can be rethought.
9) It was noted that for some LANs the LAN specific layer of
the GLI(General Lan Interface) must provide a method of
packetization. This will be an issue in the case of
passing T.120 or H.245 control over TCP/IP which does not
have packet boundaries.
10) It was suggested that H.22Z should be an RTP profile
and be RTP conformant. This was discussed at length, with
the conclusion that:
(a) H.22Z would continue to be RTP "inspired" but in PDU
structure would not follow RTP/RTCP, nor would there
be any attempt to be interoperable with RTP/RTCP.
(b) If at all possible, H.22Z would follow the media
packetization schemes of RTP, with the intent of both
taking advantage of the IETF work, and easing the
efforts of implementors who wish to produce systems
capable of both RTP and H.323. It was noted that
H.323 signaling will be highly incompatible with
RTCP.
11) It was suggested in AVC-799 that a "real-world"
profile be added to illustrate the use of a particular
LAN, with TCP/IP being suggested. This was agreed to in
the spirit of T.123, which provides such an example.
Whether this is informative or normative is for further
consideration, but it was noted that T.123 is making the
LAN stack normative, although it was initially
informative.
12) AVC-799 suggests that H.22Z specify an accuracy
requirement on the capture timestamp. This was
tentatively accepted, and input on the proper value is
solicited.
13) AVC-799 suggests that H.22Z specify how much
difference in audio/video capture timestamps may be
tolerated before recovery procedures are started. This
was tentatively accepted, and input on the proper value
is solicited. It was also agreed to consider how to
handle the situation where video arrives ahead of audio,
and not to simply prohibit this, as this cannot be
assured.
14) It was tentatively agreed to follow the H.261
packetization direction of RTP. The 512 bit frame
approach was rejected. Per frame packetization allows
error recovery only on the level of the entire frame, and
was rejected for this reason. An H.263 packetization for
the LAN must be developed.
15) As discussed under the H.323 topic, the scope of
H.22Z will include broadcast/multicast video on the LAN
in the context of the gateway operating as an MCU, and
also the case of the gateway operating as a simple video
broadcasting element. Thus, H.22Z must consider the
possible error recovery implications of the broadcast
scenario. The tentative direction is that even if video
and audio are unidirectional, the H.245 control link will
always connect the H.323 endpoint to the
gateway/gatekeeper, and thus the same error recovery
procedures for the duplex case will apply to the
broadcast case.
16) Audio silence packets will be supported/allowed as
an option.
The following issues related to H.22Z were raised:
1) It was suggested that T.125 should run over the T.123 LAN
stack as specified in T.123. The issue of whether and
how T.120 should be coordinated with the audio/video
requires further work. Two directions are:
(a) Run T.120 without any coordination with audio/video.
This has the problem that some features(e.g.
associating video with a cursor) may be impossible.
(b) Add a program id to the T.120 PDUs in some fashion,
as well as to the audio/video PDUs to support this
association.
2) Some important messages (e.g. freeze picture release) are
in the media stream on a non-guaranteed delivery PDU. It
is necessary to have some strategy (duplicated sending,
etc.) to assure delivery.
3) The issue of whether mixed audio/video packets would be
allowed was discussed. Two views were expressed:
(a) Audio and video should be kept in separate packets
to take advantage of QOS services offered by
different LANs.
(b) If audio is put into packets by itself, this results
in too many packets for some LANs. Specific
implementations were mentioned where mixing of audio
and video in a single packet was needed. It may be
desirable to make mixing of audio and video an
option, with its own capability.
4) Program or source identifiers may be important in the
context of video broadcast/multicast on the LAN since
point-to-point signaling may not be present. This
requires further consideration.
The editor requests that material intended for the July
edition be received by June 19, 1995 by posting to the H.323
reflector at h32z2-list@mtgbcs.att.com.
8.3 Draft H.323
The meeting at large and small group meetings coordinated by
Editor (Mr. Gary Thom) discussed the guiding principles and
study items towards determination at the SG15 meeting in
November 1995.
H.323 session began in the afternoon of Monday May 15. Five
documents were presented and discussed. In addition, a small
work group met during lunch breaks and on Tuesday and
Wednesday evening to further discuss the issues relating to
H.323. This report summarizes the result of these
discussions.
TD-5, an overview of AVC-758 was presented and there was some
discussion. In particular, the following points were raised:
1) H.263 SQCIF is optional but H.263 also specifies CIF and
QCIF picture formats. Are these not supported?
Resolution: These were not intentionally excluded and will
be added to the text.
2) FEC may not be required on the video since errored
packets will probably not be output from the network
interface for error correction to be performed.
Resolution: This will be handled in the H.22Z video packing
description. The current thinking is that FEC will not be
used with the video on the LAN.
3) A Gatekeeper entity will be required.
Resolution: The following description will be added.
1.x Gatekeeper
The Gatekeeper is a centralized conference manager that
provides access to the network for H.323 terminals and
gateway units. The gatekeeper is always required, even when
all terminals are on the same LAN. It is logically separate
from the terminal and the gateway, however, its physical
implementation may coexist with a terminal, gateway, server,
or other network entity. The Gatekeeper may be a single
entity or may be multiple entities that co-operate to
provide the gatekeeper services. The gatekeeper shall
provide the following services to H.323 terminals and
Gateway units on the LAN:
- Conference Authentication. Is a terminal on the WAN
permitted access to the LAN? Is a terminal permitted access
to a conference?
- Bandwidth Management. Static control of the number of
H.323 terminals permitted simultaneous access to the LAN.
- Connection Management. Management of ongoing
connections.
- Conference Management. Management of ongoing
conferences.
- Terminal to gatekeeper ÒQ.931 likeÓ call signalling.
- Network management information data structure.
- Directory services. E.164 to LAN address translation
list. Static mandatory, dynamic optional.
- Multicast address allocation.
4) H.323 intends to use H.245 for communications control.
This may require some changes to H.245. These changes
include:
- Addition of G.DSVD audio code point.
- Other changes
Resolution: Need contributions describing necessary changes
to H.245. Open
5) A procedure for limiting video bitrates is needed.
Resolution: Video, audio, and data bitrate will be
negotiated during the capability exchange. This will use the
H.245 Flow Control message.
6) A more detailed description of the Gatekeeper and the
gateway are required.
Resolution: New sections will be added to describe the
procedures involving the gatekeeper and the gateway.
AVC-792 was presented which described an implementation
example of video teleconferencing on non-guaranteed quality
of service LANs. This contribution was very useful in
presenting actual implementation issues. Some discussion
followed. It was confirmed that H.323 is not only targeted to
software implementation. Furthermore, questions were raised
regarding :
7) The effect of not having network timing at the end-
points. Can rate adaption be performed acceptably in the
gateway between the end-point on the LAN and an H.320
terminal on the WAN?
Resolution: It is thought that this will not be a problem.
AVC-799 was presented which raised many issues. This
contribution was very helpful in summarizing many issues
relating to Non-Guaranteed QoS LAN video telephone systems.
Some discussion followed. These issues are addressed below:
8) Scope
- Limit scope to LAN end-point to gateway and LAN
endpoint to LAN endpoint.
- Remove MCU-less multipoint.
Resolution: Scope of H.323 includes
- Point to point
- H.323 terminal to H.323 terminal
- H.323 terminal to gateway to H.320/H.321/H.322
terminal
- H.323 terminal to gateway to H.324 terminal
- H.323 terminal to gateway to gateway to H.323
terminal
- Multipoint
- H.231/H.243 MCU in gateway
- H.321/H.243 MCU on WAN
- without MCU (for future study)
- Broadcast/multicast
- Simplex Audio/video Broadcast/multicast, duplex
control
- Single source on LAN
- Single source on WAN
- Video Broadcast/multicast
- Single simultaneous source
- Source selected by MCU
- Audio mixing in MCU
- Video Broadcast/multicast
- Multiple simultaneous sources
- Sources controlled by MCU
-Audio mixing in MCU
9) Terminology
- packet network vs LAN
Resolution: Terminology will remain LAN because of possible
further confusion with X.25 packet networks, etc.
10) Speech Coder
- Make provision for G.DSVD.
Resolution: Provision has been made for the low complexity
G.DSVD audio algorithm.
11) Control Channel
Resolution: The following control/signalling paths need to
be described:
- H.323 terminal to H.323 terminal (end-to-end intra LAN)
- H.323 terminal to H.323 Gateway (end-to-gate intra LAN)
- H.323 terminal to H.323 Gatekeeper (end-to-manager
intra LAN)
- H.323 Gateway to H.323 Gatekeeper (gate-to-manager
intra LAN)
- H.323 Gatekeeper to H.323 Gatekeeper (manager-to-
manager intra LAN)
- H.323 terminal to WAN/GSTN terminal (end-to-end inter
LAN)
- H.323 terminal to H.231/H.242 MCU (multipoint
intra/inter LAN)
- H.323 MCU-less multipoint (multipoint intra LAN) (for
future study)
12) Call Control
Resolution: Use IEEE 802.9a tailored Q.931 carried in PDU
for signalling. H.323 perform call signalling with the
gatekeeper. The gatekeeper will also perform E.164 number to
LAN address translation.
13) Capability Negotiation
Resolution: Allow for intelligent gateways that perform cap
set conversion. This is particularly useful for audio
conversion. Allow gateway to pass-through non-standard cap
and com to endpoints. [[What about NS-Cap/Com destined for
gateway?]]
14) Audio/Video Synchronization
Resolution: Handled in H.22Z
15) Audio Quality
- Specify audio sample rate accuracy
- Specify echo return loss
- Specify nominal audio levels.
Resolution: Audio levels will be specified. Sample rate
accuracy may be specified. No decision on specifying echo
return.
16) Network Management
- Provide support for network management entities.
Resolution: Volunteers have agreed to provide text.
Possibly for an informative annex.
17) In-bound Call Routing
- How are inbound calls routed to an endpoint on the LAN?
- H.242 extensions?
Resolution: Inbound E.164 address to LAN address
translation will be performed in the Gatekeeper. We may need
to define extensions to H.242 to support transmission of
secondary addresses.
18) Authentication
- How do we provide LAN access authorization?
- H.242 extensions?
Resolution: Authentication will be performed in the
Gatekeeper. We may need to define extensions to H.242 to
support authentication.
19) Support for T.120 Data
- Use T.123.
- Association with audio and video.
- H.320 call is placed first.
- Inside/outside of H.22Z PDU?
Resolution: Handled in H.22Z.
20) Multiplexing Audio and Video
- Send audio and video in different packets.
Resolution: Handled in H.22Z.
21) Packetizing Video
- Use picture packets
- Fragmentation and reassembly
Resolution: Handled in H.22Z.
22) Echo on GSTN voice calls
- Echo issue for audio only terminal interoperability.
Resolution: Open
23) Specification using Real World Protocols
- Add profiles for TCP/IP and SPX/IPX
Resolution: Handled by H.22Z. Volunteers will provide text
for an informative annex.
AVC-797 suggests making an allowance for adopting future
multicast services for T.120 data.
24) Multicast for T.120
Resolution: Handled by H.22Z.
Other issues
25) Encryption
- H.223/H.224
Resolution: Use procedure described in H.324.
26) Mux/Demux terminology
- Change to Data formatter?
- Change to Packer/Depacker?
Resolution: Open.
27) Call establishment
- How is the terminal to terminal call established?
- Terminal procedures?
Resolution: Volunteers have agreed to write text for H.323
on these issues.
Members are requested to submit all comments, suggested text,
and recommendations by June 15, 1995 by correspondence using
the H.32Z e-mail reflector.
8.4 Refinement through correspondence
The texts of Draft H.310, H.22Z and H.323 are refined through
correspondence. The next edition will be issued early July
and at least one more edition will be issued by mid September
before the October meeting of the Experts Group. For Drafts
H.22Z and H.322, Mr. Joerg Ott provided a list of discussion
items as in Annex 11 for consideration of the members.
9. Work plan and work method
9.1 H.310 hardware trials
It is expected that the trials will be demonstrated at the
next meeting.
9.2 Second phase work and SG15 tasks during and beyond the
next study period (1997-2000)
Though we did not have time to discuss this topic at this
meeting, contributions are solicited toward the next meeting.
9.3 Interaction with other groups
In addition to the correspondence to SG13 (¤6.1.1) and MPEG
(¤5.1), the meeting decided to send the following
correspondence:
Destination Topic Cover sheet Attachment
The ATM Forum Status report Annex 12 AVC-800R
ETSI NA5 Network adaptation Annex 13 Annexes 7 and 3 to AVC-
800R
Furthermore we identified that the following work items of
SA&A/The ATM Forum are relevant to the work of this Experts
Group and we appreciate to be informed of the outcome:
¥ Network performance, CDV in particular,
¥ Definition of uni-directional communication terminals, and
¥ DSM-CC mapping to Q.2931.
9.4 Use of ftp server
The following ftp site has been installed for distributing
the AVC Experts Group documents, Draft Recommendations in
particular.
FTP site ftp.gctech.co.jp
Login name itu-t
Password sg15!avc
This ftp site can be accessed by anyone who is interested in
the AVC Experts Group activities.
10. Future meetings till November 1995
Meeting Date Place Note
20th Experts Group 24-27 October 1995 Yokosuka, Japan
Study Group 15 13 - 24 November 1995 Geneva
END
Annexes
Annex 1 Documents for the Haninge meeting
Annex 2 Correspondence to MPEG regarding RTI
Annex 3 Correspondence to Rapporteur for Q.6.1/13 in ITU-T
SG13
Annex 4 FEC characteristics
Annex 5 Possible implementations of FEC and system clock
recovery
Annex 6 Proposed timing descriptor
Annex 7 Report on network adaptation issues (AAL, FEC, CDV
compensation)
Annex 8 Resolutions on Draft H.222.1 and Draft H.245
Annex 9 Proposed addition to H.245 for jitter control (in ATM
Networks)
Annex 10 H.310 Action Items
Annex 11 Issues to be considered for H.22Z and H.323
Annex 12 Cover sheet for the correspondence to The ATM Forum
Annex 13 Cover sheet for the correspondence to ETSI NA5
Participants of the nineteenth meeting of the Experts
Group
for Video Coding and Systems in ATM and Other Network
Environments
held in Haninge, Sweden
Country Name Organization
Germany Mr. Joerg Ott Technische Universitaet Berlin
Australia Mr. Stuart Dunstan Siemens
Belgium Mr. Olivier Poncin BELGACOM
Korea Mr. Dong-Bum Jung ETRI
Mr. Jin-Soo Kim KAIST
USA Mr. Narjala Bhasker Intel
Mr. Chuck Bostrom CLI
Mr. Jay Gadre TELE-TV
Mr. Tom Geary Rockwell Telecommunications
Mr. Barry Haskell AT&T
Mr. George Kajos VideoServer
Mr. Jeffrey J. Lynch IBM
Mr. Hayder Radha AT&T
Mr. Mark Reid PictureTel
Mr. Lee Rogers IBM
Mr. Dale Skran AT&T
Mr. Gary A. Thom DIS
Mr. Qin-Fan Zhu Motorola
Finland Mr. Mika Grundstroem Tampere University of Technology
France Mr. Eric Gonfia CNET
Mr. Bruno Lozach LEP/Philips
Israel Mr. Aharon Segev ECI Telecom
Italy Mr. Maurizio Corasiniti Olivetti Ricerca
Japan Mr. Keiichi Hibi Sharp
Mr. Yuichiro Nakaya Hitachi
Mr. Sakae Okubo GCL
Mr. Tomoaki Tanaka NTT
Netherlands Mr. Roel ter Horst KPN Research
UK Mr. David Beaumont BT
Mr. Geoff Morrison BT
Mr. Mike Nilsson BT
Ms. Georgina Waide Cable & Wireless
Sweden Mr. Ola Andersson Telia Research
Mr. Gosta Leijonhufvud Ericsson
Mr. Per Tholin Telia Research
Ms. Christel Verreth Telia Research
Annex 1 to AVC-800R
Documents for the Haninge meeting
(15-18 May 1995)
Normal Documents
AVC
number Pur-pose
Title (Source)
AVC-743R R Report of the eighteenth Experts Group meeting in
Kamifukuoka (24-27 January 1995) (Rapporteur)
AVC-744 P Draft H.222.1 (Editor, Stuart Dunstan)
AVC-745 P Draft H.245 (Editor, Mike Nilsson)
AVC-746 P Draft H.310 (Editor, Hayder Radha)
AVC-747 P Draft H.321 (Editor, Hayder Radha)
AVC-748 P Draft H.322 (Editor, Geoff Morrison)
AVC-749 R Seventh progress report of the Experts Group for
Video Coding ad Systems in ATM and Other Network
environments (Rapporteur)
AVC-750 R Report of the Study Group 15 meeting held during
6-17 February 1995 (Rapporteur)
AVC-751 P Harmonization of H.245/H.246 (M. Nilsson)
AVC-752 A Open issues toward the Stockholm meeting
(Rapporteur)
AVC-753 A Liaison regarding need for FEC in H.222.1
(SA&A/The ATM Forum)
AVC-754 A Liaison regarding DSM-CC (SA&A/The ATM Forum)
AVC-755 R MPEG DSM-CC Meeting at Lausanne, Switzerland,
March 20-24, 1995 (C-C. Li)
AVC-756 R The MPEG Systems committee met in Lausanne,
Switzerland on March 20-24 (B. Haskell)
AVC-757 P Draft H.22Z (Editor, D. Skran)
AVC-758 P Draft H.323 (Editor, G. Thom)
AVC-759 P Draft Amendment 1 to ISO/IEC 13818-1 (MPEG
Systems)
AVC-760 P Draft Amendment 2 to ISO/IEC 13818-1 (MPEG
systems)
AVC-761 P Draft Amendment 1 to ISO/IEC 13818-2 (MPEG Video)
AVC-762 P Proposed corrigendum for ISO/IEC 13818-2 (MPEG
Video)
AVC-763 P Real-Time Interface specification for Low Jitter
Applications (MPEG Systems)
AVC-764 P Proposed Addition to H.245 for Jitter Control (in
ATM Networks) (AT&T)
AVC-765 I Binary primitive polynomial and generator
polynomial of Reed-Solomon code (Japan)
AVC-766 I Information on the TS packet jitter accompanied by
the FEC framing (Japan)
AVC-767 P Logical channel set-up procedure (Japan)
AVC-768 D Transfer rate for H.310 terminals (Japan)
AVC-769 D&P A case study for H.310 communication procedures
(Japan)
AVC-770 D Terminal specification for H.310 terminals (Japan)
AVC-771 P&D Protocol data unit in H.222.1 layer (Japan)
AVC-772 P Comments on H.310, H,321, H.245, and H.322 (AT&T)
AVC-773 P Proposal to remove FEC from H.222.1 (AT&T,
CableLabs, COMSAT, IBM, Telesis, Technologies
Laboratory)
AVC-774 I&P Concealment of Bit Errors in MPEG2 Video Decoder
(AT&T)
AVC-775 I&P Proposals for Error Resilience (AT&T)
AVC-776 I&P Proposals for Multipoint Video (AT&T)
AVC-777 I&P Real-Time Interface Specification for Normal
Jitter (AT&T)
AVC-778 D&I Descriptor Information to Aid Timing Recovery
(AT&T)
AVC-779 A Liaison regarding DSM-CC #2 (SA&A/The ATM Forum)
AVC-780 A Liaison regarding B-HLI (SA&A/The ATM Forum)
AVC-781 P Update of ATM performance assumptions (Experts
Group)
AVC-782 I Liaison regarding H.320 over AAL and AMS Phase 1
Work Scope (SA&A/The ATM Forum)
AVC-783 I A Summary of the April 1995 ATM Forum AMS Meeting
(IBM)
AVC-784 P An AAL5 only profile for H.32X (IBM)
AVC-785 Vacant
AVC-786 D&P List of open issues in H.222.1 (Siemens)
AVC-787 D&P Explanation of current H.222.1 acknowledged
signalling procedures (Siemens)
AVC-788 D&P Codepoint and parameter duplication in H.245 and
H.222.1 (Siemens)
AVC-789 D&P Proposed additions to H.222.1 acknowledged
signalling procedures (Siemens)
AVC-790 D&P Comments on Draft Rec. H.245 (Siemens)
AVC-791 D&P Protocols to support H.245 (Siemens)
AVC-792 I H.322/3 and an example software based multimedia
conferencing system (Siemens, Monash University)
AVC-793 P US National Body Position on MPEG-2 Real-Time
Interface (USA)
AVC-794 I&D Further clarification on an AAL model for real-
time VBR services (BT and KPN)
AVC-795 D&P Outstanding H.245 issues for ATM-based systems
(BT)
AVC-796 D AAL for MPEG-2 Transport Streams (France)
AVC-797 D&P Transmission of T.120 information in a LAN
environment (TU Berlin)
AVC-798 P Proposed Draft Amendment to ISO/IEC 13818-2 "4:2:2
Profile" (MPEG Requirements and Video Subgroups)
AVC-799 D Comments on Draft H.323 and H.22Z (Intel)
Abstract
AVC-743R Report
of the eighteenth Experts Group meeting in Kamifukuoka
(24-27 January 1995) (Rapporteur)
This document records the outcome of the Kamifukuoka meeting
held in january 1995, summarizing the discussion and
identifying action items.
AVC-744 Draft H.222.1 (Editor, Stuart Dunstan)
AVC-745 Draft H.245 (Editor, Mike Nilsson)
AVC-746 Draft H.310 (Editor, Hayder Radha)
AVC-747 Draft H.321 (Editor, Hayder Radha)
AVC-748 Draft H.322 (Editor, Geoff Morrison)
These documents contain updated drafts which reflect
discussion at the Kamifukuoka meeting, SG15 meeting in
February and subsequent correspondence. Open issues are
indicated in form of editor's comments.
AVC-749 Seventh progress report of the Experts Group for Video
Coding ad Systems in ATM and Other Network
environments (Rapporteur)
This document reports major achievements obtained at the
three meetings (Grimstad, Singapore, Kamifukuoka) towards
defining the following Recommendations of which we are in
charge; H.262, H.222.0, H.222.1, H.24X, H.32X, H.32Y,
H.32Z.1. It also lists particular items which need
consideration of Working Party 1/15.
AVC-750 Report of the Study Group 15 meeting held during 6-17
February 1995 (Rapporteur)
This document reports the outcome of Working Party 1/15
meeting (7-15 February) and Study Group 15 meeting (6, 16, 17
February), highlighting the issues of our concern; comments
on draft Recommendations, new Editors for H.22Z and H.32Z.2,
Recommendation numbers, alignment between H.24X and H.24P,
cooperation with MPEG, and other liaison statements.
AVC-751 Harmonisation of H.245/H.246 (M. Nilsson)
This contribution describes some of the differences in Drafts
H.245 and H.246 and suggests how they can be harmonised. The
following items are discussed; use of ASN.1, lower layer
protocols, mode indication, indication of capability, control
and indication, messages, document structure. It is
concluded that despite their different appearances, H.245 and
H.246 are very similar, thus it should be quite easy to
remove the minor differences procedures and messages and it
would be beneficial to do so, particularly compatibility at
the bit level can be achieved.
AVC-752 Open issues toward the Stockholm meeting (Rapporteur)
This document lists open issues which were identified after
the Kamifukuoka meeting. They are classified into categories
of "H.222.0", "Video coding and VBR", "Network adaptation",
"C&I and DSM-CC", "Draft H.222.1", "Draft H.24X (H.245)",
"Draft H.32X (H.310)", "Draft H.32Y (H.321)", "Draft H.32Z.1
(H.322)", "Draft H.32Z.2 (H.323), H.22Z" and "Second phase
work"
AVC-753 Liaison regarding need for FEC in H.222.1 (SA&A/The
ATM Forum)
This document requests that the Expert Group should
reconsider their decision to include FEC at the H.222.1
layer. Its ground is that since it appears impossible to
characterize the error behavior, especially with a single
model that is applicable to all transmission systems, the
best approach would be to detect for the presence of errors,
and then attempt to conceal their effects rather than
directly correct the bit errors.
AVC-754 Liaison regarding DSM-CC (SA&A/The ATM Forum)
This document describes the status of DSM-CC study in the
SA&A and lists several work items being considered for the
Phase 1 AMS Implementation Agreement or for future work
efforts. Interest is shown to the use of DSM-CC U-N messages
for the end-to-end session control and management.
AVC-755 MPEG DSM-CC Meeting at Lausanne, Switzerland, March
20-24, 1995 (C-C. Li)
This document summarizes the outcome of the DSM-CC Subgroup
meeting held on March 20-24, 1995, in Lausanne, addressing
those items which are either directly related to or may
potentially impact the work in ITU-T SG15. The group
produced the second Working Draft of ISO/IEC 13818-6 at the
end of the meeting. This document covers User-to-Network
operations, User-to-User operations, transport of DSM-CC
messages, Normal Play Time (NPT) and downloads.
AVC-756 The MPEG Systems committee met in Lausanne,
Switzerland on March 20-24 (B. Haskell)
This document reports the outcome of the MPEG Systems meeting
in Lausanne which produced the RTI-LJ specification allowing
up to 25 microseconds of jitter (50 us peak-to-peak),
regardless of bit rate. It is raised whether the ITU-T
should specify a Real Time Interface for "Normal Jitter"
(RTI-NJ), perhaps as part of H.222.1, to cater for the ATM
environments.
AVC-757 Draft H.22Z (Editor, D. Skran)
AVC-758 Draft H.323 (Editor, G. Thom)
These two documents provide initial drafts for the multimedia
multiplex & synchronization and the terminal on non-
guaranteed QoS LANS.
AVC-759 Draft Amendment 1 to ISO/IEC 13818-1 (MPEG Systems)
This document is for amending the procedures to register
format_identifier for the private data in H.222.0|ISO/IEC
1388-1 through Registration Authority.
AVC-760 Draft Amendment 2 to ISO/IEC 13818-1 (MPEG systems)
This document is for amending the procedures to register
copyright_identifier for the Systems stream of
H.222.0|ISO/IEC 1388-1 through Registration Authority.
AVC-761 Draft Amendment 1 to ISO/IEC 13818-2 (MPEG Video)
This document is for amending the procedures to register
copyright_identifier for the Video stream of H.262|ISO/IEC
1388-2 through Registration Authority.
AVC-762 Proposed corrigendum for ISO/IEC 13818-2 (MPEG Video)
This document lists several corrections to the final text of
H.262|ISO/IEC13818-2: 1) dual-prime vertical vector range, 2)
semantics for chromaticity parameters, 3) reservation for
signed_level == -2048, 4) first frame after any
sequence_header (), 5) frame_pred_frame_dct in progressive
frames, 6) VBV, 7) description for
profile_and_level_indication, 8) typos, 9) definition of
slice_picture_id, 10) semantics for copyright_identifier.
AVC-763 Real-Time Interface specification for Low Jitter
Applications (MPEG Systems)
This document is Committee Draft produced at the Lausanne
meeting which specifies t-jitter as 25 microsecond (jitter
shall be +/- 25 microsecond or less at the input of an RTI-LJ
decoder).
AVC-764 Proposed Addition to H.245 for Jitter Control (in ATM
Networks) (AT&T)
This document proposes additional H.245 messages for
transmitting the following information from the decoder; 1)
decoder buffer size available for jitter removal, 2) an
estimate of the received jitter at the decoder, and 3)
indication of frame skipping by the decoder. This is to
assist the encoder to control its coded data generation so
that the decoder buffer does not underflow nor overflow.
AVC-765 Binary primitive polynomial and generator polynomial
of Reed-Solomon code (Japan)
This document summarizes the binary primitive polynomial and
the generator polynomials of RS codes which are used in
existing standards or applications. It is suggested that
either primitive polynomial of X8+X4+X3+X2+1 or X8+X7+X2+X+1
is appropriate for H.222.1 and the choice of generator
polynomial affects hardware complexity.
AVC-766 Information on the TS packet jitter accompanied by the
FEC framing (Japan)
This document analyzes the TS packet jitter due to TS packet
mapping on FEC frame and FEC frame mapping on AAL-SDU. The
former is one TS packet period time (250 us at 6 Mbit/s)
without alignment while the latter is one cell period time
(70 us at 6 Mbit/s) without alignment. If the alignment is
made between FEC frame with AAL-SDU, efficiency decreases due
to padding.
AVC-767 Logical channel set-up procedure (Japan)
This document first discusses allocation of functions to
higher layer modules (H.222.1, H.245 and H.310) to clarify
the protocol configuration for logical channel set-up. Then
it proposes to use both H.222.1 SE and H.245 procedures,
because they are considered to have different
functionalities, and application dependent control should be
managed by the Call Management (H.310) module.
AVC-768 Transfer rate for H.310 terminals (Japan)
This document reviews some methods to reproduce multiple rate
clocks in a step of 64 kHz in the receiving terminal and
concludes that though the current representation of the
transfer rate is appropriate, further study is needed for
whether any value of n be mandatorily supported by the H.310
terminal. It is also suggested to study the upper bound of
the transfer rate (maximum value of n) for each type of the
H.310 terminal.
AVC-769 A case study for H.310 communication procedures
(Japan)
This document presents a case study to clarify the whole
communication procedures from a call setup to the intended
audiovisual communication by listing all the relevant events
for an example case of audiovisual communication. It focuses
on the mode switching for which two proposals have been made,
describing their information flow in the control and
audiovisual channels. Various questions and observations are
provided and some specific proposals are made with respect to
the default mode and mode request. It also points out that
the relationship between H.222.1/H.245 messages and DSM-CC
messages be clarified.
AVC-770 Terminal specification for H.310 terminals (Japan)
This document discusses first the basic specifications of
high quality audiovisual terminal in ATM environments
consisting of AAL5 and TS and then presents available
technologies for inter connectivity with H.320 and compares
their features, highlighting the configuration based on AAL5
and TS. It suggests to make a proper framework of ITU-T
Recommendations for different type of audiovisual terminals
in ATM environments, taking into account not only B-ISDN but
also ATM LANs.
AVC-771 Protocol data unit in H.222.1 layer (Japan)
This document investigates the H.222.1 PDU in terms of FEC
handling in Recommendations, its usefulness for Piecewise
Constant Bit Rate (PCBR) applications, and jitter due to FEC
framing. It concludes that; 1) FEC should be optional for
H.310 A1, B1, A2, and B2 terminals, 2) the specifications of
the H.222.1 PDU for PCBR data should be left as "for further
study" until the implementation of the PCBR terminals is
clarified, and 3) the length of the FEC frames and the
packetization method of TS and PS into FEC frames and AAL
PDUs need further discussion.
AVC-772 Comments on H.310, H,321, H.245, and H.322 (AT&T)
This document lists some comments to the draft texts of the
four Recommendations in the title. It points out that
clarification is needed for where ATM LANs should be handled
(H.322, H.321, H.323).
AVC-773 Proposal to remove FEC from H.222.1 (AT&T, CableLabs,
COMSAT, IBM, Telesis, Technologies Laboratory)
This contribution proposes that the SG 15 Video and Systems
Experts Group reconsider their decision to include FEC in the
H.222.1 layer. The reasons are; additional hardware, non-
support of I.363 for forwarding corrupted data , additional
protocol overhead, FEC location being appropriately in
physical layers.
AVC-774 Concealment of Bit Errors in MPEG2 Video Decoder
(AT&T)
This documents gives experimental results on the impacts of
10 -7 random errors on reproduced pictures for the two cases;
one is to forward bitstream with errors to the decoder, the
other is to detect errors with AAL5's CRC, discard the
information with errors and inform the decoder as to the
location of missing information for concealment. The results
show that pretty good pictures can be reproduced with the
error detection and concealment strategy. As a conclusion,
the document proposes to exclude FEC from AAL5 based H.310
terminals, to include FEC only in AAL1 based H.310 terminals
with its optimization for AAL1 and without alignment between
FEC framing and ATM cells.
AVC-775 Proposals for Error Resilience (AT&T)
This document addresses error resilience by use of H.262 Data
Partitioning syntax in the environments where no priority is
provided. It uses pre-transmission of High Priority
information so that the decoder can use it when recovering
from the packet/cell loss. The document proposes additional
text in H.222.1 to enable the above error resilience method.
AVC-776 Proposals for Multipoint Video (AT&T)
This document proposes additional specifications in H.222.0
and H.245 which allow for simultaneous multiple video
displays by coding every frame as a P frame and use I
macroblocks within these streams when needed. This technique
enables a decoder or MCU to merge multiples of such streams
by simple header manipulations.
AVC-777 Real-Time Interface Specification for Normal Jitter
(AT&T)
This document proposes RTI for Normal jitter, considering ATM
and other environments where higher jitter is involved than
those for RTI-LJ. The specification for t_jitter is 500
microsecond.
AVC-778 Descriptor Information to Aid Timing Recovery (AT&T)
This document addresses a method to indicate from the encoder
to the decoder which parts of the data stream may be used for
recovering the Decoder System Clock. An example of
ITU_video_timinig_descriptor () is given for discussion.
AVC-779 Liaison regarding DSM-CC #2 (SA&A/The ATM Forum)
This document reports that the Implementation Agreement
includes among other things: 1) the DSM-CC definition of
"session", 2) the support of DSM-CC User-Network session
messages for session control mapped over ATM connection
control, 3) the definition of an end-to-end ATM parameter --
the "correlation id" -- to identify and associate all the
ATM-related connections within a session, 4) the definition
of ATM signalling parameters needed to support ATM
connections under DSM-CC session control.
AVC-780 Liaison regarding B-HLI (SA&A/The ATM Forum)
This document states the SA&A consideration for the use of B-
HLI for the Correlation ID and asks SG11 whether B-HLI be
transported end-to-end.
AVC-781 Update of ATM performance assumptions (Experts Group)
This document provides an update of the Experts Group
assumption for the ATM network performance, which is based on
the cocommunication with SG13 and braodband network
performance experts since July 1994.
AVC-782 Liaison regarding H.320 over AAL and AMS Phase 1 Work
Scope (SA&A/The ATM Forum)
This document contains two liaison statements addressed to
ITU-T SG15; 1) H.320 over AAL5 study initiation by ATM Forum,
2) informational correspondence of AMS Phase 1 Work Scope and
Schedule. The second one includes scope and time schedule
for Implementation Agreement as well as MPEG2/AAL5 packing
efficiency and MPEG2 PCR awareness.
AVC-783 A Summary of the April 1995 ATM Forum AMS Meeting
(IBM)
This document reports the outcome of the April Audiovisual
and Multimedia Services (AMS) Activities (Service Aspects and
Applications(SAA) SWG) meeting which focused on: 1) reviewing
the VOD over ATM Implementation Agreement (IA), 2) agreeing
on changes and updates to the VOD IA Baseline text, 3) begin
planning for phase 2 work items. Use of DSM-CC for VOD out-
of-band service selection/control and user-network signalling
parameters are highlighted among other things.
AVC-784 An AAL5 only profile for H.32X (IBM)
This document proposes that the H.32X Draft Recommendation
should specify an AAL5 only profile for Terminal Types A1,
A2, B1, and B2 consideraing the large number of workstation
and PC AAL5 ATM adapters projected to be in use in the
future,
AVC-785 Vacant
AVC-786 List of open issues in H.222.1 (Siemens)
This document lists a number of open issues with respect to
or surrounding H.222.1.
AVC-787 Explanation of current H.222.1 acknowledged signalling
procedures (Siemens)
This document gives explanation of the H.222.1 acknowledged
procedures in form of illustration and examples. It is
proposed that the example procedures be included as an
appendix to H.222.1
AVC-788 Codepoint and parameter duplication in H.245 and
H.222.1 (Siemens)
This document discusses the consequence of overlapped
information in different channel and concludes that it may
not undesirable. It proposes a rule that H.245 should
contain only those parameters which are necessary to
completely describe the capabilities of a terminal, such that
without this parameter the call could not proceed.
Furthermore it proposes to add a descriptor indicating a
capability set of the remote terminal to judge the acceptance
of the requested logical channel establishment.
AVC-789 Proposed additions to H.222.1 acknowledged signalling
procedures (Siemens)
This document proposes the following additions to the H.222.1
acknowledged signalling procedures contained in Annex A of
Draft Rec. H.222.1:
¥ END PDU and RELEASE indication signal parameter to
indicate source of release
¥ N(CAUSE) values in the BGREJ PDU indicating reason for
logical channel establishment refusal
¥ a signal indicating clock synchronisation of the system
clock in the remote terminal
¥ M-ERROR indication signal and ERRCODE values
¥ H.222.1 user plane error codes
¥ PDU coding in the Transport Stream. Two phases of
signalling are required.
¥ N(REQUEST) parameter for the STATREQ PDU to determine
format of information to be returned
¥ Keep alive function in the ESTABLISHED state
AVC-790 Comments on Draft Rec. H.245 (Siemens)
This document provides technical comments and editorial
comments to the draft H.245. The former address 1)
alternative wording for "connection/connectionless", 2)
arrangement of acknowledgment messages, 3) relationship
between logical channel number and PID/stream_id.
AVC-791 Protocols to support H.245 (Siemens)
This document raises a question to the statement in Annexes 3
and 4 to AVC-743R that "the SSCOP is tightly coupled to AAL
type 5 and therefore unsuitable for use in MPEG Systems" and
shows a possible way of using SSCOP PDU in the H.222.1
multiplex.
AVC-792 H.322/3 and an example software based multimedia
conferencing system (siemens, Monash University)
This document describes an example LAN based multimedia
conferencing system, with interworking to standard H.320
terminals in the public network via an ISDN gateway. All
video and audio codec functions are software based. Common
PC platforms and audio and video capture cards are used.
This document is provided as an illustration as to what is
possible in multimedia conferencing using commonly available
PC based hardware.
AVC-793 US National Body Position on MPEG-2 Real-Time
Interface (USA)
This document describes the position of US National Body for
JTC1/SC29/WG11 that the RTI should be modified to suit a
larger range of applications, that the RTI should not contain
a specified value for maximum allowed timing jitter in a
bitstream's real-time delivery, and that the RTI only should
define a framework that helps MPEG users specify their
interoperability requirements between equipment such as video
servers, delivery networks, storage devices, and decoders.
AVC-794 Further clarification on an AAL model for real-time
VBR services (BT and KPN)
This document reports the current progress on an AAL
definition for variable bit rate services which has been made
in SAM/ETSI NA5. It gives modeling of AALs according to
I.363 which shows that the functions allocated to H.222.1 in
the Experts Group liaison should be in the CS. It also shows
the effectiveness of the AAL1-model by means of practical
examples including the support of CBR MPEG-2 and a model for
AAL2 based on AAL1 as well as possible format for the CS-PDU
in AAL2.
AVC-795 Outstanding H.245 issues for ATM-based systems (BT)
This contribution lists the outstanding issues related to
H.245 for ATM-base systems, considers issues raised using e-
mail and proposes some solutions. Commonality with solutions
for PSTN systems is proposed wherever this is possible. The
most outstanding issue is to fix where the logical channel
acknowledged procedures be defined; in H.222.1 or H.245 or
both.
AVC-796 AAL for MPEG-2 Transport Streams (France)
This document discusses that although AAL type 1 is seen as
appropriate for the transport of MPEG-2 signals, the use of
AAL type 5 needs further investigations and that before the
use of AAL type 5 is considered as a serious candidate, it is
necessary to define and describe the selected option for
jitter removal in terms of convergence sublayer so that a
clear comparison between both AALs can be made.
AVC-797 Transmission of T.120 information in a LAN environment
(TU Berlin)
This document aims at describing ways of distributing T.120
data information in a mixed multicast and point-to-point
environment. It proposes a way to make use of LAN (and WAN?)
multicast facilities where possible for more efficient
information distribution. The protocol XYZ layer which fills
the gap between the services and the QoS offered by the LAN
and the needs of the MCS is discussed and a solution is
proposed which separates it into two parts: 1) a (set of)
generic multicast transport protocols that offers reliable,
at least single source ordered, and flow-controllable
service, and 2) an adaptation layer that provides the
additional T.120/H.22Z specific functionality, where
necessary this layer may also make use of reliable point-to-
point protocols e.g. for peer negotiations and "connection"
setup.
AVC-798 Proposed Draft Amendment to ISO/IEC 13818-2 "4:2:2
Profile" (MPEG Requirements and Video Subgroups)
This document proposes addition of the "4:2:2" profile based
on the experiments which had been carried out by the time of
MPEG Lausanne meeting. This profile is a 4:2:2 version of
the Main Profile and intended for professional use where
multiple generations of encoding and decoding are required.
AVC-799 Comments on Draft H.323 and H.22Z (Intel)
This document provides various comments toward setting
appropriate goals for Draft H.323 and H.22Z addressing scope,
terminology, speech coders, control channel, call control,
capability negotiation, audio/video synchronization, audio
quality assurance, network management, inbound call routing,
authentication, support of T.120 data, multiplexing audio and
video, packetizing video, echo on PSTN voice calls,
specification using real world transport protocols.
Temporary Documents
# Source Title
TD-1 Rapporteur Agenda for the Haninge meeting
TD-2 Rapporteur Available documents for the Haninge meeting
TD-3 Rapporteur FTP site for Draft Recommendations and
other documents
TD-4 Rapporteur H-series audiovisual communication
terminals
TD-5 Editor (G. Thom) Overview of H.323
TD-6 DAVIC Press release
TD-7 B. Haskell Various rates in the encoder
TD-8 ATM Forum Audiovisual multimedia services:
Implementation Agreement 1.0
TD-9 R. ter Horst Report on network adaptation issues (AAL,
FEC, CDV compensation)
TD-10 Y. Nakaya Possible implementations of FEC and system
clock recovery
TD-11 Editor (G. Thom) H.323 report
TD-12 Editor (D. Skran) H.22Z report
TD-13 SG8 (Q.10/8) Harmonizing T.120 and H.24X protocol stacks
for ATM
TD-14 Telenor, BT, GPT,
CSELT Audio level setting in H.320 revision
TD-15 J. Ott Issues to be considered for H.22Z and H.323
TD-16 T. Tanaka FEC performance in AAL type 1
TD-17 Rapporteur Draft list of agreements
TD-18 B. Haskell Liaison to ISO ISO SC29/WG11 MPEG regarding
RTI
TD-19 R. ter Horst Liaison to ITU-T SG13/2 Q6 (Mr. Yamazaki)
regarding request for FEC without
interleaver in AAL type 1
TD-20 B. Haskell Proposed Addition to H.245 for Jitter
Control (in ATM Networks)
TD-21 B. Haskell Proposed Timing Descriptor
TD-22 Editor (S.
Dunstan) Resolutions on Draft Rec. H.222.1 and H.245
TD-23 Editor (H. Radha) H.310 Scope for Bi-directional Terminals
END
Annex 2 to AVC-800R
Liaison to ISO ISO SC29/WG11 MPEG regarding RTI
18 July 94
Source ITU-T SG15 Experts Group for Video Coding and Systems
in ATM
Title: Liaison to ISO ISO SC29/WG11 MPEG
Purpose: Generic Real Time Interface Specification
At its May meeting in Stockholm the ITU-T SG15 Experts Group
on Video Coding for ATM agreed that the recently proposed
Real Time Interface for Low Jitter was not useful for our
applications. In fact, changing the jitter number to a
larger value would not help our situation either since, as
yet, we are not sure if network providers will specify upper
bounds on jitter for all their ATM services.
However, we would find it helpful to define a generic Real
Time Interface specification that terminal manufacturers and
network providers could refer to when they indicate their
jitter handling capabilities. In that way, customers would
know very specifically what a provider means when specifying
a jitter number that characteri their equipment or service.
We suggest that part 9 of MPEG2 would be very convenient as a
generic RTI specification if the jitter number were removed
and wording to the effect that it is a generic specification
were added. Attached is a suggested version of a generic
RTI.
END
Real-Time Interface Specification (RTI)
_____________________________________________
Recommendation H.222.2
1. Introduction
Conformance for ITU-T Rec H.222.0 | ISO/IEC 13818-1 Transport
Streams is specified in terms of the normative specifications
in part 0 of this Recommendation. These specifications
include, among other requirements, a Transport Stream System
Target Decoder (T-STD) that specifies the behavior of an
idealized decoder when the stream is input to such a decoder.
The T-STD model, and the associated verification, do not
include information concerning the stream in real time.
This part of the standard specifies the timing of the real-
time delivery of the bytes of Transport Stream packets at a
Real Time Interface for Jittered applications (RTI). This
specification does not change or supersede any of the
requirements in Part 0 of this Recommendation. All Transport
Streams, whether or not they are delivered in accordance with
the RTI, shall comply with the T-STD model. In particular,
the accuracy requirement in Part 0 for PCRs in Transport
Streams is not changed by the requirements of this section.
Compliance with this Recommendation is optional.
Equipment that includes some type of interface for Transport
Stream data, the timing characteristics of which are said to
comply with the RTI specification, must be able to operate
normally with any input that complies with the RTI
specification. In no case, however, is a piece of equipment
required to implement an RTI interface.
Figure 1-0 provides a simplified view of the scope of
H.222.2. This figure shows a Data Link Interface Adaptor , a
Real-Time Interface Decoder (RTD), and the location of the
Transport stream that complies with the RTI Specification.
It should be noted that the Data Link Interface Adaptor is
responsible for removing any data link protocol/data
structures, as well as any timing variations (i.e.) in order
to produce a compliant RTI Transport Stream. This RTI
Specification has been developed specifically for
applications in which the input to the Data Link Interface
Adaptor contains jitter.
- insert figure here
2. Real-Time Interface Requirements for Jittered
Applications
2.1 The Real-Time Interface Decoder Model for Jittered
Applications
The Real-Time Interface Decoder Model for Jittered
applications, called the RTD, is a conceptual model used to
define the RTI normative requirements. The RTD is used only
for this purpose. Neither its architecture nor the timing
described precludes uninterrupted, synchronized playback by a
variety of decoders with different architectures or timing
schedules.
The RTD is exactly the same as the T-STD model defined in
part 0 of this Recommendation, except that
- the byte delivery schedule defined in the T-STD is
replaced by the actual byte arrival time in the RTD;
- real-time constraints are imposed on the values of PCR in
relation to their arrival time in the RTD;
- the buffer sizes defined in the T-STD are different in
the RTD; and
- an extra requirement on the Transport Buffer occupancy,
see below.
2.2 Clock Frequency Requirements
The requirements on the System time clock w.r.t. frequency
and frequency slew given in part 0 of this Recommendation are
also mandatory for the Real-Time Interface for Jittered
applications..
2.3 PCR Accuracy Requirements
This section defines a single constraint on the relationship
of the arrival time of all the bytes containing the last bit
of a program_clock_reference_base field for a single program
of a Transport Stream, and the value carried in the
corresponding program clock reference.
Specifically,
- let system_clock_counter be a counter that counts cycles
of a system clock that satisfies the frequency
requirements specified in clause 2.2 above, where t
represents time;
- let i'' be the index of a byte containing the last bit of
a program_clock_reference_base field;
- let t(i'') be the time at which byte i'' arrives in the
RTD_NJ; and
- let PCR(i'') be the value of the program clock reference
associated with byte i'';
then there shall exist such a system_clock_counter(t) and a
sequence of times e(i'') that satisfy
PCR(i'') = system_clock_counter((t(i'') +
e(i''))%(300*2^33)
and
| e(i'') | <= t_jitter.
2.4 Buffer Requirements
The buffers in the RTD have the same names as those in the T-
STD, indexed with r. Their sizes are:
TBS_rn = TBSn + (2*t_jitter*Rx) + 188 bytes
TBS_rsys = TBSsys + (2*t_jitter* Rx) + 188 bytes
sb_size(r) = sb_size + (2*t_jitter*sb_leak_rate) + 188
It should be noted that the use of the smoothing buffer (sb)
is optional for the RTD, as it is in ISO/IEC 13818-4.
The multiplex buffer (for video) and the decoder buffer (for
audio and systems data) in the RTD have the sizes:
MBS_nr = MBS_n + (4* t_jitter * Rx),
BS_nr = MBS_n + (4* t_jitter * Rx), and
BS_rsys = BS_sys + (4*t_jitter*Rx),
respectively.
Note 1: in all these equations, Rx, which is identical in
definition to the same variable in the T-STD, is
expressed in bytes/second for convenience.
Given the RTD buffers as defined above, and a system clock
that fulfills the above requirements, the RTD requires that
all the buffer constraints imposed by the T-STD in part 0 of
this Recommendation be complied with. In addition, the
buffer state of the buffer TB_rn in the RTD at the arrival of
the first byte of any Transport Stream packet shall be no
more than the size of that buffer minus 188.
2.5 The value of t_jitter
The value of the constant t_jitter (Note this is a zero-to-
peak jitter) is a characteristic to be specified by equipment
and service providers.
3.0 Compliance Testing for RTI
3.1 Assumptions
This text assumes an RTI specification that is developed
according to the three parameters clock accuracy, slew rate,
and PCR jitter. These parametersare referred to in the text
below by variable names, D_f, R_slew, and t_jitter,
respectively. The formulas that tie these parameters to
certain buffer sizes, however, are supposed to remain
fundamentally unchanged.
3.2 Objectives
The objectives of a testing procedure for the RTI
specification are the following:
1. Test for compliance with the frequency accuracy spec.
2. Test for compliance with the slew rate spec.
3. Test for compliance with the PCR jitter spec.
4. Test for compliance with the buffer requirements.
For some streams, all of these requirements cannot be reached
in the sense that it's not possible to measure them
accurately enough or to separate them from each other. In
principle, it can be said that streams need to have a certain
length for the concept of compliance with all four points to
have any meaning. The procedures for the different
objectives are outlined briefly below.
3.3 Procedure
Frequency Accuracy, Slew Rate, and PCR jitter
. The compliance test is carried out for one program at a
time. The rest of the procedure is described for one
program called P.
. For each byte that carries the last bit of a PCR field for
P, the arrival time of that byte and the value of the
corresponding PCR itself are noted. These values are called
t(i) and PCR(i), respectively.
. When all PCR values in the segment of stream to be tested
have been noted, these are plotted against their arrival
values.
. The stream is now compliant if a graph can be drawn such
that its slope in each point is compliant with the
requirement for STC frequency
. accuracy; its curvature in each point is compliant with the
requirement for maximum STC frequency slew; andits vertical
distance to any of the points (t(i), PCR(i)) is not greater
than t_jitter in any case.
Finding a graph such as in d. will sometimes be difficult. A
stream is compliant whenever such a graph can be found, and a
stream is not proven non-compliant until it can be proven
that no such graph exists. This can be proven in some cases
by for example taking a suspect point (t(i), PCR(i)) and draw
a region that includes all other permissible points in the
bitstream . If another point falls outside that region, the
stream is non-compliant. A stream shall be assumed to be
compliant unless it can be proven to be non-compliant.
3.4 Buffer Compliance
The buffer compliance test shall be performed exactly as the
corresponding test for the T-STD, except for obvious changes
due to different arrival times and buffer sizes, as well as
the extra requirement for TB_r occupancy at the start of
Transport Stream Packets.
END
Annex 3 to AVC-800R
Correspondence to Rapporteur for Q.6.1/13 in ITU-T SG13
Source : Q.2/15
Title : Correspondence to Rapporteur for Q.6.1/13 (Mr.
Yamazaki) in ITU-T SG13
Purpose : Request for FEC without interleaver in AAL type
1
The experts group for video coding and systems in ATM and
other environments discussed the ATM network adaptation for
broadband audiovisual communication systems and terminals. We
currently focus on CBR only, with scenarios for both AAL1 and
AAL5. We concluded that:
¥ There is currently no identified need for FEC in the AAL5
scenarios.
¥ For the AAL1 scenarios, the existing RS (128,124) FEC in
AAL1 was identified to meet our needs. For low delay
including FEC, we propose a non-interleaved version of this
FEC. In this case there is no correction for cell losses,
but this is acceptable in our network and service
scenarios, since cell losses will be detected. FEC framing
is supported by the CSi bit every 47 FEC frames, similar to
the interleaved version.
¥ The AAL1 FEC options we propose for the broadband
audiovisual terminals therefore are:
1. RS (128,124) with interleaving
2. RS (128,124) without interleaving
3. No FEC
¥ The AAL1 option of FEC without interleaver should be
supported by the capabilities exchange in both Q.2931 for
channel set-up and H.245 for multimedia system control.
¥ It was emphasized that at the AAL1 CS service access points
a CBR service is defined, independent of the optional use
of the FEC inside of the CS. As an example: in case of the
adaptive clock method in AAL1, this method should
incorporate the buffering delays introduced in the FEC
decoder.
Some concern was expressed in the meeting on the
effectiveness of the RS (128,124) code without interleaving.
It is capable to correct 2 byte symbols that have errors in a
block of 128 bytes, with unknown location of these bytes.
The probability of two random bit errors in a 128 byte frame
is very low, but the capabilities for burst errors with a
burst length of more than 8 bits gave us some concern. Also
the effect of the scrambler in the physical layer was
mentioned: a bit error in the physical layer will cause a
second error 43 bits apart in the ATM layer.
It was however mentioned that even if the RS (128,124) error
correction capabilities may be limited, its use for error
detection may be appropriate for the broadband audiovisual
terminal. This is subject to further study.
Conclusions
1. We propose the inclusion of the non-interleaved RS(128,124)
code as an additional FEC option in the AAL type 1 CS.
2. We invite comments on the effectiveness of this FEC option,
with a view on the error characteristics (single bit vs.
burst errors) that can be expected from the networks.
3. We invite comments on the effectiveness of this RS code for
error detection.
END
Annex 4 to AVC-800R
FEC performance in AAL type 1
Source: Tomoaki TANAKA, NTT
Title: FEC performance in AAL type 1
Purpose: Information
FEC method Delay
(*1) at 6 Mbps
(msec) Probability of
uncorrectable bit errors
(*2)
no FEC 47x8 / R 0.06 1
FEC without
interleave ;
RS(128,124)
(47x3-4)x8 / R
0.18 For 2 single bit errors ;
10**-n (*3,*4)
For 2 bits burst error ;
1-(6/8) = 0.25 (*5)
FEC long interleave
;
128 cells that
include 4 RS cells
47x124x2x8 / R
15.5 extremely low
* 4 cell losses or
* 2 cell losses and l
errored
octet in each row
* 2 errored octet in each
row
*1 R = Information bitrate at AAL SAP. (see Fig. 1)
*2 If this value is X and bit error ratio at ATM layer SAP is
10**-9, the error ratio at AAL SAP is Xx(10**-9).
*3 In SDH, one bit error in physical layer causes two bit
errors in ATM layer, 43 bits apart because of scrambler for
cell payload. (see Fig. 2)
*4 10**-n is probability in which more than two bit errors
in physical layer are included in one FEC frame. If bit
errors occur in random and bit error ratio is 10**-9, this
value is approximately 10**-7.
*5 6/8 is probability in which two bits burst error does not
occur beyond octet boundary. (see Fig. 3)
Conclusions
¥ FEC without interleave is not tolerable for burst errors.
¥ Probability for uncorrectable error is 25% for 2 bits burst
error.
¥ We should be careful whether usual error is single bit
error or burst error. (see Liaison to SG 13 as in Annex 3)
Note: - FEC without interleave may be used for bit error
detection. The performance of error detection is for further
study.
END
Annex 5 to AVC-800R
Possible implementations of FEC and system clock
recovery
SOURCE : Japan
TITLE : Possible implementations of FEC and system clock
recovery
Purpose : for clarification
1. AAL1
AC: adaptive clock
2. AAL5
END
Annex 6 to AVC-800R
Proposed Timing Descriptor
Source: AT&T (Barry Haskell)
Title: Proposed Timing Descriptor
Purpose: Review
ITU_timing_descriptor(){
descriptor_tag (=70) 8 uimsbf
descriptor_length 8 uimsbf
SC_PESPktR 24 bslbf
SC_TESPktR 24 bslbf
SC_TSPktR 24 bslbf
SC_byte_rate 30 bslbf
vbv_delay_flag 1 bslbf
reserved 1 bslbf
reserved 32 bslbf
}
SC_PESPktR-- If ¹ 0xffffff, this parameter indicates that
PES packets are passed from the encoder buffer to the
multiplexer buffer at a constant rate. Integer value is the
ratio of 27e6 Hz to the PES packet rate. It specifies the
interpacket durations for the next PES packet and all
following packets up to and including the PES packet
following a new valid SC_PESPktR.. This parameter is valid
only in an elementary stream descriptor.
SC_TESPktR-- If ¹ 0xffffff, this parameter indicates that TS
packets for the specified elementary stream (hereinafter
called TES packets) are passed from the encoder buffer to the
multiplexer buffer at a constant rate. Integer value is the
ratio of 27e6 Hz to the TES packet rate. It specifies the
interpacket durations for the next TES packet and all
following packets up to and including the TES packet
following a new valid SC_TESPktR.. This parameter is valid
only in an elementary stream descriptor.
SC_TSPktR-- If not= 0xffffff, this parameter indicates that
TS packets for the specified program are passed from the
multiplexer to the network at a constant rate. Integer value
is the ratio of 27e6 Hz to the program TS packet rate. It
specifies the interpacket durations for the current TS packet
and all following packets from the specified program up to
and including the TS packet containing a new valid
SC_TSPktR. The program_number indicates to which STC the
TS packet rate is locked. Only PSI packets containing
sections describing this program are considered part of this
program. Null TS packets belong to no program. This
parameter is valid only in a program descriptor.
SC_byterate-- If ¹ 0x3fffffff, this parameter indicates that
PES bytes are passed from the encoder buffer to the
multiplexer buffer at a constant rate. Integer value is the
ratio of 27e6 Hz to (byte_rate/50), ie,
SC_byterate=135e7/byte_rate. It specifies the interbyte
durations for the next PES packet and all following packets
up to and including the PES packet following a new valid
SC_byterate. This parameter is valid only in an elementary
stream descriptor.
vbv_delay_flag-- This is a 1 bit flag which when set to Ô1Õ
indicates that the video parameter vbv_delay may be used for
timing recovery. The last byte of PSC arrives nominally at
time
DTS - vbv_delay. This flag is valid only in a video
elementary stream descriptor.
All rates mentioned above are locked to the Systems Time
Clock, whose frequency is nominally 27e6Hz.
Informative Annex
In severely jittered or highly lossy networks, timing
recovery may be problematic in inexpensive implementations
that cannot afford highly stable crystal clocks. Often the
encoders can provide information as to which parts of the
data stream may be useful for recovering the Decoder System
Time Clock (D-STC) frequency and phase.
Generally this means that one or more data rates are locked
to the Encoder System Time Clock (E-STC) and can be used in
an Adaptive Clock Recovery (ACR) scheme at the decoder. The
size of the assumed buffer in the ACR is implementation
dependent and will depend on how much jitter is encountered
during transmission. The jitter may or may not include
multiplexing jitter. If it does, then the assumed ACR buffer
will be larger.
END
Annex 7 to AVC-800R
Report on network adaptation issues (AAL, FEC, CDV
compensation)
SOURCE: ITU-T SG15 Experts group for video coding and
systems in ATM and other environments
TITLE: Report on network adaptation issues (AAL, FEC, CDV
compensation)
PURPOSE: Information
Several inputs to the meeting discussed the network
adaptation protocol reference model that had been drafted in
the groupÕs January meeting (Annex 7 to AVC-743).
The approach of a common FEC and FEC framing in the H.222.1
specific sub-layer has been abandoned, since jitter problems
have been identified and since the inclusion of FEC in this
sub-layer was considered to be inconsistent with the AAL CS
model approach. Methods for piecewise CBR (PCBR) or VBR in
H.222.1 will not yet be included in the November 1995 version
of H.222.1. We therefore restricted the H.222.1 scenarios to
CBR over AAL1 and AAL5:
· There is currently no identified need for FEC in the AAL5
scenarios. The error detection in the AAL5 CPCS layer would
be sufficient, in combination with simple error concealment
in the video layer. It was mentioned that detection of TS-
packet loss can be included in the System layer and may
support the concealment in the video decoder.
· For the AAL1 scenarios, the existing RS (128,124) FEC in
AAL1 was identified to meet our needs. For low delay
including FEC, we agreed on a non-interleaved version of
this FEC. In this case there is no correction for cell
losses, but this is acceptable in our network and service
scenarios, since cell losses will be detected. FEC framing
is supported by the CSi bit every 47 FEC frames, similar to
the interleaved version.
· The AAL1 FEC options for H.222.1 therefore are:
1. RS (128,124) with interleaving
2. RS (128,124) without interleaving
3. No FEC
· The AAL1 option of FEC without interleaver should be
supported by the capabilities exchange in both Q.2931 for
channel set-up and H.245 for multimedia system control
· It was emphasized that at the AAL1 CS service access
points a CBR service is defined, independent of the optional
use of the FEC inside of the CS. As an example: in case of
the adaptive clock method in AAL1, this method should
incorporate the buffering delays introduced in the FEC
decoder.
The group concluded that the RTI as an internal point between
H.222.0 and H.222.1 is not an essential conformance point,
since implementers may integrate the functions of the
different layers, without implementation of an internal RTI
compliant interface. However, RTI as a definition was
considered to be useful for specification of jitter handling
capabilities of separate H.222.0 equipment. We concluded
that no particular jitter value need be mentioned in the RTI
specification.
The essential interface is the user network interface as
shown in figure 1. Definition of expected values for CDV, as
well as BER and CLR, at this interface is needed for the
design of the ATM audio-visual terminal. The ATM performance
assumptions as in document AVC-781 have been discussed with
SG13 experts on these issues. We decided that these
performance assumptions will be an informative note to
H.222.1, giving some guidance to implementers.
Figure 1: Overview of the AAL1 and AAL5 functions for
H.222.1
Note 1:: AAL SAP is a definition point in the model.
Implementers may choose to integrate the AAL CS and
H.222.1 functions for CDV accommodation, also for AAL1.
Note 2: The AAL1 structured data transfer (SDT) method is
only applicable if no FEC is used. However, all other
combinations of error correction, delimitation and
timing recovery are allowed. Use of the SDT method has
not been identified for H.222.1.
END
Annex 8 to AVC-800R
Resolutions on Draft Rec. H.222.1 and Draft Rec. H.245
SOURCE: Stuart Dunstan, Siemens Ltd
TITLE: Resolutions on Draft Rec. H.222.1 and Draft Rec.
H.245
PURPOSE: Report
No. item description action
1 Logical channel
signalling In support of harmonisation with LBC,
logical channel signalling procedures
have been moved from H.222.1 to H.245.
In H.310 H.245 logical channel
signalling is always done for all
terminal types.
PSI/PSM tables (repeated signalling) in
the TS/PS are redundant. Their coding
is not mandatory. H.222.1 SD
H.245 SDLs SD
H.245 MN
H.310 HR
2 H.245 functions H.245 has the following distinct and
independent functions:
¥ capability exchange
¥ logical channel signalling
¥ C&I
There may be other distinct functions.
Attachment 1 shows H.245 in relation to
the H.310 terminal. Attachment 2 shows
H.245 PDUs. H.245 MN
3 Mode switching Mode switching is performed by opening
multiple logical channels which share a
common decoder resource. See Sharing is
indicated by inclusion of a resource_id
in the BGN message. H.245 C&I attaches
the decoder resource to one and only one
of the open logical channels. See
Attachment 3.
These procedures implement the
dependency capabilities indicated during
the capability exchange.
The term Òfast mode switchingÓ is to be
changed to Òmode switchingÓ. Reference
to Òslow mode switchingÓ is to be
dropped. H.245 MN
4 logical channel
reference Moving the logical channel signalling to
H.245 i.e out of band with respect to
H.222.1, requires that a logical channel
be referenced by reference to both:
¥ an ATM VC (or TS/PS)
¥ a PID/stream_id
Options for identifying an ATM VC end-
to-end include use of:
a) Q.2931 and correlation_id
b) Progressive; H.245 followed by
Q.2931 signalling. H.245 attaches
an end-to-end reference to the next
VC to be opened.
c) Inband H.222.1 signalling
a) is the preferred solution. Use of
the correlation_id is to be confirmed.
. b) is a satisfactory alternative. c)
is undesirable and not allowed. H.245 MN
MN.: confirm
use of
correlation_id
with DSM_CC
5 Additions to
H.245
acknowledged
signalling
procedures ¥ the STAT and STATREQ PDUs, and
related signals are to be removed.
¥ CAUSE values to be added to BGREJ
¥ SOURCE parameter to be added to END
PDU
¥ signal to indicate receive terminal
clock synchronisation
¥ table of error codes for M-ERROR
signal.
¥ H.222.1 user plane errors
¥ addition of H.245 keep alive
function in which H.245 sends a
signal to its peer, and expects an
acknowledgment signal in a fixed
period. N retries are attempted
before the remote terminal is
declared to be not alive. H.245 SDLs SD
H.222.1 SD
6 ITU-T
stream_ids The arrangement as shown in Attachment 4
was adopted. H.222.1 SD
7 ITU-T stream
types and
PTS/DTS ITU-T audio stream types may be used
with MPEG video. A definition of an
access unit is required for ITU-T audio.
There is never an MPEG Systems system
time clock associated with H.261. (why
not??) SO
8 frame
synchronous
signalling Two options were considered
a) signal in video layer picture
header
b) signal in PES packet. Use ITU-T
data stream_id, and use PTS in the
PES packet to time the event.
The former has good packing efficiency
but is less flexible. The latter was
chosen as the desired method.
H.222.1 requires video frame synchronous
stream type and stream_id_extension
codepoints, and a description of the
method.
The video frame synchronous signals are
to be described in H.310. H.310 HR
H.222.1 SD
9 H.222.1 and
jitter removal H.222.1 may offer the service of jitter
removal/reduction. The method is left
to implementations. H.222.1 provides no
specific coding for removal of jitter,
but contains qualitative description of
jitter removal as part of its
functionality with a note containing
some specific values for information
purpose. H.2221. SD.
10 Number of
programs In the H.310 terminal there shall be
only one MPEG System System Time Clock
i.e. only one program, in one
communication direction. This is true
even in the case of multiple VCs i.e.
multiple TS/PSs, in which case one STC
is shared amongst many TS/PSs.
This impacts H245 logical channel
signalling (amongst other things). H.222.1 SD
H.310 HR
11 Multiple TS/PS When multiple VCs are used i.e. multiple
TS/PSs, it is mandatory to code PCR/SCRs
in at least one TS/PSs. It is not
mandatory to code PCR/SCRs in all
TS/PSs.
PSI required in each case? H.222.1 SD
12 Figure 1 Annex
9 AVC-743R Figure 1 will be moved to an informative
Annex in H.222.1. It will be updated as
follows;
¥ the T.120 protocol stack will be
left unspecified. If the protocol
stack is decided in the near term
it will be described in H.222.1 (or
H.310?). If not in the near term
it will be described in H.310.
¥ the diagram will be updated to
reflect changes in signalling H.222.1 SD
(H.310 HR ?)
13 Encryption H.222.1 will say that PES packets and TS
packets may be encrypted using H.233.
H.222.1 will say nothing about exchange
of keys etc. H.310 will say something
about this.
Requires confirmation H.310 HR
H.222.1 SD
MN to
investigate
14 Use of AALs AAl type 1
use of primitives will be stated.
H.310 to specify use of CS tools.
AAL type 5
text from ATM Forum IA 1.0 will be
used H.222.1 SD
H.310 HR
15 Default coding
modes and
logical
channels Shown in Attachment 5. Where is this to
be specified? H.222.1 SD
H.310 HR
16 H.222.0
optional
functions Some fields in MPEG-2 Systems relate to
Network Elements e.g remultiplexers. A
H.310 send terminal is not required to
code these fields, but may. A H.310
receive terminal by definition ignores
these fields. H.222.1 SD
17 H.222.1 ¥ in section 6 change ÒfunctionsÓ to
ÒservicesÓ.
¥ in clause 5 include a statement
that H.222.1 currently only
supports constant bit rate coded
video.
¥ correct editorial errors in clause
13 on descriptor rules
¥ remove reference to mode changing.
This is now described in H.245 H.222.1 SD
H.245 MN
18 Error
resilience,
AVC-775 Include the improved 2nd and 3rd last
paragraph of AVC-775 in H.222.1. See
Attachment 6. H.222.1 SD
19 Jitter
descriptor, AVC
764 Include Annex 9 to this report in H.245. H.245 MN
20 Timing recovery
descriptor AVC-
778 Include Annex 6 to this report in
H.222.1. H.222.1 SD
21 H.245
codepoints The following codepoints are required to
be inserted in H.245;
¥ T.120 codepoint
¥ MPEG-2 audio
¥ AAL type 1 CS options
¥ AAL type 5 unassured/assured option H.245 MN
22 ATM network
adaptation
capabilities The syntax has been modified to offer
greater flexibility. The syntax
supports mixed AAL types and mixed TS/PS
in one call. H.245 MN
H.310 HR
23 H.245 Appendix
I This appendix is to illustrate coding
and should be more extensive.
Contributions are sought. ??
H.245 MN
24 H.245 A.5.1 FR-
SSCS Some text on using this service are
required KH
H.245 MN
25 H.245 clause
6.2 Point to
Multipoint
working Clarification of this section is
required. Once clarified the terms
Òconnectionless" and Òconnection
orientatedÓ should be replaced by more
appropriate ones. clarification
MN
H.245 MN
26 H.245 style H.245 should be written in a generic
manner, so that it is applicable to a
wide range of applications. H.245 MN
27 H.245 progress Good communication between AVC and LBC
groups is required. Post comments at
both AVC and LBC reflectors.
28 H.245 and H.323 Requirements from the H.323 perspective
are to be reflected by means of an input
to the SG15 meeting in November.
29 Descriptor
priority rules To be corrected as advised H.222.1 SD
- end -
Attachment 1 / Annex 8 to AVC-800R
Logical channel signalling and H.245
Attachment 2 / Annex 8 to AVC-800R
H.245 PDUs
function subfunction PDU parameter
capability
exchange REQCAPSET
ACKCAPSET
NACKCAPSET -
-
cause
mode request REQMODE -
logical channel
signalling establishment BGN
BGAK
BGREJ VCn, PID/stream_id,
sequence number, stream
parameters
VCn, PID/stream_id
VCn, PID/stream_id,
cause
release END
ENDAK VCn, PID/stream_id,
source
VCn, PID/stream_id
C&I H.233 data C&I
unacknowledged
data transfer UDATA
FLOWCONTROL user_data
multiplex table
(GSTN only) MUXTABLE
ACKMUXTABLE
NACKMUXTABLE
SETMUXTABLE
ACKSETMUXTABLE
NACKSETMUXTABLE
mode switching
Attachment 3 / Annex 8 to AVC-800R
stream_type = H.261
resource_id = 10
stream_type = H.262
resource_id = 10
stream_type = A law
resource_id = 11
stream_type = mu law
resource_id = 11
Attachment 4 / Annex 8 to AVC-800R
Attachment 5 / Annex 8 to AVC-800R
Default coding mode and logical channels
Program Stream Transport Stream
channel stream_id_ext network adapt PID network adapt
H.245 0x00010
G.711 A-law 0x00011
G.711 m-law 0x00012
Attachment 6 / Annex 8 to AVC-800R
Add the following three paragraphs to Section 12 / H.222.1
In order to improve error resilience, especially during
severe error bursts, the video information may be encoded
according to the data partitioning (DP) specification of
H.262 with all End-of-Block (EOB's) in the base layer. Then
the enhancement layer contains only Sequence, GOP, Picture
and Slice headers, and may be transmitted on a low-loss
virtual channel.
The base layer could be decoded, in principle, by both DP as
well as non DP decoders. However, the presence of the
sequence_scalable_extension() and priority break points may
disrupt some standard-profile non DP decoders.
Thus, in order to improve interoperability, the above
encoding may be implemented with a base layer that does not
contain priority break points or
sequence_scalable_extension(), in which case a
default_break_point value of 128 is used, which means that
all EOBs are in the base layer. The Hierarchy descriptor
(H.222.0, Sec. 2.6.6) defines the DP enhancement layer, which
in this case contains only Sequence, GOP, Picture and Slice
headers.
END
Annex 9 to AVC-800R
Proposed Addition to H.245 for Jitter Control (in ATM
Networks)
Source: AT&T (Amy R. Reibman and Barry Haskell)
Title: Proposed Addition to H.245 for Jitter Control (in ATM
Networks)
Purpose: Review
IN: Section 4.1 Multimedia system control messages
ADD:
jitterControl [APPLICATION 12]IMPLICIT
JitterControl
ADD NEW SECTION (syntax)
Section 4.13 Jitter control
JitterControl ::=SEQUENCE
{
logicalChannelNumber INTEGER (0,8191), -- for 13
bit PID --
estimatedReceivedJitter 5-bit STRING
skippedFrameFlag BOOLEAN
skippedFrameCount OPTIONAL INTEGER (0,15)
availableBufferFlag BOOLEAN
additionalDecoderBuffer OPTIONAL INTEGER (0,2^18-1)
}
ADD NEW SECTION (semantics)
Section 5.13 Jitter control
This message is used to specify the amount of jitter
estimated by the the receiver of a logical channel. It may
be useful for choice of bit-rate, buffer control in video
channels, or to determine the rate of PCR transmission in PCR
channels, etc.
The video encoder will then have the option of using this
information to restrict the video bit-rate or the video
decoder buffer fluctuations to help prevent decoder buffer
underflow or overflow, given the occurring jitter. If the
encoder takes this option, it will enable correct operation
for existing designs of video decoder buffers, regardless of
the amplitude of received jitter, as well as allow correct
operation with minimum delay.
When the logicalChannelNumber is zero, the information
pertains to the whole multiplex. Each transmission of this
command can affect a specific logical channel or the entire
multiplex. More than one such command may be in effect at
the same time, up to the number of open logical channels plus
one, for the overall multiplex limitation.
estimatedReceivedJitter provides an estimate of the jitter
that has been received by the unit sending the message. The
meaning of the 5-bit STRING is defined as follows.
The possible range is from 1 usec to 7.5 sec. The first 2
bits indicate the magnitude of the received jitter as
described by the table below:
bits meaning
00 1
01 2.5
10 5
11 7.5
The next 3 bits indicate the exponent of the received jitter:
bits meaning
000 larger than 7.5 sec
001 * 1 usec
010 * 10 usec
011 * 100 usec
100 * 1 msec
101 * 10 msec
110 * 100 msec
111 * 1 sec
[Example: 5-bit STRING = 01011 means 250 usec.] If the last
3 bits are 000, the estimatedReceivedJitter is greater than
7.5 seconds, which is the maximum that the syntax can
specify.
skippedFrameFlag is "1" if skippedFrameCount is present.
It is "0" otherwise.
skippedFrameCount indicates how many frames have been
skipped by the decoder since the last JitterControl message.
[Since frames are skipped when the decoder buffer underflows,
additional jitter may cause the decoder buffer to underflow
more or less often than the encoder expects frame skips to
happen.] Since the maximum value here is 15, this
information must be transmitted (if the decoder implements
this option) before more than 16 frames have been skipped.
availableBufferFlag is "1" if additionalDecoderBuffer is
present. (This is only necessary to be transmitted once,
since it doesn't change during the call.) It is "0"
otherwise.
additionalDecoderBuffer indicates the additional size of
the video decoder buffer over and above that required by the
indicated profile and level. This uses 18 bits, and is
defined the same way as vbv_buffer_size in section 6.3.3 of
ITU-T H.262.
Figure 1 shows a possible signaling time-line for the encoder
and decoder.
Figure 1. Possible scenario for jitter control signalling.
END
Annex 10 to AVC-800R
H.310 Action Items
1) Mapping of G.7XX audio to TS and PS (H.222.1 SD)
2) Mapping of TS/PS to AAL1/AAL5 (H.222.1 SD)
3) Define call procedures for : (Mr. Hibi)
¥ Unidirectional terminals
¥ Bi-directional terminals
4) H.245 Protocol Stack (Mr. Hibi)
(H.222.1 SD)
5) T.120 Protocol (Mr. Hibi)
6) Transfer rate description: (Mr. Haskell, Mr. Tanaka)
(a) Expression
(b) Mandatory modes
7) Multipoint and Broadcast mode support (Mr. Skran)
END
Annex 11 to AVC-800R
Issues to be considered for H.22Z and H.323
Source: Jšrg Ott, TU Berlin
Title: Issues to be considered for H.22Z and H.323
Purpose: Discussion
This contribution lists a set of work items that should be
considered in the progress of the stanardization of H.22Z and
H.323. The list below does not claim to be exhaustive and
just covers a few of the issues that came up in the
discussions so far. It is grouped according to subjects;
neither grouping nor the sequence shall express any
prioritization.
1. Connection setup and teardown
a) Two approaches have been identified for call setup: either
translating an E.164 address into a LAN (e.Êg. IP) address
within the gateway or giving additional information (such
as the within the called institution unique) name of the
person to be contacted and using some directory service to
translate this name into a LAN address. For both
approaches it might be useful to carry out the respective
procedure without the need for a translation table that is
updated manually. Assuming that some means of
authentication is provided anyway, the gateway might simply
query the entire LAN for the requested address or name (as
is done in the Address Resolution Protocol). This would
have the side effect to allow some degree of user mobility
in the LAN.
b) It needs to be defined how data and audio/video information
streams do relate to each other and whether the existence
of an audio connection (only when talking to an H.320
terminal?) is a prerequisite for the establishment of a
data path and whether closing the audio(visual) connection
implies closing the data connection (which is the case in
H.221). The various scenarios should be investigated.
c) In conjunction with this it needs to be specified how
bandwidth is allocated to the various information streams
of the LAN terminals and how changes are made. The
guarantee that the allocated bandwidth is not exceeded
should be implemented in the H.323 terminal by some means
of rate control.
d) Furthermore, it should be considered that LANs might
provide some means of prioritizing certain information
streams over other traffic up to a preallocated bandwidth
without giving a guarantee for this bandwidth (and delay,
jitter) to be available.
e) It should be specified how point-to-point connections are
set up within a LAN (without the interference of an MCU or
a gateway?).
f) Will the same (TCP) connection that is used to exchange the
Q.931-like PDUs of IEEE 802.9a be used for H.245 PDUs? As
no commonly accessible D channel seems to be needed this
approach seems feasible. The lifetime of this connection
should determine the lifetime of the call (including
T.120?).
g) What is the maximum rate of H.22Z traffic allowed in a LAN
with a certain load for the resulting communication quality
to be considered acceptable (from a standardization point
of view)? What is to be done if the LAN load varies (how
long can a decrease in quality be tolerated; when shall the
call be dropped; etc.?)?
2. Aspects concerning signalling with H.245
a) How are multiple information streams (audio/video/data) of
H.245 identified to belong to the same logical connection?
b) A reliable transport mechanism should be used to transmit
H.245 PDUs to prevent loss of control information, e.Êg. a
TCP connection.
c) In some cases, e.Êg. for mode switches, it is required to
synchronize H.245 PDUs and the affected information
streams. This might be done by either including references
in the H.245 PDUs which PDU (referred to by means of its
media type and sequence number) is the first to be affected
by the change, or to provide some inter-stream
synchronization by means of some global sequence number.
3. T.120 and other data streams
a) How are the T.120 data stream, audio and video streams that
belong together identified? Do they share a common
identifier? Who assigns this identifier?
b) What is done with other data streams that are not supposed
to be reliable (for real-time applications such as far end
camera control)? A separate content type is needed for
this.
4. Multicasting issues
a) Communication in LANs according to H.323 is point-to-point.
The usage of multicasting is optional and is not
standardized in the short term. However, a manufacturer-
specific solution must be possible and has to be negotiated
in a standardized way so that multicast and non-multicast
terminals may be distinguished. Negotiation of
multicasting capabilities should be included, and it must
be possible to negotiate which (non-standard) way of
multicasting is applied for which information
(audio/video/data) stream.
b) Which body is responsible for specifying the negotiation
and usage of a multicast transport for both audio/video as
well as data information? It is expected that SG15 defines
the optional usage of audio and video but what is to be
done with data. As part of a capability exchange this has
to be done in SG15, however, the decision to actually use
this capability needs to be taken during connection setup
of the T.120 transport connections (or at some later point
in time) - which then would be up to Q10/8. This raises
the question which tasks are to be performed by this
working group and what is to be done by Q10/8 concerning
the T.120 protocol suite?
5. Security issues
a) In LANs it might be crucial to the trustworthyness of a
terminal that encryption of all kinds of information is
supported. This signalling must be carried out end-to-end
as the gateway cannot simply perform decryption (if it
should, is needs to participate in a key exchange procedure
and must be trusted as well).
b) The H.233 encryption mechanisms would solve this problem
(and should be provided anyway). This requires that either
none, some, or all of the information streams are crypted
with the same or different encryption keys. This requires
that an H.323 terminal is able to identify all information
streams belonging to the same H.221/H.223 connection.
6. Gateway issues
a) How many gateways are allowed to interface to a LAN? If
more than one (logical) entity is allowed, do they need to
interact? How is this done?
b) Which functionality is located in a gateway? We have
suggested a range from a dumb transport layer converter to
a smart MCU that includes T.120 functionality. As
integration of both functions provides interesting
perspectives (and thus is more than simply an MCU running
on a gateway), with respect to future development, all
possible scenarios should be considered.
7. Protocol format
a) The H.22Z header should start with two zero bits to
simplify distinction from RTP packets.
b) The packetization rules for various media specified by the
IETF AVT working group should be used whenever applicable.
This would be useful for possible ÒtranscodingÓ.
c) The 16- and 32-bit words used in the PDU format should be
aligned to 16-bit and 32-bit boundaries, respectively.
END
Annex 12 to AVC-800R
Correspondence to SA&A/The ATM Forum
To: George Dubrowski Chair, ATM Forum Technical
Committee
Dean Skidmore Chair, SA&A / AMS
From: ITU-T SG15 Experts Group for Video Coding and
Systems in ATM and Other Network Environments
Subject: Current Status of ITU SG-15 ATM Terminal
Definition
The ITU-T SG15 Experts Group for Video Coding and Systems in
ATM and Other Network Environments met in Haninge, Sweden,
May 15 - 18th. Many aspects related to the profiling and
functional features of ATM audio-visual and multimedia
terminals were discussed and decided.
Attached is the meeting report of the SG15 experts group.
The ITU-T SG 15 requests that the ATM Forum consider this
work in its development of Implementation Agreements for
audio-visual and multimedia services.
Furthermore, we identified that the following work items of
SA&A/The ATM Forum are relevant to the work of this Experts
Group and we appreciate to be informed of the outcome:
¥ Network performance, CDV in particular,
¥ Definition of uni-directional communication terminals, and
¥ DSM-CC mapping to Q.2931.
Sakae OKUBO
Rapporteur for Q.2/15
Graphics Communication
Laboratories
6F Annex Toshin Bldg, 4-36-19
Yoyogi
Shibuya-ku, Tokyo 151 Japan
Phone : +81 3 5351 0181
Fax : +81 3 5351 0185
e-mail : okubo@gctech.co.jp
Attachment: AVC-800R Report of the Haninge meeting of the
Experts Group
END
Annex 13 to AVC-800R
Correspondence to ETSI NA5
To: Mr. H-J. Breuer, Chairman ETSI NA5
From: Mr. S. Okubo, Rapporteur for Q.2/15 in ITU-T
SG15
ITU-T SG15 Experts Group for Video Coding and Systems
in ATM
and Other Related Environments
Purpose: FOR INFORMATION
Subject: ITU-T SG15/Q.2 video experts group's progress on ATM
network adaptation
ITU-T SG15 Q.2 video experts group thanks ETSI NA5 for its
liaison statement clarifying the Convergence Sub-layer (CS)
functions associated with AAL 1 and a proposed AAL 2, which
SG15 reviewed at its meeting in Haninge, Sweden (15-18 May
1995).
The liaison was very helpful in clearly identifying the CS
functionality with respect to I.363. SG15 also noted NA5's
concern that in the AAL 2 proposal some traditional CS
functions (e.g. timing recovery and error correction) had
been repositioned by SG15 into its H.222.1 layer.
We understand that NA5's liaison was also presented and
discussed at the rapporteur's meeting of SG13 AAL (chaired by
Mr. Yamazaki), in Stockholm, prior to the SG15 meeting. We
also understand that it was agreed at the SG13 meeting that
SG15's proposal for moving some CS functions into high layers
was not against the principles of I.363. SG15 is therefore
fully entitled to perform some CS functions in H.222.1 if it
is needed to meet SG15's requirements.
SG15 would also like to inform NA5 that as a result from its
Haninge meeting SG15 has decided to only consider constant
bit rate encoded video services (i.e. H.262/MPEG-2, H.261) in
its first phase of Recommendations (e.g. H.222.1, etc.) due
in November 1995. Although SG15 has no immediate need to
transport variable bit rate encoded MPEG-2 signals this will
be a requirement in its next phase of work.
SG15 wishes to thank NA5 for its past contributions on the
development of AAL 2 and would be interested in any further
progress that NA5 makes on AAL 2 development. I have attached
meeting documents TD9 and TD19 to assist NA5 in any future
AAL developments that it may undertake and will continue to
keep it informed of any relevant progress made within SG15's
experts group on adaptation requirements.
Attachments:
TD-9 Report on Network Adaptation issues (AAL, FEC, CDV
compensation) May 1995
TD-19 Request for FEC without interleaver in AAL type 1
May 1995
Conatact:
Sakae OKUBO
Graphics Communication
Laboratories
6F Annex Toshin Bldg, 4-36-19
Yoyogi
Shibuya-ku, Tokyo 151 Japan
Phone : +81 3 5351 0181
Fax : +81 3 5351 0185
e-mail : okubo@gctech.co.jp
END