背景

之前不是写过一个项目嘛，就之前有更改过存储对接的项目
go语言对接S3存储的SDK(支持minio和OSS)
这个项目主要的业务是就一个，点播rtsp协议的码流，视频来源在存储服务器上。
这次的问题是rtsp协议只播放部分，需要我们进行排查和修复

分析

先看取存储数据的地方是否存在问题

在options交互的时候 会创建2个队列

在DESCRIBE的时候会去取存储的数据放到队列中

在另外一个携程中会去消费队列

从代码来看，没什么大的问题。

使用ffplay 点播并抓包分析

ffplay -rtsp_transport tcp  -i rtsp://xx.xx.x.1xx:554/xxx/8f8c42954992/5_5

抓包看信令也没什么问题(这块信令交互，后续等有时间我在写)

TEARDOWN 是客户端请求断开连接，停止媒体流。服务端没实现，这个问题也比较小，不会存在着只播放部分的问题。

那问题点出现在哪里？

我们注意到一个事情，当没有进行拉流之后，客户端一直在给服务端发ack

每隔一段时间会发一个ack相关的

我们在初始化的时候会重新实例化这个队列消息

会不会是因为这个原因，把队列给清空了。

为了证明我们的猜想，我们只需要在NewQueue方法上打一个日志就可以了。

我们就初始化了二个队列，但打印了四次，理论上来说只会打印2次的。

也就是说ffplay在拉服务端发完流之后会继续尝试请求进行拉流，就会导致这个问题。

也就是我们我们的Options方法调用了多次，那如果解决这个问题呢？

我们只需要在这加一个空判断，如果是空的我们在去实例化。这样就不会存在初始化队列的问题。

重启在进行点播测试，没有只播放部分的问题了，说明我们已成功解决。