You need to find a way to offload video compression onto a dedicated chip so that old laptops and new netbooks can be effectively utilized.

Don't wish to ruin your day with howls of laughter...but we still have stacks of Thinkpad 600Es and use them intensively. Even use an old 380Z as an engine analyzer. Suspect most of the now "uncool" durable laptops are similarly in use. Yes, I know about Walmart laptops....but they aren't as durable as 12 year old business class.

Besides, that atom processor must be made your friend. Ain't gonna happen without CPU offload........

Can user installed CoreAVC offload CPU?

(it makes nvidia gpu:s do more 264 decoding)

I certainly don't speak for VSee (and please correct me if I'm wrong); but VSee could do GPU offloading of encoding/decoding using the DirectX Video Acceleration 2.0 (DXVA 2) API. There's a bunch of new Device Driver Interfaces (DDI) but require Windows Display Driver Model drivers. This is only for Win 7 - I think you'd have to revert to VMR9 and Overlay mixing for Win XP (not entirely sure on that point.)

The advantage with that approach is not being locked into vendor specific hardware processing; it would work for both NVIDIA and AMD GPU chipsets.

The disadvantage with this approach is the added complexity of coding to VSee's (presumably) highly tweaked processing pipeline.

The caveat for me here is that I am not a programmer and perhaps the smart folks in VSee Labs are working on just this approach. Perhaps further, it may not pose any significant difficulty for them.

A SIMD processing approach really helps though. That is (partly) why, for instance, the HaiVision, Mako HD (http://www.haivision.com/products/mako) only has 70ms latency end-to-end in their pipeline. They also use fast DSPs - but lots of chips are simultaneously chugging away.

Firstly, I want take the opportunity to thanks all Vsee team to give me this chance to ask some question.
Secondly, I am master student and my area it's (P2P video conferencing), so I have another type of question (technical question) :



1-I talked with Mr. Melton and I asked him about number of users that can Vsee support it, he reply me for each user 100 kbps that means if I have 1 Mbps (download) can support 9-10 users my question how can determine the bandwidth between us specially the amount of bandwidth (upload / download) different from peer to another peer in the other word (network heterogeneous).



2-Vsee used TCP or UDP to transfer the video?



3-How can I get full support and answer my entire (technical question)?

Hello khalaf,

I'll do my best to answer your questions.

1) Make one of the video windows the active (forward) window and hit ctrl-I or select "network statistics" from the meeting tools menu (the icon of a screen and two people). This will bring up the network statistics window which shows your upload, how much you're sending and receiving, and the bandwidth you are getting from each individual caller. On each caller's video window, you'll also see a graph of their CPU usage and their network delay. Each caller can only see their own upload speed.

2) UDP is the default.

3) Nonpaying, non-trial users can only be supported via the support pages (FAQ, How To, Forum, etc.). As for answering technical questions, we'll do our best here.

Thanks for using us.
-John

Thanks Mr. John for your answers and your support.

In term of P2P network each peer works as a ( Server or Client ) so each peer will help other peer by sharing the resorces (CPU, Bandwidth,memory). Snice the botellneck alway happen in Upload link so:

1- how can each peer support another peer specially in video conferencing we have multi video stream?

2- Vsee assign 100 kbps for each user why?

3- I don't know I write in the apropirate area in this forum?

Thank very much for your support

Khalaf,

Perhaps I can clarify for you how the connections work (as per usual, if I error, please correct):

VSee does not use an overlay network like Skype's JoltID bandwidth sharing network. Instead, VSee uses a direct point to point connection with each participant. The advantages to this approach are that latency is kept lower as nodes do not try to offset bandwidth needs with neighboring end user nodes within an overlay network - this savings in latency is similar to not having to rely upon a central server like an MCU used in more traditional multi-participant models.

The downside to this approach is that each endpoint user must have the bandwidth to support the inbound and outbound bit rate of each participant in a session. However, VSee does provide an MCU add-on to its Relay service when absolutely necessary.

Thanks Rich!

Also, to cover your second statement, VSee isn't assigning 100 kbps (at least, not without a command line prompt to specifically do so). It just happens to only need that much bandwidth. The actual amount changes due to things like movement, frame rate and resolution if you change them, and, of course, available bandwidth.

Make that, to cover khalaf's second question...