Section_8.3_rev to include point-to-multipoint VC connection configuration (root initiated join)

[Li Yan]

Dear Mr. Okubo and other Q.12/16 experts,

This is a draft for the clock synchonization section.

It is a contribution as one of Q.12 experts, not an editor.
Although attached text is not yet complete, I would like to hear the
comment/suggestion from other experts.

{Assumption:
 I guessed that a highly stable 27MHz clock is only recoverable when a
 common network clock is available. The common  network clock
 availability, however, seems to be impractical especially in
 customer premises ATM network environments, I would like to propose
 clock synchonization/adaptation shall be achieved solely in an
 H.bmultipoint MCU. }

------------------------------------------------------------------------
7.5 Clock synchronization

7.5.1 General

There are two independent clock sources need to be considered in
H.bmultipoint conference:

1)  27MHz system time clock (STC) in each H.310 terminal and MP,
2)  transmission clock for the multiplexed stream.

Recommendation H.310 leaves STC synchronization as further
study, current H.310 terminals may generate their STCs as follows:

1) by a local oscillator (local master),
   Note: In this case a frame synchronizer for video input
   or a video camara with clock reference input is necessary.
2) by referencing video input (video slave),
3) by referencing network clock (network slave),
4) by referencing recovered system_clock_frequency of the decoder
   (receiver slave).

Transmission clock synchronization is also left as further study,
the followings are possible to generate transmission clock in each
terminal and MCU:

1) by referencing common network clock (common network clock),
2) by referencing receiver clock (local network clock),
   Note: Local ATM switch generates the network clock, not referencing
   public B-ISDN network clock.
3) by a local oscillator (local oscillator),
4) by referencing video input (video input).

7.5.2 STC generation in MP

STC frequency in an MP shall conform to H.222.0 Section 2.4.2.1.  PCR
tolerance due to PCR modification during re-multiplexing in the MP shall
conform to H.222.0 Section 2.4.2.2.

Since there exists the case that STC frequency in each terminal is
independent, MP shall adjust the difference.  One possible implementaion
is to equip a frame synchronizer for video and sample clock synchonizer
for audio.  MP may use a recovered STC of a selected peer as a
re-multiplexing STC source, only if the stability of the recovered STC
satisfies H.222.0 requirements.  The ITU-T Timing Descriptor defined in
H.222.1 will help the STC recovery process.  When the recovered STC is
used and video is switched, PCR discontinuity happens.  Within a certain
period of time after the PCR discontinuity, frame skip or repeat and/or
audio discontinuity may occurs by the PCR clock recovery and AV
synchronization processing.

7.5.3 Transmission clock synchronization

Common network clock is not always available to all of the terminals.
It is especially true in customer premises ATM networks.
Thus, H.bmultipoint MCU and terminals shall operate under the
environment that each terminal has its own transmission clock source.
The receiver side of the MCU and each terminal shall recover the
transmission clock by the method indicated through AAL paramter IE.

{Source clock frequency recovery method IE only exists in AAL1?
 How can we inform the source clock frequency recovery method when we
 use AAL5?}

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

> 4. Bit rate management
>
> We will need a sub-section in Section 7 which addresses how to manage
> elementary stream and multiplexed stream bit rate, particularly in the
> switched video environment. The description may not be normative, but
> give some guidance to the implementors.

Yes, I agree.  FlowControlCommand can be used to limit the bit rate of
video elementary stream. Is it apparent that a multiplexer will insert TS
null packets to fill the transmission bit rate?

I will try to describe some text tomorrow.

Hideh

Hidenobu Harasaki           harasaki at ccm.CL.nec.co.jp
Principal Researcher        C&C Media Research Labs., NEC Corporation
                            Phone: +81 44 856 8083    Fax: +81 44 856 2232