流媒体转发的遇到的一些问题

标签：ase   clean   ...   .com   base   result   bsp   htm   html   

在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包，数组的长度依据期望的延时来设置,

我最大的延时忍受值是5秒，传输的视频是1920*1080   也就是5*8500Kbps=41KB  　　每个元素存放1024byte数据，所以就是40个元素，（考虑到特殊情况I帧比较多的时候）我放大了一点60个元素

2.新建两个线程，一个专门读取udp传输过来数据，放入数组，记录读取下标。另一个转发数据，记录转发下标（加锁，防止读写冲突）

如果读取udp传输过来数据的位置马上追上了转发数据的位置，那说明已经延时5秒，直接丢弃前五秒的数据，把转发数据的位置移到读取传输数据的前一个位置

流媒体转发的遇到的一些问题

标签：ase   clean   ...   .com   base   result   bsp   htm   html   

原文地址：http://www.cnblogs.com/baldermurphy/p/7156618.html