TX to EX is poorer quality than via TPS

[tunderhi]

Hi

I'm currently testing a setup where we have a TX9000 calling directly to a VCS registered EX (also C20s).  The quality of the direct call between the TX9000 and the EX / C20 is visibly poorer and in 4:3 format compared to when the call is bridged via the TelePresence Server.  When hosted on the TelePresence Server the call is 16:9 and better quality.  Photos attached to illustrate the difference. 

There is a bandwidth limitation of 512Kbps to all VCS registered endpoints, i.e. including the EX and C20s in question.  So regardless whether the call is direct or via the TPS the bandwidth limit is 512Kbps.

Can anyone explain this difference in quality?

Many thanks

Trevyn                  

[ahmashar]

the bandwidth limitation on VCS is just suggestion. As you mentioned whether the call is direct or via VCS, the bandwidth is always 512kbps. it's clear indication of the call bandwidth needs to be set from the endpoint before the call (you have that option). the reason you get better quality with TPS, it could be the clear-vision option key installed on the server.

do you have any pipe defined for subzones?

[Marius Nedregaard · Accepted solution]

Hi Trevyn

The 500 kbps limits video and audio, so experienced video on your endpoint will run at 384kbps.

I would like to start off with saying that running a call to a TX9000 with only 384kbps is NOT a supported bandwidth from the TX side.

In a point to point call the TX9000 will require a certain amount of bandwidth and resolution to properly decode the incoming media stream. For a TX9000 locked to a 720p call then the system need at least 1.5 mbps at average to perform sufficient.

With a 384kbps call, the resolution and bandwidth is not sufficient for the TX9000, I am actually surprised that the call go through.

The TelePresenceServer(TPS) uses DSPs to re-encode packet streams to match the connecting endpoint. The TPS is designed for interop and situations like this. I do not see it as strange that the TPS produces a much better picture, as the bandwidth-limited decoding is happening on the TPS rather on the codec ( the codec got less power and possibilities than the TPS )

I will try to illustrate this with a few examples, feel free to use the one that fit your setup. All payloads are examples and does not reflect real life scenarios.

EX < – 384kbps - payload 101 – SD Quality-> TX9000  

In the example above system uses a payload(codec) that fits the EX90 the best. Result quality will not be good

EX < -384kbps - payload 101 - SD Quality ->        TPS(reencode)                --384kbps - payload 97 – SD Quality -> TX9000 

In the example above the EX90 sends its “best negotiated payload” to the TPS

The TPS re-encode the media stream to the “best negotiated payload”  for TX9000 and picture produced will be better.

EX <-4000kbps - payload 101 - HD Quality->       TPS(reencode)                --384bps - payload 97 - SD Quality ->  TX9000 

In the example above EX90 uses HIGH bandwidth to the TPS, and TPS re-encodes the picture to fit the TX9000 resolution and codec support

The result is better picture.

EX <-384kbps -  payload 101 - SD Quality ->        TPS(reencode)                --4000bps - payload 97 - HD Quality -> TX9000

In the example above the limitation is only towards the TPS but not towards the TX9000. The resolution sent to the TPS will be SD but the resolution sent out from the TPS will be HD. This results I better picture.

The bottom-line is that the TPS is much stronger and much more agile than an endpoint codec. The TPS is designed to use with all resolutions and codecs, while then endpoint codecs got less power and need more bandwidth to handle the same task.  And also that 384kbps call is within TPS spec but NOT within TX9000 spec.

My recommendation would be to avoid running TX9000 calls at 384kbps as this is NOT supported by TX9000, the least supported bandwidth average for 720p on a TX9000 is 1.5mbps on average.

//Marius