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 http://www.itu.int you'll probably spot them.

-Gary

-----Original Message----- From: wmshen [mailto:wmshen@PUBLIC.WH.HB.CN] Sent: Tuesday, February 15, 2000 7:04 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: question on video transcoder or gateway

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