我是一个菜鸟,才刚刚接触这方面的东东,所以也不敢发表什么高论.我把我最近学习和实践的一些操作和体会贴出来,
  希望高手能够给出一些好的意见,也希望大家就这个问题能够多多发表高见!

    我做的是在LINUX下的视频传输(在局域网内),先假设有两台机子A和B要进行视频通讯,A机是普通的台式机,B机是INTEL公司的一个开发平台,带触摸屏.只有A机连有摄相头,现在B机想查看A机的实时视频信息,我的做法是先启动A机摄相头,并将图象大小设置为320*240,颜色深度为16色.摄相头启动之后,将摄相头的缓冲区映射到A机里的一块内存(这样读取数据速度就比较快),这样就可以通过读取这块内存的信息获得视频数据,我把每帧的数据存于一个char类型的字符数组中,然后把这个数组的数据分成512(我也不大清楚划分为多大传输效果会更好?)字节大小的小包,通过UDP传到B机,B机在接受数据之前先将其帧缓冲映射到一块内存中,待B机受到数据之后,马上将这写数据写到其帧缓冲所映射的内存里.循环上述步骤以达到B机实时查看A机视频信息.

   这里我略去了建立连接的过程,在传送数据包的时候,丢包的情况我没有进行处理,但我给每一帧对应的每一个包都加了一个编号,这样就可以知道该包数据的实际显示位置.
   运行结果是另人不满意的:
1)B机帧缓冲可以显示视频,但刷新的很慢.在网络传输方面还有很多待改善之处,包划分为多大比较合适?上面的操作过程是否可以精简或改变以利于数据的传输和实时性的提高?
2)原本图象大小是320*240的,但在B机里显示的只有160*240,还有一半没有显示出来,我测试了好多次都是这样的,所以应该不是数据丢失的问题(如果是的话那也太夸张了,每次丢失的都是那些数据?),这个问题我到现在还是没有搞清楚,哪位DX知道的希望能赐教一二,谢过!

  之所以做这些也是源自于一时的好奇,在实现上面的操作的代码中用的都是系统自带的库和头文件.
再一次声明我只是一个菜鸟,很多想法还是很不成熟,真诚地希望大家能够批评指正!!

1.www.live555.com
livemedia库可以充当host 和client, 使用RTCP/RTP, 应该可以实现你的想法。
如果有兴趣，可以深入其内部研究。

2.速度慢可以归结为实时性差，这有很多可能；可能是发送端本身就慢，实时性不是很好；
还有可能是你所说的丢包率太大，你不妨使用tcp来收发；还有可能是接受方接收/处理不及时等。首先还是要找到速度慢的原因的。
512的包长并不是很长了，我怀疑是你的B机（接受方）处理不及时造成的。

虽然没有做过这方面开发，但有几点建议。
0 找到瓶颈
  从现象上看，肯定有瓶颈，因为在局域网上看电影（直接播放另外一台机器硬盘上的电影），效果也比楼主说的好。
  不知道楼主的摄像头写到内存中的文件是什么格式的，压缩比例是多少，尺寸有多大。
1 通讯协议。
  TCP协议是肯定不能不用的，因为它会因为丢失一个包而重新要求发送的。对于你的项目对于丢掉个别包是可以接收的。
  至于UDP还是RTP我就不知道，因为没有比较。请高手鉴别吧。
2 数据包的大小
  从TCP协议的开发经验上看512确实太小了，我们经常用nk。
3 多线程/多进程
  如果能确定是网络传输是瓶颈，可以考虑多线程/进程的设计方式。

处理速度就要看你的程序结构和方法了。

live media是使用DelayQueue(Timer)的方式来运作的。

你可以参考下。

最重要的是你的视频没有压缩！！！！！！！！！

320*240大小随便找种压缩算法在台式机上都能做到实时。
比如mpeg1/2、 h263、mpeg4

我觉得你可以参照H323协议里的算法和处理方法

h.323肯定是不行的，这个复杂的协议处理语音还成，图像不是很好，delay的问题总结下是压缩（解压缩）和传输两个地方造成的，我觉得在局域网上，UDP问题不大，可能就是你的压缩处理问题吧，是不是你的显卡对于mpeg的解码速度很慢？是延迟大，还是fps小呀？你加个time stamp看看原因。

关注一下。我觉得传输视频的话可以用RTP协议。
本人也是菜鸟，期待着高手解答！

学习...