看了一下,也太多人过于自满了，大家想想，目前大家考虑的只是视频和网络传输问题，没有考虑到网络的带宽和流畅音频的问题，就这个那个的相互攻击，有什么意思呢。 我的经验不是很足，但也作过这样一个程序，光视频这一块通讯器来还算流畅，所以拿出来和大家分享一下经验。 为了保证视频捕捉端程序的流畅性，我专门作了一个视频捕捉的EXE，这个程序是以DDE和其他程序进行通讯的。 因为我的程序动画比较多，然而我的电脑速度不是很快，所以在播放视频影像的时候会影响动画的流畅度，我对线程又不是很了解，所以采用了进程处理。 我的发送图象端（S）程序向视频捕捉的EXE发送开启视频捕捉的DDE命令，并让其显示视频信息到我的发送图象端程序的Picture1里，当接收图象端（C）连接发送图象端（S）后，（C）处于等待接收字符状态，（S）向（C）发送一个"OK"命令表示可以提出命令请求,（C）便向（S）发送"GIVE ME THE PICTURE"命令，（C）处于等待接收字符状态，（S）向视频捕捉的EXE发送保存图片命令(JPG格式由视频捕捉的EXE，一般大小在2K左右)并读取文件大小以字符方式发送给（C），（C）返回“NEXT”作为通知，（S）读取文件到数组中，然后向（C）发送数组，（C）判断所收的数据达到文件长度后将数组写到文件读取图像文件到设备，再向（S）发出"OVER"命令，（S）向（C）发送一个"OK"命令表示可以提出命令请求，到此通讯完毕。 因为我采用了170*120大小，又把高度压了一半，然后用JPG压缩图像进行传输，所以数据量比较小，每一贞在2K左右，在一般的媒体中高品质的动画是每秒30贞流动，一般点的是24贞，基本的是15贞这些都能让人感觉动画流畅了。以目前的宽带而言速度最少可达到120K，2*30不过每秒需要60K,所以效果是搓搓有余。方法很土，还请各位不要见笑。
不记得是vb里还是第3方有个控件可以连接到视频，不记得了，找到了告诉你吧。
原理是将图像抓下来后放到控件里，用API分解图像的信息，将这些信息转为二进制，二进制再转为BASE64发送，对方收到后将base64转为二进制，再将这些二进制的图像信息用API还原成图像流，最后就是显示出来啦
你说你发送这个1.44M的文件 跟我所说的，发一个只包含BMP头文件的数据流，是不是一样呢哦，对了，都是用winsock发，都是用VB写的，真的是一样哦郁闷的四次方
楼上两位不要吵了，VB也有他的局限。如果楼主要用vb写这样的程序，建议你还是做财务软件这很有前途的职业吧……在vb里面实现jpeg压缩是很慢的，或者，你也可以实现rm压缩或是vmr压缩，但是这都是需要real或者ms的控件实现的。图像流的问题不是单纯的屏幕图像这样的传输问题，所以最好是采用mpeg制式的压缩方法方能获得比较流畅的效果。换句话说，这里要使用的不是静态压缩技术，而是动态压缩技术。恰巧mpeg和jpeg都不是vb的长项，而real和ms提供的sdk，就需要你自己研究了，据说用他们在vb中是可以实现这样的要求的。
我的经验不是很足，但也作过这样一个程序，光视频这一块通讯器来还算流畅，所以拿出来和大家分享一下经验。
为了保证视频捕捉端程序的流畅性，我专门作了一个视频捕捉的EXE，这个程序是以DDE和其他程序进行通讯的。
因为我的程序动画比较多，然而我的电脑速度不是很快，所以在播放视频影像的时候会影响动画的流畅度，我对线程又不是很了解，所以采用了进程处理。
我的发送图象端（S）程序向视频捕捉的EXE发送开启视频捕捉的DDE命令，并让其显示视频信息到我的发送图象端程序的Picture1里，当接收图象端（C）连接发送图象端（S）后，（C）处于等待接收字符状态，（S）向（C）发送一个"OK"命令表示可以提出命令请求,（C）便向（S）发送"GIVE ME THE PICTURE"命令，（C）处于等待接收字符状态，（S）向视频捕捉的EXE发送保存图片命令(JPG格式由视频捕捉的EXE，一般大小在2K左右)并读取文件大小以字符方式发送给（C），（C）返回“NEXT”作为通知，（S）读取文件到数组中，然后向（C）发送数组，（C）判断所收的数据达到文件长度后将数组写到文件读取图像文件到设备，再向（S）发出"OVER"命令，（S）向（C）发送一个"OK"命令表示可以提出命令请求，到此通讯完毕。
因为我采用了170*120大小，又把高度压了一半，然后用JPG压缩图像进行传输，所以数据量比较小，每一贞在2K左右，在一般的媒体中高品质的动画是每秒30贞流动，一般点的是24贞，基本的是15贞这些都能让人感觉动画流畅了。以目前的宽带而言速度最少可达到120K，2*30不过每秒需要60K,所以效果是搓搓有余。方法很土，还请各位不要见笑。