【FAQ】全志XR系列 设置音频结构体HttpStreamBufferConfig成员有什么意义?

[q1215200171]

问题背景
有客户放映在播放网络音频时经常在最后时返回recv err(104)，但是通过修改HttpStreamBufferConfig成员的大小偶尔又不会出现。

问题描述
为什么XRMCU播放网络音频时会出现recv err(104)？为什么修改HttpStreamBufferConfig又可以令异常消失？

问题分析
HttpStreamBufferConfig结构体的成员如下：

typedef struct HttpStreamBufferConfig
{
    int maxBufferSize;
    int maxProtectAreaSize;
    int thresholdSize;
    int seekIgnoreThresholdSize;
} HttpStreamBufferConfig;

XRMCU在播放网络音频时，通过lwip和服务器建立连接请求数据，其中maxBufferSize就是能接收到的最大缓存数据，缓存区满了之后，需要等待播放器播放消耗掉才能继续接收数据。

maxProtectAreaSize，考虑到播放器可能向前seek。如果数据已经丢弃，就必须重新连接服务器获取数据，效率较低，所以设置了maxProtectAreaSize，即使播放了数据依旧不会马上丢弃，而是继续保留在maxBufferSize定义的缓存区中，直到超出了maxProtectAreaSize。

thresholdSize，音频解码时必须是一帧完整的帧，否则会引起解码器异常，所以所有音视频解码器都是必须缓存够一段数据后才开始解码，这个变量的意思是数据缓存必须大于这个值才进行解码。

当往前seek的时候，我们可以采取两种方式来实现seek。一种是重新和服务器进行connect协商，一种是我们继续正常read数据，但把read的无效数据直接丢弃，直到read到需要的数据。这个seekIgnoreThresholdSize的含义就是，如果seek的距离小于这个值，则我们采用丢数据的方式；如果seek的距离大于这个值，则采用重新connect的方式。

至于出现的recv err(104)，通过抓包数据分析，原因为服务器下发数据的速度过快了，导致maxBufferSize大小的缓冲区不够而停止接收，而这段时间服务器依旧往下发，并且在发送完成后主动关闭了连接，导致cedarx再次去申请数据时无法申请，所以出现了recv err(104)。
问题解决

由于播放不能加快，如果服务器端不能修改数据下发速度，则只能通过修改maxBufferSize的方式扩大缓存，确保不会丢数据。

如果没有需求，则可以减少maxProtectAreaSize的数值。