我正在使用自定义编解码器处理直播服务器（必须使用它，没有办法解决它） . 多个客户端将与服务器连接以获取实时源 . 在理想的世界中，所有客户端都将通过宽带连接进行连接，并且在编码之后，我可以以循环方式将所有编码帧转发到每个插槽 . 但在现实生活中，我可以通过高延迟连接以及慢/移动连接来连接客户端 . 这将导致很少客户能够快速摄取数据而其他客户将滞后 .
显然，像循环法这样的技术在这里不起作用 . 另一种可行的技术是对每个连接进行编码，但这会在服务器端消耗过多的CPU - 这也是不可接受的 . 最后，我正在考虑改进的h264 i-frame技术 . 基本上，无论内容如何，只需每1-2秒添加一个I帧 . 这样，一个缓慢的消费者将能够在每个I帧同步其余部分 . 反馈？是否有任何标准技术/算法来处理这种情况？
1 回答
您需要至少2个正常（高带宽）和更小（低带宽）的编码 .
使用.NET 4.5的套接字等待/异步语法 . *异步方法也会带来一些额外的性能，而不是使用循环同步套接字，使用IO完成端口和更少的阻塞 . （这是一个例子：https://stackoverflow.com/a/12631467/884862）
最后确定是否为客户端提供高带宽或低带宽版本，而不实现自适应比特率流 .
给用户一个选择
进行带宽测试，向客户端发送带有128KB数据的回应请求，并使用发送的时间和返回时间来计算出客户端对于高带宽版本是否足够快 .