c40 reverts to XGA/QCIF mid call

[Nicholas Holum]

Hello, I have a c40 that continues to baffle me.

I call into my MCU 4510 via SIP at 768kps, and it connects with a 1280x720 resolution.

However, it eventually reverts to XGA ... usually after several minutes.

This particular c40 used to be connected to two LCD displays. And I don't believe this problem ever occurred with that configuration. We moved it to another room which was equipped with projector. I am not certain if the problem started happening immediately after this move. I have updated the software several times since the move, and obviously it has't helped. So maybe this is some type of HDMI and/or scaler problem?

[Wayne DeNardi · Accepted solution]

The call may downscale depending on the available bandwidth, or bandwidth conditions between the ends of the call.

It can also be affected by the quality settings on the endpoint and whether you are giving preference to Motion (at a higher frame rate) or Quality (at a lower frame rate).

Have a look and compare your settings to those listed on page 126 in the Admin Guide around quality and frame rates, and the bandwidth requirements for what you require.

From what you have described, it sounds like it is possibly changing from 30fps to 60fps as there is motion in the video (and, as per the table, changing from 1280x720p30 to 1024x576p60), or due to poor conditions, dropping from a "High" profile 1280x720p30 to a "Normal" 1024x576p30.

[Nicholas Holum]

Wayne, this seems to have worked.

I set the "Optimal Definition" to...

Profile = High

Threshold60fps = 1920_1080

It has been connected at 2048kbps for a couple hours now, and has maintained its resolution the whole time.

[PJMack]

This problem doesn't have anything to do with the displays you are using, the codec doesn't "know" that. I'd bet you are getting significant packet loss on your initial call and it's downgrading the resolution to try to deal with it, the codec and MCU will do that by design. 

Here's my guess - you moved rooms, yes? So a new switch port, my guess is the ports aren't configured the same, you either went from a port that was set to auto negotiate to one that's forced to 100/full or vice versa. Your C40 has to be set to the same setting as the port you are plugged into or you will get a duplex mismatch which will cause packet loss and downgrading of your calls. 

Here's how that works - if the switch and codec are both set to 100/full, you have no problem. However, if the switch is set to 100/full and your codec is set to auto negotiate, the codec will get the speed right, but when it doesn't negotiate the duplex it will default to half and you'll have the mismatch. The reverse is also true. This is the case for any network device BTW, not just video systems, it's just that video isn't as tolerant of packet loss as data would be. 

Try your call and look at the call stats, assuming you are getting packet loss you could try simply changing however the C40 is currently configured to the opposite, or work with your network resource to make sure they are set the same. Generally leaving both the switch port and codec on auto is fine, but old school guys might want to force the speed/duplex, which is fine too as long as they are the same. 

Hope this helps. 

[Nicholas Holum]

That's for your responses!

I captured some stats at the moment the camera reverted to XGA.

Here is what I captured from the MCU...

Receive stream H.264, 176 x 144 (QCIF), Non-interleaved mode
enhanced to 352 x 288 (CIF), Non-interleaved mode
Receive address 10.15.173.100:61028
Encryption AES-128
Channel bit rate 2.00 Mbit/s
Receive bit rate
64.0 kbit/s (actual=4.74 kbit/s)
Received jitter 6.0 ms (buffer=20.0 ms)
Delay applied for lipsync 0 ms (RTCP delay=-24 ms)
Packets received 15096
Packet errors 29
Frame rate 30.0 fps
Frame errors 17 / 10057
Transmit stream H.264, 1024 x 768 (XGA), Non-interleaved mode
Transmit address 10.15.181.241:2348
Encryption AES-128
Channel bit rate 704 kbit/s
Transmit bit rate
704 kbit/s (actual=698 kbit/s)
Packets sent 52880
Frame rate 30.0 fps
Temporal / spatial 18

...and here is what I captured from the codec itself...

Call
Protocol SIP
Transmit call rate 768 kbps
Receive call rate 768 kbps
Encryption AES-128

Video Transmit Receive
Protocol H264 H264
Resolution 176x144 1024x768
Frame rate 30 fps 30 fps
Channel rate 2000 bps 694 kbps
Total packet loss 0.2% 0.0%
Current packet loss 0.7% 0.0%
Jitter 0 ms 14 ms

The switchport is Full-duplex, 1000/Mb/s

No errors on the switchport.

Duplex on the codec is set to "Full"

The status on the codec says "1000full"

There appears to be some minimal packet loss noted on the MCU and codec. But it's not much more than I typically see on most other calls.

One thing I have tried in the interim is connecting at 2048 kbps instead of the usual 768 kbps. I see a little more packet loss than normal, but it is not reverting to XGA/QCIF... which is nice :-)

[Nicholas Holum]

Well I spoke to soon. Connecting at 2048kbps worked for a while, but it eventually reverted to XGA.

We rerouted the connection over the internet / VPN, reconnected at 768kbps, and it has held hi-def resolution for over an hour now. (It was previously connecting over our MPLS connection).

This is weird because there are two other cameras (SX10 and SX20) at this site that don't have any issues connecting over our MPLS connection.

[PJMack]

there could be another factor here, the MCU will "ask" the codec to send different resolutions depending on what is being viewed. For example (keeping it simple), if every far end was viewing a quad split 720p image, the endpoints will probably send 360p to the MCU for the simple reason that four 360p images displayed together = one 720p image. If you're using non symmetrical continuous presence layouts the resolution of the codec will often change to a higher resolution when they are speaking (because they move into the primary window) than when they're not. 

To test this theory, create a conference with a full screen voice switched mode and connect only one other codec so it doesn't switch ever, and then see what you get. 

[Nicholas Holum]

Thanks again for the response PJ.

The conferences on our codec are all full screen voice switched. And this codec is reverting to XGA regardless of whether it's the only codec connected or other codecs are connected too.

Also, it has eventually reverted to XGA in all scenarios I've described/tried in this thread. So far I have tried...

1. Changing the call rate from 768 to 2048. This seemed to help but eventually it reverted to XGA.

2. Rerouting the connection over our internet/vpn. This seemed to help the most but it eventually reverted to XGA.

3. Turning off encryption. This made no difference.

4. Verifying QoS settings.

5. Updating software to latest release.

As I type this I have connected it via H323 instead of SIP. So far so good but only time will tell.

Really not sure what else to try here.

[Nicholas Holum]

Well it seems the h323 connection eventually reverted too. I'm all out of ideas :-(

[PJMack]

We kind of skipped over the basics, what SW revs are you running on both the C40 and 4510?

Latest for both are TC7.3.14 and 4.5(1.89) respectively.