Tandberg MCU Question

[Airwave1]

If in an MCU call one site can only receive CIF quality and another site transmits an XGA PC image (and takes the Floor) do all sites receive CIF as standard instead of say QCIF/SVGA/XGA?
Or is the Tandberg able to allow some sites to receive QCIF/SVGA/XGA whilst another CIF?

I'm running D3.4 level software and its a 16+16 MCU

Thanks

[trapehzoid]

the mcu can send different video streams to different sites.. the sites will send in 'the best they can' and they will recieve whatever the stream the MCU is sending out. I think the MCU supports two different outgoing qualities simultaneously.. I might be off on that tho

[Airwave1]

From what I have found out it apears that the MCU does do this but its hard to predict how and when.

eg: In a conference one site takes the floor and transmits an XGA resolution PC image. There 4 ISDN6 sites dialled in, at least 1 not supporting XGA resolution, this brings the MCU video output down to 4CIF. Also connected is 1 IP site at 768KBps, this receives an XGA resolutution picture. Drop its call speed to 383KBps and it drops to 4CIF.

Does this all make sense to anyone?

The problem we have is we can have 10 sites in one conference, 9 of which can support XGA and one which is only CIF, this means all sites get CIF when one site has taken the floor, not good!!

I have heard that the MPS will Support mutli-outputs at different call rates/protocols and that this feature is called collaborates.
Hopefully this can be added to the current MCU by means of a software update as it really is a bug bear for me and my users!

[cribbinsb]

Well, I guess the problem with most MCUs is that they do not have the processing power to have a separate encode for each participant in the conference – this is why with most MCUs there is usually only one or two continuous presence layouts for each conference and have many other restrictions. This is also why it will be very hard for most MCUs to add this functionality with a simple software update.

The lack of processing power means a few things:

Most viewers have to see themselves – if they don’t see themselves no one else sees them. This can be very off putting as it indicates to the users the delay in conference.
The conference may well have to drop down to the lowest common bitrate, codec – and as you are seeing here – resolution.
Most MCUs cannot do continuous presence layouts at high resolutions.
Most MCUs drastically drop their port count as the bitrates of the conferences goes up.

The one exception I know to this is the Codian MCU which is using the latest TI DSPs – so has far more processing power. It can mix any number of combinations of codecs (including H.264), bitrates (up to 2Meg) and resolutions (up to XGA) in the same conference. It can do CP layouts at up to XGA resolution. Each participant sees their own layout – so users never have to see themselves, and can choose one of 42 different layouts without affecting anyone else. And above all – there is never any reduction of port count or functionality, regardless of what codec, bitrate or resolution is used.

[jakob]

Airwave,
I think the MCU uses the callrate to set up the encoders. Try to dial in with a slightly lower callrate from the endpoint that only suports CIF.

[Airwave1]

Airwave,
I think the MCU uses the callrate to set up the encoders. Try to dial in with a slightly lower callrate from the endpoint that only suports CIF.
That makes sense, I'll have a play about with this then, If I could get all the non-XGA sites to dial in at 320Kbps and those who support XGA to dial in at 384Kbps then this could solve the problem and I would be a happy man. It would be a pain like as we sometimes use 16 sites in one call and getting everyone to adhere to the call speed rules would be a challenge!

Thanks

[robertk]

Well, I guess the problem with most MCUs is that they do not have the processing power to have a separate encode for each participant in the conference – this is why with most MCUs there is usually only one or two continuous presence layouts for each conference and have many other restrictions. This is also why it will be very hard for most MCUs to add this functionality with a simple software update.

The lack of processing power means a few things:

Most viewers have to see themselves – if they don’t see themselves no one else sees them. This can be very off putting as it indicates to the users the delay in conference.


The Tandberg MCU most certanly CAN and WILL do different layouts!!! Look at the 5+1 and 7+1 layouts... when you speak, you never see yourself in the larger view. But the other sites do. So there is atleast 2 different views.

I can't understand how TANDBERG can make their product look as it belongs with the "low end" MCUs where you HAVE too see yourself all the time. I just can't understand it... Or maybe it is some thecnicality that forces them to have it that way. It looks cheap though. However the price of the TB MCU isnt :^)

I really hope that they make the MPS work like a MCU should, IE never show your own image : ^)

//Robert

[Andrew_B]

