在windows下开发流媒体转发，遇到了不少问题，汇总一把
1.第一个是有时候会莫名其妙的卡死，检查了不少代码，也没发现问题，
不过发现一个现象，printf()打印的终端，没显示最近的日志，按enter,会出来很多日志，在网上找了好久
http://www.cnblogs.com/jwk000/p/6194525.html
发现这兄弟和我遇见的情况一致，可能是打印缓冲区满了导致的，也有可能其他原因（大神知道的可以告诉我），最后在接收到心跳的时候加了system（“cls”），就没出现过,可能windows真的不适合服务器开发
2.使用close关闭boost的socket的时候奔溃
boost::asio::ip::tcp::socket socket(io_service); boost::asio::socket_base::linger option(true, 0); socket.set_option(option); .... socket.close();
这个是多线程问题，这边关闭，另一边却不知道，还在操作，所以崩溃
socket.shutdown(tcp::socket::shutdown_both);
shutdown就不会，官方注释也是这样推荐的
3.udp接收到的数据不能正常正常解析
不停调试发现是udp socket的缓存区的大小设置太小，要找的适合自己程序的值
int nRecvBuf = 1024 * 1920 * 1090;
//int nRecvBuf = 1024*1024*100;
int iResult = setsockopt(NodeRecSocket, SOL_SOCKET, SO_RCVBUF, (const char*)&nRecvBuf, sizeof(int));
if (SOCKET_ERROR == iResult)
{
LOG_ERROR << "setsockopt error " << WSAGetLastError();
WSACleanup();
return;
}
4.sleep（1）的实际休眠时间，在传递数据的时候，为了保证数据的有序，使用了sleep（1），循环一次不明显，循环多次视频明显延迟很多，所以查了一下sleep（1）
不查不知道，一查吓一跳，sleep（1）的实际时间取决于 系统时间精度，cpu核个数，CPU分配的时间片，以及线程调度的时候上下文切换，等等一系列因素，有的电脑测出来休眠了10毫秒，简直无法忍受，有的测出来0.6-0.8ms
目前没有好的办法，我只用sleep（0），让渡出去，让系统决定时间
5.以前的流媒体转发设计是，使用了一个线程，重复做如下工作
a.读取视频流udp数据
b.解析udp数据
c.向所有请求的远端转发udp数据
d.重复a-c;
这样的设计出现一个很大的问题就是
延时的积累，因为b,c都是耗时操作，而且要耗时操作执行完才能读取下一次的数据，这个时候可能udp的缓存区已经积累的大量的数据，而且udp每次只能读一个包
有时候延时很严重，延时一分钟两分钟，直至最后卡死
所以我改写了流程
1.新建一个数组存放udp数据，数组的每个元素存放一个udp包，数组的长度依据期望的延时来设置,
| 视频大小 | 分辨率 | 建议码率 |
| 480P | 720X480 | 1800Kbps |
| 720P | 1280X720 | 3500Kbps |
| 1080P | 1920X1080 | 8500Kbps |
我最大的延时忍受值是5秒，传输的视频是1920*1080 也就是5*8500Kbps=41KB 每个元素存放1024byte数据，所以就是40个元素，（考虑到特殊情况I帧比较多的时候）我放大了一点60个元素
2.新建两个线程，一个专门读取udp传输过来数据，放入数组，记录读取下标。另一个转发数据，记录转发下标（加锁，防止读写冲突）
如果读取udp传输过来数据的位置马上追上了转发数据的位置，那说明已经延时5秒，直接丢弃前五秒的数据，把转发数据的位置移到读取传输数据的前一个位置