噶菲

> 1.把allowed-sites.conf文件下的注释全部取消。 > 2.nginx.conf下的dns改成8.8.8.8。就可以解决了。 > 朋友你再看一下在谷歌浏览器中访问这个代理，然后访问[https://sci-hub.se/downloads/2019-09-13/73/[email protected]，看看这个pdf你那里能下载吗？](https://sci-hub.se/downloads/2019-09-13/73/[email protected]%EF%BC%8C%E7%9C%8B%E7%9C%8B%E8%BF%99%E4%B8%AApdf%E4%BD%A0%E9%82%A3%E9%87%8C%E8%83%BD%E4%B8%8B%E8%BD%BD%E5%90%97%EF%BC%9F) 好的,我试试, 这两步分别要解决的是什么问题呢

> 第一个 > 你看说明就你能理解。 > 第二个是由于作者那边的dns和你内网的dns不一样，他在他那边的网没问题，在你这就不行了。   兄弟, 我改了,还是这样呢 

> 你要代理youtube啊，那这个代理不了，作者都说了，youtube暂时还有问题，没法代理。。。。。 所有都这样, 应该和ytb无关

> 你这样，你别localhost了，你换成服务器的ip试一试 我没有证书, 只是想本地运行下

> 问题是这样的 当播放摄像头视频流帧率较低时，延迟会更加明显 调试 发现 currentTime始终小于 buffeded.end，且怎么追也追不上 例如帧率为10，当SourceBuffer对象添加8段segment才能够启播，即bufferd.end一直在增加，而currentTime始终为0(已经对Video标签设置了autoplaye为ture) 这时延迟就稳定在 （1/10）*0.8 = 0.8s，currentTime始终小于 buffeded.end，怎么追也不追不上。 例如帧率为5，也是SourceBuffer对象添加8段segment才能够启播，即bufferd.end一直在增加，而currentTime始终为0(已经对Video标签设置了autoplaye为ture) 这时延迟就稳定在 （1/5）*0.8 = 1.6s，currentTime始终小于 buffeded.end，怎么追也不追不上。 且发现同样的帧率，采用不同编码格式也不一样，例如上述描述的为h264编码，8段才能启播，而h265编码的话，大概3段就能启播。 当帧率设置为1时，大概两到三段segment才能启播，延迟就稳定在2~3s > > 请问作者及大家有遇到过类似的问题吗？有好的解决方案吗？ 当帧率较高时，延迟就不是很明显，但帧率较低时，延迟就很明显，需要优化~ 低时延问题解决了吗