posted 26 September 2005 04:34 AM               

This company was once a startup now it is a threat for the big players

I won't comment on the "usual veritest" tests. If Veritest is a serious company it is not who is writing the list of tests and pay'ng them to run them. The saw the same story with Polycom VS Radvision and Polycom Vs Tandberg recently.

I think that there should be a real indipendent testing facility that is not running commissioned tests like these.

BTW Codian is going to release any day now MCU 1.3 with their REVOLUTIONARY H.239

posted 26 September 2005 12:50 PM            

I "think" it is going to shake the industry up a bit alot of very clever (and usefull)ideas

posted 01 October 2005 03:05 PM               

1. Content -> main video
A Content generated as H.239 or VNC will be internally converted as the main video coming from a virtual participant only for users that are not able to receive H.239.

2. VNC -> H.329

You can use a PC and install VNC on it and have it as the content source, the MCU will internally convert it to H.239 to H.239 capable endpoints and as regular video for others

3. Streaming of content with chat and more

Users will be able to connect to the MCU and see the content in streaming as you said, additionally they will be able to chat with each other and make annotations on the content.

4. Streaming with different codecs

You can stream the conference with different codecs with this version, before you could "only" have different rates of the same streaming codec.

Streaming the conference with H.264 is possible and with quicktime 7.0 the quality is very good

All of thise features do not pose limits in the use of H.239.
Some customers do not have all of the endpoints H.239 capable. You gain the flexibiity to send content from the same place where you have a terminal that would not able to like the VS-128 for example.

Historically MCUs that support H.239 do not really do nothing with it internally but simply forward the H.239 stream.

5. Endpoints Database works for incoming calls

You can configure endpoints not to control their layouts, get a specific one and so on in the endpoints database.

These settings only worked with dial out and not dial in.

posted 02 October 2005 11:08 AM               

quote:

---

Originally posted by Senthil:
thanks for more information czoli and did u try the firewall port and route packets from the public network to internal network safely?.

Senthil

---

Didn't really, will find time for it.

posted 03 October 2005 04:03 AM               

quote:

---

Originally posted by Senthil:
good,what about G722.1 when is going to come with codian?.

Senthil

---

Do you really need it? I do not think it is such needed tosday considering that everyone is targeting mpeg AAC and G.722.1-Annex C (known as Siren 14)

Look at new terminal from Aethra they should support both.

Look at the 22 Khz of LifeSize = Mpeg AAC

posted 03 October 2005 05:32 AM               

quote:

---

Originally posted by cribbinsb:
The Codian MCU will get Siren-14 support (and some other new audio features) in the near future.

---

Mind readers ?!?!

Siren-14 is not in my humble opinion what I would call "super quality".

G.722.1 (non Annex C) is the good old Siren7 if I am no wrong.
Who cares supporting it if there is Siren14 as ITU-T standard now?
It is good, yes, but mepg is better.

It is important to bother the endpoint verdors to support at least Siren 14 too.
(look at recent Aethra pretty good move from them)

We finally need a wideband common standard.

Same goes for MCUs and Gateways.

Credits to polycom for having Siren14 as ITU-T standard (G722.1 annexC)

Anyhow they lost again something unique they had and I hardly see something unique in polycom anymore.

posted 04 October 2005 05:34 AM               

Siren 14 in my humble opinion does not have such a good performance in term of audio frequency/noise ratio as "advertised"

It sounds significantly better then G.722 but we definitely need a quality jump.

Call for army !!!! let's all bother vendors to go for a common Mpeg AAC version.

which one do you find superior? AAC-LD or AAC-LC ? (not so skilled in these variants yet)

posted 04 October 2005 06:43 AM               

AAC-LD requires a slightly greater bitrate for the same quality; roughly speaking 32 kbps LD = 24kbps LC, and 64kbps = 56kbps LC.

However LD has fixed latency of <20ms whereas LC typically has a much larger latency e.g. 150ms at 64kbps.

In my opinion low latency is critical for videoconferencing and so I believe that -LD is the right choice

posted 05 October 2005 10:13 AM            

I agree on the latency should be relativly fixed, say not varying much on content or channel packet loss.
But why do you go for that low latency ? IMHO audio will always be delayed in buffer to get lip synchronization with video. Is there any video codec running below 150 ms latency ? I feel lip sync as an important behavior of VTC systems.

The only reason why I switch off lipsync (yes, I can do this on codec and on my bridge unlike 95% of the systems on the market) is if a group likes to sing a song together

Did I miss something here ?

Mero

posted 05 October 2005 10:42 AM               

The inherent latency of any of the H.26x video codecs is just one video frame, or 33ms at 30fps.

These are just the inherent codec delays- you normally need to add on DSP processing time and many other sources of delay in the system to get the total end-to-end latency.

To put this in perspective the TOTAL latency through the Codian MCU including all delays through the network stacks, DSPs, and dynamic jitter buffers is only 80ms. We've worked very hard to get it this low and this is with full continuous presence H.264 and lip-sync- the delay is the same 80ms for both audio and video media.

posted 06 October 2005 05:54 AM            

Wow!
Thanks for explanation of the different delay components contributing. I see now, that delays >200ms I observed between audio and video come from much less DSP power those endpoint codecs have.
With the actual endpoint systems I know, it is not possible to switch off lipsync in order to minimize audio delay (although I assume it IS often possible by service tech access).

Any reader here knowing about an actual VTC-system with lipsync-off switch ?

Second lesson I learned from this thread is, the convergence of videoconferencing and video broadcast standards is still limited to common requirements (e.g. both need a cheap H.264-chip) In terms of audio compression, there is a fork between low latency for VTC and high-end multichannel quality for broadcast. Both AACs are from MPEG, but there are very different algorithms inside, I guess.