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?}
------------------------------------------------------------------------
- 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@ccm.CL.nec.co.jp Principal Researcher C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232