Weiming Shen et al,
The
only real way to translate in either direction in general is to decode
(including IDCT)
and
then re-encode. This is because H.261 cannot
represent the half-pel motion
used
in H.263, and H.263 cannot represent the loop filter in H.261. Unless you
can
somehow stop the original encoder from using features
that aren't found in both standards,
you're
stuck doing real transcoding. The re-encoding
complexity
can be
reduced significantly by re-using the motion vectors
and
prediction mode selections from the
incoming video rather than doing a new
motion
estimation in the re-encoder.
Since motion estimation and mode selection can
take
a lot
of processing power, getting rid of some of that can
help.
For
best performance it would be good to have the re-encoder do a local
refinement of
the
incoming motion vectors and to try different prediction
modes.
There
are standards for gateways and multipoint conferencing units. I don't
think they
give
much advice in them about this issue. I don't recall which standards those
are,
but if
you look at a list of the H-series standards list at www.itu.int you'll probably
spot
them.
-Gary
Hello, all
experts,
I am a Ph.D student
working on video communication. I am wondering about how the video
transcoder/gateway works between H.261 and H.263, and between IP network and
PSTN or ISDN, in paticular i wonder whether there is a method by which
bitstreams can be translated directly between H.261 and H.263
format.
Who knows the
technique details on above topics or where may i get some useful reference
infomation?
Any help will be
approciated.
Weiming
Shen