I think I'm somewhat in the same boat. We had 9 sites that all connected at 384kbps and the was no packet loss. But the image was crappy. All blocky and jagged. So is it a problem with the MCU? It can't handle having that many sites connected at once? It was a voiced switched session 7+1 I think.

Why would Tandberg sell a product that has a bandwidth maximum (7500kbps I believe) and a maximum number of sites (16), when it can even handle that many hosts?

How can I fix this? Make it so it's totally voiced switched and you can't see all the remote sites on the same screen at once?


Please help,

Andrew

[jakob]

Andrew,
Do I understand you correctly that you want to set the MCU into voice switched mode? Just select Voice Switched as the conference's picture mode and you are done.

[Andrew_B]

We had the conference in 7+1 and the big picture would switch to whoever is talking. There was no packetloss, but the video looked crappy. What gives?

[Airwave1]

If I understand this what Andrew is saying is he was in a 7+1 config and the voice switching is to and from the larger box on screen (ie. the 1 of 7+1).
I use this style a lot and have had it up to 14 sites in one conference with no obvious problems, we use ISDN6 generally. You do get the odd picture flaw but it is momentary and never a problem.

One question I would ask:
Is the picture problems all over the whole MCU view or just in one or two of the 7+1 box's on screen?
I sometime get picture freezing etc. but its often just in one box and therefore I guess its that one sitye that has the problem and no the MCU.

After looking at my own MCU issue it seems that the MU can send two outputs bu they must be at different speeds. I'm going to have to be more carefull in future with who I connect in and at what speed.
Why does Tandberg not make this information avaliable, it should atleast be in the manual!!

[vtjoe]

From what I have found out it apears that the MCU does do this but its hard to predict how and when.

eg: In a conference one site takes the floor and transmits an XGA resolution PC image. There 4 ISDN6 sites dialled in, at least 1 not supporting XGA resolution, this brings the MCU video output down to 4CIF. Also connected is 1 IP site at 768KBps, this receives an XGA resolutution picture. Drop its call speed to 383KBps and it drops to 4CIF.

Does this all make sense to anyone?

The problem we have is we can have 10 sites in one conference, 9 of which can support XGA and one which is only CIF, this means all sites get CIF when one site has taken the floor, not good!!


We have had the same problem. Try connecting the 9 sites that support XGA at one bandwidth - regardless of IP or ISDN - lets say at 384. Then connect the 10th site that can't do XGA at a slightly lower bandwidth like 320. This will help keep everybody getting the best quality.

The Tandberg MCU seems to have only two streams of video, as others have indicated. The highest BW connected will be one stream - and then it settles on the common denominator (H.261 or H.263 and then CIF, 4CIF, XGA, etc.) for the highest bandwidth. The other stream is the lowest bandwidth and includes everybody who is not in the highest bandwidth - and then a common denominator ((H.261 or H.263 and then CIF, 4CIF, XGA, etc.) .

A worst case scenario is when you have two sites connected at 768kbps, and then something like 5 sites connected at 384kbps, and one site connected at 64 kbps. The 5 sites that should be at 384 kbps will be dropped down to 64 kbps. The 768kbps sites will only get 768kbps from each other.

The easy solution is to disconnect the 768 sites, and reconnect them at 384 kbps. This will bring all the 384 sites to actual 384 quality. (Or, if possible, disconnect the 64kbps site and reconnect it at 384kbps).

I don't think the Tandberg MCU is going to get any more powerful based on software. However, it could get a lot smarter...especially for a scenario listed above.

We use the Tandberg MCU everyday for multiple conferences. Most of the time it just works without having to worry about all the above.

[Andrew_B]

It's all over the pciture. Not just a site ot two. Come to think of it we may have had one site connected at 768 instead of our normal 384. I'll try to see if that fixes the problem.


Andrew

[Airwave1]

It's all over the pciture. Not just a site ot two. Come to think of it we may have had one site connected at 768 instead of our normal 384. I'll try to see if that fixes the problem.


Andrew
Can you use IP and ISDN?

If so if you use IP only does the same thing happen and like wise with ISDN only?

If the same thing happens with both then it would suggest its a hardware issue with the MCU. If it only happens with one of them it could be either the network or the PRI's you are using.

I'm no expert but these seem like simple checks that could help get to the bottom of it.

Best of luck and keep us informed!