Transcript
US006111924A
United States Patent [19]
[11] Patent Number:
McKinley
[45] Date of Patent:
[54] ERROR-CORRECTION-CODE
[75]
6,111,924 Aug. 29, 2000
Primary Examiner—Stephen Chin
SYNCHRONIZATION IN A
Assistant Examiner—Dac V. Ha
VIDEOCONFERENCING GATEWAY
Attorney, Agent, or Firm—Cesari and McKenna, LLP
Inventor: Brittain S. McKinley, Melrose, Mass.
[57]
[73] Assignee: VideoServer, Inc., Burlington, Mass.
ABSTRACT
A de-framer (72) in a communications gateway (22) trans lates videoconferencing information from a circuit-sWitched
21
Appl, No.1 09/018,246
format to a packet-switched format. A demultipleXor (78) extracts a bitstream containing video information that
[22]
Filed:
[51] [52]
Int. Cl.7 ...................................................... .. H04L 7/00 US. Cl. ........................ .. 375/354; 375/365; 375/366;
rnincd locations With respect to synchronization bits spaced by a Synchronization interval and forming a predetermined
375/368; 370/503; 370/509; 370/512; 370/513; 370/514; 714/758; 714/775; 714/789; 714/798
synchronization sequence. A frame checker (88) for check ing the error-correction code ?nds codeWord boundaries by
[58]
Feb‘ 3’ 1998
includes error-correction-code ?elds disposed at predeter
Field of Search ................................... .. 375/365, 366,
375/368; 354; 370/503; 509; 512; 513; 514; 714/54, 12, 707, 758, 775, 789, 798
[56]
References Cited
Us‘ PATENT DOCUMENTS
5,600,646
2/1997 Polomskl .............................. .. 370/263
5,903,619
5/1999
5,956,377
9/1999 Lang ..................................... .. 375/372
......................... ..
bitstream bits until it ?nds a match. To do so, the frame checker (88) takes a group of video-bitstream Words offset from each other by the synchronization interval. It compares
each WOI‘d~ 1n the group With a respective synchronization
WllklIlSOIl ............................. .. 5570370 10/1996 Lm """ 370/953 Claisemartin
comparing the predetermined synchronization sequence
With sequences of synchronization-interval-spaced video
Word consisting of a Word-Width replication of a respective Synchronization Enough Words resulting from the Com parisons are ORed together that the result Will be all ones unless each Videobitstream Word Contains a res ective
375/366
_
_
_
_
_
_
_ _
p
synchromzanon e“ m a correspendmg b1t_P°S1t1°n~ If the result does contain a zero, then it can be inferred that the
OTHER PUBLICATIONS International Telecomunication Union, “Video Codec for Audiovisual Services at p><64 kbit/s,” ITU—T Recommen
video bitstream contains synchronization bits in correspond ing bit positions‘
dation H.261 (Mar. 1993).
3 Claims, 15 Drawing Sheets
ADVANCE
GetPtr BY 1
LEAST 512 WORDS
IN BUFFER?
WITH WRAP CHECK
K102 TempPtr = Ptr Count = 0 Sum = O
DOES Sum HAVE ANY
zERos?
K146 SYNCHRONIZATION
ACHIEVED; FIND ZERO-BIT LOCATION AND SET IT AS THE REMAIN VALUE.
Index = (Index + Count) MOD 8 Comp = Table(|ndex) A *TempPtr
Sum: Sum I Comp TempPtr : TempPtr +16 Count : Count +1
TempPtr > BufEnd?
K150 TempPtr = TempPtr - BufSize
l__
U.S. Patent
Aug. 29,2000
Sheet 2 0f 15
6,111,924
H0cTET—+—0oTET——+—ocTET——>| VIDEO AUDIO DATA VIDEO AUDIO DATA VIDEO AUDIO DATA
VIDEO STREAM
s F
HDR
DATA
ECC
ECIIEROUPéOé BLZOCIZ
_
mNwo~m3£9k2$85om92: 2%v$R0N89m2So:2wo moomv m22
395P29503r0.5
[email protected]
$360.35 5$089 m@ow @emo
.QEo_\
503m505@cc8
g cc
U.S. Patent
Aug. 29,2000
Sheet 6 0f 15
NEWVORK BUS
6,111,924
BPU Bus BPU SWITCH
58\
58\
DSP1 A
5s\
DSP2 A
SRAM A
DSP1 B
SRAM B
60]
60)
58
5s\ DSP2 B
DSP1 c
5s\
58\
DSP2 c
DSPI D
SRAM c
58\ DSP2 D
SRAM D
61]
so] 32 BIT CP BUS
A4 SRAM CP
8 BIT MICROPROCESSOR BUS
020%:
A2 DSP _ SER
CP
HPU
MUX
36
INTERFACE EEROM
ISA BUS
FIG. 12
U.S. Patent
Aug. 29, 2000
Sheet 7 0f 15
6,111,924
QPI
.I,.. .r .->
I\
81x:
EMJrE05WE _1H5
_mamom
29Eu
mmm8%3w3%“
I\OZ>mw
m|.m
RXawwk
31Iw“ENm\m_10mEzoi_
EENMWE 5:NRE:wNs:Z10PEI|.v6_o/ WI. O_jEM5 mmx3w\zéwUol2z>w
mK-NMuE:RN 1LI50m3ug./‘0E NNK_
.L. .
MQmUE/‘3&1 Mwzamo
. .0E2
U.S. Patent
Aug. 29,2000
Sheet 8 0f 15
FIG. 14
6,111,924
U.S. Patent
Aug. 29, 2000
Sheet 9 0f 15
6,111,924
/ 158 ADVANCE1 I
Getptr BY
LEAST 512 WORDS IN BUFFER?
,
WITH WRAP
STOP
CHECK
f
102
TempPtr = Ptr Count = 0 Sum = 0
144
DOES Sum HAVE ANY
zERos?
K146 [154 SYNCHRONIZATION
ACHIEVED; FIND ZERO-BIT LOCATION AND SET IT AS THE
REMAIN VALUE.
Index = (Index + Count) MOD 8 Comp = Table(lndex) A *TempPtr
Sum: Sum | Comp TempPtr : TempPtr +16
CO unt = .Co unt +1 148
f 156
TempPtr > BufEnd?
r150 TempPtr = TempPtr - BufSize
FIG. 15
100
U.S. Patent
Aug. 29,2000
104 K
PutRemain = PutRemain + n
l
Temp = Bits SHIFT Temp BY PutRemain PutWord = Temp | PutWord
108 x “i
6,111,924
1
106
\
Sheet 10 0f 15
m
*PutPtr = PutWord PutPtr = PutPtr + 1
112
PutPtr = BufEnd? 1A
PutPtr = BufStart
PutRemain = PutRemain + 32
[5
SHIFT Bits BY GetRemain PutWord = Bits
'
RETURN
FIG. 16
109
U.S. Patent
Aug. 29, 2000
6,111,924
Sheet 11 0f 15
@
122
GetRemain = GetRemain + n
i
124
RetVal = *GetPtr
SHIFT RetVal BY GetRemain 126 \
GetRemain 2 0? 129
GetRemain = GetRemain-32 130
l GetPtr = GetPtr + 1
NO
GetPtr = BufEnd?
YES GetPtr = BufStart 136
Temp = *GetPtr 138
SHIFT Temp BY GetRemain l RetVal = RetVal | Temp
Mask = FFFFFFFFH LEFT SHIFT Mask BY n
RetVal = Mask | RetVal /~— 128
RETURN RetVaI
FIG. 17
U.S. Patent
Aug. 29,2000
Sheet 12 0f 15
6,111,924
166
r170
WAS THE SOURCE BIT
RESET THIS ROUTINE __
BUFFER RESET?
DOES THE BIT BUFFER CON TAIN DATA?
K188 IS THE CURRENT WORD DONE?
YES
FETCH A NEW 32-BIT WORD FROM THE
SOURCE BIT BUFFER
f
NO
186
WRITE FETCHED BITS TO THE PACKET IF THERE IS ONE.
1
K190
SEARCH FOR N ZEROS FOL LOWED BY A ONE. (N=15 FOR H.261 AND 16 FOR H.263)
r212 WAS TH PATTERN FOUND?
NO
COMPUTE STARTING BIT LOCATION OF PAT-
2
TERN. EXTRACT GOB# J AND HEADER (PS0)
(5
14
FIG. 18A
U.S. Patent
Aug. 29, 2000
Sheet 13 0f 15
6,111,924
K218
216
DID THE LAST GOB END
BAZZLIJDPLEEQTTERS
BEFORE THE CURRENT WORD?
COUNTS
NO r220 COMPUTE END BIT VALUE FOR
CURRENT PACKET, COIvIPUTE START BIT FOR NEXT PACKET
Is THERE A CURRENT PACKET?
r226 IS THE
224
GOB BOUNDARY A no TURE BOUNDARY? (GOB# = 0)
YES
SET T|ME STAMP AND SEND MES SAGE ABOUT VIDEO FORMAT CHANGES
NO
[
CLEAR UNUSED BITS, SET UP PACKET HEADER, )228 AND LOAD PACKET’S CONTROL FIELDS
ALLOCATE NEW PACKET AND lNlTlALlZE IT 330 236
'
/234
F
CLEAN UP CURRENT WORD
CLEAN UP
DID THE PATTERN START IN PREvIOUs WORD?
l
LAST WORD AND WRITE IT TO PACKET
l /-238
WRITE CURRENT WORD TO PACKET
% €240
FIG. 18B
U.S. Patent
Aug. 29,2000
Sheet 14 0f 15
6,111,924
wt/
Hx3GuE6£W|82wé>MmQ3nSV @t\#2 532E:6.051m8%92:
UL5I@0N956:2%E04$?a m w l “_ w /
amwdnvlmcE;Noqi
mmESmQlIcEnoQ
.@E9
U.S. Patent
Aug. 29,2000
Sheet 15 0f 15
6,111,924
f194
V
ADD CURRENT BYTE’S LEADINGZERO-TABLE ENTRY TO ZERO COUNT
1 O
lYES YES
ZERO COUNT AT LEAST
ZERO COUNT =
CURRENT BYTE‘S
TRAILING-ZERO- 306 TABLE ENTRY r 204
L
7
PATTERN_FOUND=TRUE
r200 60 TO YES NEXT '—_
BYTE
ANY
198
MORE BYTES IN
WORD?
NO
r208
PATTERN_FOUND=FALSE NO 4 w
FIG. 20
6,111,924 1
2
ERROR-CORRECTION-CODE SYNCHRONIZATION IN A VIDEOCONFERENCING GATEWAY
Word, and this operation is repeated a number of times equal to the length of the synchroniZation sequence. If the Word-length video-bitstream sequence, With Which the operation started contains a synchroniZation bit, then the
BACKGROUND OF THE INVENTION
sum Word Will still have a Zero in the corresponding bit at the
end of many OR operations. OtherWise, all bits Will be ones, and the operation is repeated, beginning With a neW Word Width sequence. Operation proceeds in this manner until synchroniZation is achieved, as indicated by a Zero in the
The present invention is directed to video communica
tions and in particular to achieving synchronization in error-correction-coded video bitstreams.
Digital video communications transmit large amounts of information, Which can be vulnerable to corruption in the communication process. To reduce this vulnerability, it is commonplace to add redundancy to the data. The result is a sequence of code Words, each of Which consists of a
predetermined number of bits of the original, non-redundant video data concatenated With error-correction-code (ECC)
10 sum Word.
Employing this approach enables the system to expedite the synchroniZation process by taking advantage of the microprocessor’s Word Width. 15
bits generated from those data to bear a predetermined
The invention description beloW refers to the accompa
relationship to the data bits. If they do not, the receiving
nying draWings, of Which:
node can conclude that an error has occurred. In many cases,
FIG. 1 is a block diagram of a communications topology
the code is so constructed that the receiving node can not only detect errors but also correct them in most cases.
of the type in Which the videoconferencing gateWay of the
present invention Will typically be employed;
In order to take advantage of these features, the receiving
FIG. 2 is a diagram that illustrates the format of a video
node has to determine Where one code Word ends and the next one starts. A mechanism for achieving this “synchro
niZation” is for each code Word to be preceded by a single synchroniZation bit so chosen that the synchroniZation bits preceding successive code Words form a predetermined
BRIEF DESCRIPTION OF THE DRAWINGS
stream of the type that the gateWay of the present invention
Will typically process; 25
synchroniZation sequence. Suppose, for instance, that the length of a code Word is 511 bits and each code Word is preceded by a synchroniZa
FIG. 3 is a diagram illustrating the format of a typical link-level packet used to transmit the video stream; FIG. 4 is a diagram illustrating the RTP header of FIG. 3; FIG. 5 is a diagram illustrating the header of a single
picture portion of the video stream; FIG. 6 is a diagram of a single picture’s division into
tion bit so that every 512th bit is a synchroniZation bit. If the
groups of blocks (“GOBs”)
synchroniZation sequence is relatively long, then if every 512th bit after a given candidate bit forms With it the
FIG. 7 is a diagram illustrating the header of a GOB
predetermined synchroniZation sequence, the receiving node
portion of the video stream; FIG. 8 is a diagram illustrating a single-GOB picture
can conclude With a relatively high degree of con?dence that the candidate bit is indeed a synchroniZation bit. For
35
segment’s division into subregions represented by respec tive “macroblocks”;
instance, if the synchroniZation sequence is thirty-tWo bits long, there is less than one chance in four billion that a bit other than a synchroniZation bit Will form With every ?ve
FIG. 9 is a diagram illustrating a macroblock header; FIG. 10 is a diagram illustrating a macroblock region’s
hundred tWelfth bit thereafter the predetermined thirty-tWo bit synchroniZation sequence. So the synchroniZation-bit approach to ?nding code-Word boundaries can be quite
coverage by its constituent blocks; FIG. 11 is a diagram of a multipoint control unit (“MCU”) of a type that can embody the present invention; FIG. 12 is a more-detailed diagram of the bridge process
reliable.
Unfortunately, it can also be quite time-consuming. Basically, candidate bits must be fetched from, say, thirty tWo Widely spaced positions in the received data record. The resultant sequence must then be compared With the expected synchroniZation sequence, and the process must be repeated
45
FIG. 13 is a data-?oW diagram used to describe the bridge
processing unit’s implementation of the present invention; FIG. 14 is a conceptual logic diagram of the synchroni Zation operation performed by FIG. 13’s process 88;
until a match is found.
FIG. 15 is a How chart of a routine for implementing that
SUMMARY OF THE INVENTION
operation in softWare;
We have developed a Way of greatly expediting this process. Our approach reorders the operations in such a
FIG. 16 is a How chart of a routine for storing data in FIG.
13’s bit buffer 84;
manner as to take advantage of a microprocessor’s datapath
Width. Speci?cally, rather than initially form a
FIG. 17 is a How chart of a routine for fetching data from 55
synchronization-sequence-length (in the example, thirty tWo-bit-long) bit sequence by fetching bits from locations separated by the code-frame frame length (512 bits in the
FIG. 19 illustrates the data structure of FIG. 13’s packet
buffer 164; FIG. 20 is a How chart of FIG. 18A’s step 190; and FIG. 21 is a diagram of FIG. 3’s H.261 header.
parison is saved as the initial value of a sum Word, and the
parison is ORed With the sum Word to produce a neW sum
FIG. 13’s bit buffer 84; FIGS. 18A and 18B together form a How chart of FIG.
13’s packetiZing process 162;
example), We simply start With a Word-length sequence of consecutive bits from the incoming video bitstream and compare them With a Word-length replication of one of the synchroniZation-sequence bit values. The result of the com
operation is repeated With a sequence extracted from the bitstream at a location displaced from the ?rst sequence’s location by the code-frame length. The result of that com
ing unit depicted in FIG. 11;
65
DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT
Terminals 12 in FIG. 1 that employ the public sWitched
telephone netWork for videoconferencing, for instance by
6,111,924 3
4
using the Integrated Services Data Network (ISDN) 14,
concatenates the rest into a bitstream that it packetiZes for
typically comply With Recommendation H.320 of the Inter
transmission in accordance With the RTP protocol. To place the packetiZation task in context, FIG. 3 illus trates a typical link-layer packet. If Ethernet is used for the
national Telecommunications Union’s Telecommunication
Standardization Sector (ITU-T). Terminals 16 that employ
link layer, the information is sent in an Ethernet frame that begins and ends With an Ethernet header and trailer, Which
packet-sWitched netWorks such as the Internet 18 instead
comply With that organiZation’s Recommendation H.323. To represent the videoconferencing nature of the arrangement, FIG. 1 includes multipoint control units (MCUs) 20, Which both standards require to provide certain organiZational
capabilities.
are used for sending the information to the next stop on the same local netWork. For Internet use the frame’s contents are
an Internet Protocol (IP) datagram, Which includes its oWn 10
To enhance videoconferencing ?exibility, a gateWay 22 can be provided to translate betWeen the tWo
15
plexed video, audio, and data information. (These “frames”
20
each of the eight octet bit positions can be thought of as a
separate subchannel Within the frame; in general, certain bits of a given octet Will contain video information, certain Will contain audio information, and certain may contain data, as FIG. 2’s ?rst roW illustrates. Additionally, the eighth bit in certain of a frame’s octets (not shoWn in the draWings)
25
speci?ed in RFC 1889, that gives this and other information. assembling the RTP header as Well as a further, H.261
apparent after We describe the structure of the data stream 30
being packetiZed. Before We turn to that description, hoWever, We Will ?rst
consider the RTP header format, Which FIG. 4 depicts as successive four-byte roWs. RFC 1889 describes the various FIG. 4 ?elds’ purposes in detail, so We Will mention only the
employs separate RTP sessions to communicate a confer 35
lation from H.221 to RTP therefore involves demultiplexing the H.221 data stream into its video, audio, and data con stituents so that the gateWay can packetiZe the video, audio,
and data separately. The present invention is directed par ticularly to performing the protocol translation for the con
Since packet-sWitched protocol data units do not in gen eral arrive in order, and since real-time information must be presented in a predetermined time sequence, the UDP pay load must include information specifying the sequence in Which the information Was sent and its real-time relationship to other packets. So the payload begins With an RTP header,
header, speci?ed in RFC 2032, Whose purpose Will be more
Request For Comments (RFC) 1889. An H.323 terminal ence’s video, audio, and data portions. The gateWay’s trans
streams, though, it speci?es the User Datagram Protocol
The present packetiZation discussion concerns itself With
represents control information by Which, among other things, frame boundaries can be recogniZed. The precise bit allocation is determined during a session negotiation process among the involved videoconferencing terminals. In contrast, H.323 terminals employ the Real-time Trans mission Protocol (RTP) set forth in the Internet community’s
as the protocol for directing the information to the desired application at the destination Internet address. For video
(UDP), so FIG. 3 depicts the IP payload as a UDP datagram, Which includes a UDP header speci?ed in RFC 768.
should not be confused With video frames, Which We Will hereafter refer to as “pictures” to distinguish them from transmission frames.) Each frame consists of one or more
channels, each of Which consists of eighty octets of bits, and
its ultimate inter-netWork address. For some parts of the
videoconference information, RTP speci?es that the Trans port Control Protocol be used as the transport protocol, i.e.,
standards’protocols. Communications from H.320 terminals typically conform to the ITU-T H.221 standard, in accor dance With Which information travels in “frames” of multi
header, speci?ed in RFC 791, for directing the datagram to
40
timestamp ?eld, Which is particularly relevant here. When information travels by Way of a packet-sWitched netWork, different constituent packets make their Ways to their com mon destination independently. That is, different packets can take different routes, so the times required for different packets to arrive at their respective destinations are not in general the same, and packets can arrive out of sequence or
ference’s video portion.
in time relationships that otherWise differ from those With Which their contained information Was generated. Moreover,
The video bits are extracted from a succession of octets
and concentrated into a stream that thereby contains only the
the UDP sessions in Which the video data are sent typically H.221 transmission’s video part, Which Was encoded at the 45 are not the ones used to send the audio that is to be played source in accordance With ITU-T Recommendation H.261. With it. RTP therefore provides for a timestamp in each
(Alternatively, it may have been encoded in accordance With a related recommendation, H.263. Although the present invention’s teachings are equally applicable to such streams, We Will concentrate on H.261 in order to avoid complicating 50
the presentation unnecessarily.) In accordance With H.261,
packet to indicate the real-time relationships With Which the information is to be played. In contrast, although video arriving at the gateWay in an H.221 stream Will have been digitiZed and typically time division multiplexed, it Will have been sent over a circuit
that stream is a sequence of error-correction-coded frames,
sWitched channel, so a common frame Will contain both a
of Which FIG. 2’s third roW illustrates one.
video segment and the audio segment to be played With it. H.221-stream timing relationships are therefore implicit: the H.221 data stream coming into the gateWay needs no explicit timestamp and therefore has none. So the gateWay consults a local clock to provide the RTP-required timestamp as it
Each frame begins With a synchroniZation bit (“S”) and a ?ll bit (“F”). The gateWay uses the synchroniZation bit in a manner described beloW to recogniZe the ECC-frame boundaries, and the ?ll bit indicates Whether, as is some times required, the frame contains no actual information but
55
assembles the outgoing packets.
is being sent to meet certain system timing requirements. The ?ll bit is folloWed by a 492-bit data or ?ll ?eld and an eighteen-bit ECC ?eld Whose contents are generated on the preceding 493 bits (i.e., on a bit group that excludes the
synchroniZation bit) in accordance With a (511, 493) BCH code that H.261 speci?es. For forWarding into a packet-sWitched netWork, the gate Way discards the synchroniZation, ?ll, and ECC ?elds, as Well as any data ?elds identi?ed as being only ?ll, and
Without more, though, it Would be complicated to play the 60
resultant timestamped information. If no notice Were taken
of the actual contents of the data stream being packetiZed, for example, a single packet could contain parts of tWo different video pictures, so parts of the same picture Would have the same timestamp, While different parts of the same 65
picture could have different timestamps. To avoid this, the gateWay described here monitors the data stream for picture boundaries, as Will noW be described.
6,111,924 5
6
FIG. 2’s fourth through seventh roWs depict the structure that the incoming data stream uses to represent successive video pictures in accordance With H.261. The fourth roW illustrates a data-stream portion covering a single vide
tion admits of a variety of data-compression techniques.) FIG. 2’s sixth roW shoWs that each macroblock has its oWn
header, and FIG. 9 illustrates that header’s structure. The header’s MacroBlock Address (MBA) ?eld contains a variable-length code for the difference betWeen the current macroblock’s address and that of the previously sent GOB’s block (since not all macroblocks are sent for every GOB). The MTYPE ?eld speci?es the manner in Which the current macroblock’s data Were encoded; the data may be the result of comparing the raW data With a neighbor macroblock’s
picture. It shoWs that the portion begins With a header, and FIG. 5 illustrates that header’s structure.
The header ?eld of importance here is the Picture Start Code (PSC). For H.261 streams, that ?eld value is alWays 00010H, a sequence that cannot occur elseWhere in the data
stream. To avoid having packets straddle picture boundaries,
data, With the corresponding data from a previous picture,
the gateWay begins a neW packet Whenever it encounters the PSC sequence. In the case of a packet containing the PSC sequence, the
With ?ltered versions of either of them, etc. If an MQUANT
?eld is present, its contents supersede the default quantiZa tion that the GQUANT ?eld in the enclosing GOB’s header
gateWay determines the timestamp simply by consulting the current local-clock output. But the length of a single-picture
15
speci?es.
portion of the data stream typically exceeds the underlying protocol’s maximum-transmission-unit siZe, so the gateWay breaks a single picture’s data into multiple packets. For such
The CBP ?eld speci?es the macroblock’s constituent “blocks” for Which the macroblock ?eld contains data. There are at most six such blocks. The ?rst four represent the
packets, the timestamp entered is the same as that assigned
luminance (Y) information from respective segments of a macroblock subregion divided as FIG. 10’s left rectangle
to the last PSC-containing packet. The gateWay is also judicious in its selection of locations
illustrates. The ?fth and sixth block ?elds represent more
at Which it breaks a picture’s data into packets. The reason
sparsely sampled blue (CB) and red (CR) color-difference
for this can be appreciated by revieWing the picture data’s
values covering the Whole macroblock region, as FIG. 10’s center and right rectangles indicate. Each block ?eld’s
?ner structure. As FIG. 2’s fourth roW indicates, the picture
data’s body portion is divided into “groups of blocks”
25 contents are coefficients of an 8x8 discrete cosine transform
of the data that remain after any subtraction by previous
(GOBs). H.261 speci?es a Common Intermediate Format (CIF) into Which, say, an originally 525- or 625-line (or other) source representation is resampled to generate the H.261 representation, and each GOB represents one-tWelfth of the resultant picture area, in a spatial relationship that
In short, the data interpretation for each macroblock depends greatly on its header and that of the enclosing GOB. This Would complicate decoding at the receiving end if
image data.
FIG. 6 illustrates. H.261 also speci?es an alternative, more
packets Were alloWed to start betWeen block or macroblock
sparsely sampled “QCIF” format. When QCIF is employed,
boundaries; the decoding of a given packet’s contents Would
each GOB represent one-third of the total picture area. And the present invention’s principles are applicable to other formats, too, such as those that H.263 speci?es.
headers. To avoid such a complication, the illustrated gate
have to aWait reception of packets containing the requisite 35
FIG. 2’s fourth roW depicts the GOB ?elds as being
unequal in length. This is because the degree of H.261 speci?ed data compression depends on the source picture’s data redundancy, Which can differ from region to region.
Way begins packets only at GOB boundaries. Although FIG. 1 depicts the gateWay 22 as separate from the MCIJs 20, the gateWay can be implemented in an MCU, such as the MCU illustrated in US. Pat. No. 5,600,646 to
FIG. 2’s ?fth roW shoWs that each GOB ?eld has its oWn header, and FIG. 7 illustrates a GOB header’s structure. The
Polomski, Which We hereby incorporate by reference. FIG. 11 depicts the major constituents of such an MCU adapted in accordance With the present invention’s teachings. Par
GOB header begins With a Group-of-Blocks Start Code
ticipants in a teleconference employ codecs 38 to generate
audio, video, and/or data signals that they send over various
(GBSC). That code’s value is 0001 H, a sequence that cannot
occur elseWhere (except in the PSC). The gateWay described
45
here monitors the data stream for GBSC sequences and begins a neW block only at such sequences. To appreciate Why it does so, We revieW the rest of the data stream’s structure.
The GOB’s Group Number (GN in FIG. 7) folloWs the GBSC code and speci?es the GOB region’s position in accordance With the FIG. 6 scheme. Next is a default
quantiZation value GQUANT, Which in?uences the con
unit 46 performs the distribution by obtaining signals from
tained data’s interpretation by specifying the magnitude intervals at Which the values Were quantiZed. The header
communications media 40a—c to the MCU for appropriate distribution to other participants. FIG. 11 adapts the Polomski arrangement so that it can communicate not only over circuit-sWitched networks, such as T1 or ISDN, but also packet-sWitched netWorks, such as the Internet. NetWork interface units 42a—c perform the loW-level processing necessary to extract the information from respective media and apply it to respective channels on the netWork or PCI/ISA bus 44 or 56. A bridge processing
55
various of that bus’s channels and applying appropriately
so-called macroblocks, Which correspond to subregions
processed versions thereof to others of its channels for re-transmission. The signals to be transmitted may have resulted from the
Within the GOB regions. FIG. 8 illustrates a single-GOB
bridge processing unit 46’s having ?rst exchanged the
may additionally contain further, optional ?elds. FIG. 2’s ?fth roW shoWs that a GOB is divided into
picture segment’s division into subregions represented by
received signals over an interprocessor bus 48 With a video
respective macroblocks. Although there are thirty-three such subregions in a GOB-represented region, FIG. 2 depicts someWhat feWer macroblocks than that, because macrob
processing unit 50 or other data processing unit 52 in order,
locks that are redundant in vieW of previous macroblocks can be omitted in accordance With H.261. (As those familiar
mon picture. In accordance With the present invention, moreover, the bridge processing unit 46 may perform an inter-protocol translation, as Will be further described beloW. A host processing unit 54 employs an Industry Standard
With the H.261 speci?cation Will recogniZe, previous may have either a temporal or a spatial meaning; that speci?ca
say, to mix tWo sources’ information into a composite signal so that tWo participants’ images are combined into a com 65
6,111,924 7
8
Architecture bus 56 to exercise control over the various
routine forms a longer, thirty-tWo-bit alignment sequence consisting of four repetitions of H.261 ’s eight-bit pattern. It
elements, partially in response to information received from the netWork interface units 42a—c. As the Polomski patent describes in more detail, the core
then conceptually loads the contents of FIG. 13’s bit buffer
84 into FIG. 14’s 16K-bit-long (conceptual) shift register 90 and, as thirty-tWo (again, conceptual) XOR gates 92
of the bridge processing unit 46 is a group of digital signal processors (DSPs) 58 shoWn in FIG. 12. The DSPs operate in pairs Whose constituent processors are labeled “DSPl”
and “DSP2.” Those labeled “DSPl” primarily perform aspects of interfacing With the netWork bus 44, While those labeled “DSP2” perform processing more closely connected
10
With transfers over bus 48 to other processor pairs. Each pair is associated With a respective conference participant. A respective static RAM 60 is associated With each DSP
pair and provides fast shared-memory communication betWeen the pair’s constituent DSPs. It also provides shared
15
indicate, compares every 512th bit With a corresponding bit of the long alignment sequence. If all the bits match, a NOR gate 94 produces a true output. A true output is a relatively reliable indicator that the BCH-frame boundaries have been found; the probability is less than one in four billion that thirty-tWo randomly chosen bit values Will form four successive repetitions of the alignment pattern. So the steady-state mode of FIG. 13’s process 88 can begin if NOR gate 94’s output is true.
OtherWise, the synchroniZation process repeatedly
mon control DSP 62, Which performs higher-level, less
advances the shift register’s contents by one bit and repeats the comparison until it ?nds a match. FIG. 14 shoWs the
time-sensitive tasks. That processor in turn has access to a
shift-register state after n such advances.
memory communication betWeen the DSP pair and a com
further memory 64, to Which the host processor 54 (FIG. 11) also has access by Way of an ISA interface unit 66. The Polomski patent describes most of these and other compo
nents’ operations in detail, so We Will describe only of the gateWay-function programming that We have added. FIG. 13 illustrates the gateWay-function data ?oWs. Blocks Within dashed lines 70 represent processes that a
20
of FIG. 1. Dedicated-circuitry use Would not take advantage 25
FIG. 12 DSP pair’s “DSPl” member performs. Process 72
is a conventionally performed operation of determining Where the 80n-octet H.221 frame boundaries occur. Once those boundaries are located, one can determine the bit
locations of command and capacity codes (not shoWn in FIG. 2’s ?rst roW), some of Which specify the video infor
Unfortunately, it usually is not practical to obtain this
reliability by the straight-forWard approach that the bit stream organiZation suggests, i.e., by implementing the synchroniZation process in dedicated logic circuitry like that
30
of the signal-processing circuitry that the system Will already have for other purposes. In the absence of the present invention’s teachings, on the other hand, an algo
rithmic approach, Which is necessary if the system’s general purpose digital-signal-processing circuitry is to be employed, could seriously detract from that circuitry’s abil ity to perform its other tasks. But We have found that We can
so reorder the synchroniZation process’s operations as to reduce this burden to a small fraction of What it Would be otherWise. FIG. 15 depicts the Way in Which We achieve this can generate and place into the respective RAM 60 (FIG. 12) a table 76 containing masks and related information that a 35 reduction. de-multipleXing operation 78 uses to perform the video FIG. 15 illustrates a synchroniZation routine that FIG. stream extraction that the transition betWeen FIG. 2’s ?rst 13’s process 88 calls periodically until it achieves synchro and second roWs represents. Dashed lines 80 indicate that a niZation. As blocks 98 and 100 indicate, the synchroniZation “DSP2” member of a DSP pair performs the de-multipleXing routine ?rst determines Whether FIG. 13’s bit buffer 84 mation’s bit positions. From this information a process 74
operation 78. Dashed lines 82 indicate that their included processes are performed by FIG. 12’s control DSP 62 or
40
contains 512 thirty-tWo-bit Words, i.e., enough bits to ?ll FIG. 14’s conceptual shift register 90. If not, the synchro
FIG. 11’s host processor 54. In particular, DSP 62 performs
niZation process stops until its neXt invocation. But once
the capability/command processing 74. The demultipleXing process produces video, audio, and data steams that undergo various processing before being
into the bit buffer 84, the FIG. 15 routine advances to step
FIG. 13’s demultipleXing process 78 has placed enough bits
present purposes, We Will consider only the video stream’s
102, in Which it obtains a value GetPtr from a control structure in buffer 84. To eXplain GetPtr’s function, We digress to a discussion of bit buffer 84, Which is imple
processing. That processing places the stream represented
mented as a circular buffer in a block of FIG. 12’s RAM 60
45
placed in their respective IP datagrams for transmission. For by FIG. 2’s second roW into a bit buffer 84. During steady state operation, a BCH frame-checking process 88 veri?es that the synchroniZation bits are Where they are eXpected to
memory assigned to that purpose and accessed by reference 50
be and checks the ECC (FIG. 2’s third roW). If all is in order, it then discards the contents of the sync, ?ll-indicator, and ECC ?elds, as Well as any data-?eld contents tagged by the ?ll-indicator ?eld as ?ll, and places the remaining bits into a successor bit buffer 89 (FIG. 13). Initially, though, process 88 does not “knoW” Where to look for the BCH ?eld boundaries. So before it begins its
steady-state function, it performs a synchroniZation routine Whose principle FIG. 14 depicts conceptually. As Was
to the associated control structure. We call buffer 84 a bit buffer because it is an object
implemented by methods that calling processes can use to add or remove numbers of bits that do not constitute Whole
numbers of memory Words. This individual-bit approach 55
employs a control-structure location PutWord in addition to the main bit-buffer storage locations. Received bits are Written into a main bit-buffer memory location only When enough bits have been received to make a complete memory
Word. In the interim PutWord receives neWly received bits in 60
its leftmost unoccupied bit positions.
explained above in connection With FIG. 2’s third roW, a
More speci?cally, the buffer’s bit-storage method takes as
synchroniZation (S) bit precedes each 511-bit (data plus
tWo of its arguments the number n of bits to be stored and
ECC) BCH code Word. In accordance With H.261, succes
an unsigned thirty-tWo-bit Word Bits Whose n right-most bit positions contain the bits to be stored and Whose other bit
sive frames’ synchroniZation bits-i.e., a ?rst synchroniZation bit and every 512th data-stream bit thereafter-repeatedly form a frame-alignment sequence SOS1S2S3S4S5S6S7= (00011011). To detect this sequence, the synchroniZation
65
locations contain Zeroes. As FIG. 16’s blocks 104 and 106
indicate, that routine begins by subtracting n from a control structure value PutRemain, Which before the subtraction
