优化抓流逻辑，建议对非gotcha系的真原画HLS流做优化

[CloudyEagle]

在2013年2月22日上午升到1.13，昨晚录到地区cdn的真原画flv流，后面被迫断开连到mcdn的二压原画流。





我录的两个主播基本都能录到真原画的fmp4流了，偶尔还是会录到地区cdn的真原画流；
当遇到这种情况大概率录到中途会有上面的情况，小概率能通过地区flv流录制完整。
个人有点猜测：
当提前蹲守直播的人过多，B某就对云服务商的真原画流降权
并对地区cdn的真原画流升权限，以做负载均衡，不管是flv流还是fmp4流；
这使不管是观众还是拉流式录制软件均连不上云服务商的真原画流，只能连到地方cdn的真原画流，
而大部分地方cdn稳定性偏差，一旦重连还是重新对api做画质调取，甚至还会携上mcdn的二压原画流。
不过有时活动更大，或者其他的情况，有可能包括我说的这种情况，在开播时可能会启用
204、205、206、207等其他的fmp4做真原画流，请问是否有做这些服务器的录制适配。

[CloudyEagle]

我连续录制不下5次了，感觉B站改推流策略了，可能流量大的主播开播不给208 fmp4的真原画流；
加上地区cdn FLV真原画流不稳定，每次录制就像抽奖，能完整录下来一场的概率很低。
1.


2.


将尝试用另外以及B站录播项目，虽然一开始我就用这个项目做录播的

[CloudyEagle]

22384516的直播间在20:55左右开播时，自己用直播流API链接手动访问以测试获取情况，
发现至少过1分钟及以上才会有208的HLS流，且能获取到真原画流的概率偏低，
所以个人建议录制体量较大的主播把HLS流等待时间延长到1分钟及以上，
主播体量极大的直播间可能1分钟都还不够，3分钟应该可以。

不过V1 API只能拿到一条FLV流，V2 API可获得到全面的直播流信息。我发现
B站应该是修改了真原画的分流逻辑，地区cdn的直播流优先，云服务商的滞后；
且云服务商的直播流排序比较靠后，可能是为了防止抓流录制软件接入，节省带宽？

[CloudyEagle]

B站为了负载均衡和节省带宽开支，经常改给予直播流的逻辑，有时HLS等待时间拉满都录不到gotch系的真原画流，还是被迫录制到地区cdn的FLV真原画流，因为其有一定不稳定性，还会断开重连到以xy开头的mcdn的二压原画流，很难不怀疑在防止人做录播/弹幕站。

[CloudyEagle]

虽然我现在不做她们两位的直播录像留存，也没有做其他的直播录像，但也给后续追求极致质量的直播录像留存的人一个告示。
没有绝对完美的软件，还是要多地多端部署抓流录制直播的软件，做好容灾备用选择。

[CloudyEagle]

非gotcha的录制稳定性目前情况未知，在我已知的情况几乎是1小时内会断流被迫连上伪原画二次压制直播流。
但经常是gotcha的伪原画二次压制直播流，若录制逻辑优化好，非gotcha的应该可以录完一整场直播。
虽然已是后话，我现在也没做哔哩哔哩的直播录制，希望给后续使用该项目软件的人做适配性优化。

[2314860760]

B站为了负载均衡和节省带宽开支，经常改给予直播流的逻辑，有时HLS等待时间拉满都录不到gotch系的真原画流，还是被迫录制到地区cdn的FLV真原画流，因为其有一定不稳定性，还会断开重连到以xy开头的mcdn的二压原画流，很难不怀疑在防止人做录播/弹幕站。

现在的情况是会返回地区cdn hls流 稳定性自测还算可以（HLS本身抗弱网能力强）