果然油管关掉 html5 后速度飞快

[trepwq]

这两天折腾香港 SOFTLAYER 的 vps ， ss+fs （ udp ），使用 html5 的油管 4k 稍卡，看速度最高 25000kbps ，平均 6~7000kbps,关了 html5 直接飙到 80~90m 的速度，基本吃满我的联通 100m ，打开直接是 4k 的， html5 下打开是 1080p 的。
观察了网速不是连续的，很均匀的一个一个波峰。

[typcn]

@shunia 优酷就是切片来支持的 Flash 缓冲控制和 seek ，不切片是不可能做到的。 HTML5 如果要实现 seek ，是不需要一行代码的，直接放到 nginx apache 或者任意一种播放器上，<video src> 就能播放，而且 Chrome 会自动做缓冲控制，而是当前播放位置的 X 秒。

@zongwan 真屌， CPU 指令集还能为网络栈优化，以及 AMF 的传输很多都是 plaintext ，只会增大数据体积，对于 mp4 来说，缩小是不可能的，下次说话之前，先打一下草稿。

@d1sm Google 早就升级了 HTTP/2 ，还会使用基于 UDP 的传输技术 QUIC ， SPDY 在去年早已被废弃

@iloveayu 这个就是为了缓冲控制，切片成 Dash

[typcn]

诶，今天我真是大开了一次眼界。。 自己不懂还要强行装懂，问题是自己编出来的话，自己都不知道对不对，竟然不先上网搜一下自己的猜想对不对，就来直接发帖子。

[shunia]

https://developer.mozilla.org/en-US/Apps/Build/Audio_and_video_delivery/buffering_seeking_time_ranges#Seekable

不给你看 Flash 的只给你看 HTML5 的。 MDN 的这段说的并不详细，但是意思是说明白了。

还是有话说对了，不切片确实办不到缓冲控制。 Flash 办不到， HTML5 也办不到。
但是 Seek 是利用的服务器端功能（不管是哪个部分-nginx 还是 FMS 等-来实现）。

我非要撕是看在一点上：既然不懂 Flash ，甚至某些基本的不涉及 Flash 的部分都有知识疏漏，为什么要强行黑？瞎扯的部分，老老实实说，我没调查过，不就好了吗？

[typcn]

@shunia
1.自己去看看 ffmpeg 和 chromium 的源代码，看看会不会无脑缓冲到头
2.Seek 利用的是 HTTP 协议本身的特性，而 Flash 需要做特殊切片处理 （通常 ?start=xx ）

[typcn]

@shunia https://tools.ietf.org/html/rfc7233 自己看， HTTP 协议标准， Flash 是不支持的

[akw2312]

@typcn "Google 早就升级了 HTTP/2 ，还会使用基于 UDP 的传输技术 QUIC ， SPDY 在去年早已被废弃"
不完全 我這邊的 googlevideo 服務器是 quic + spdy3...沒有 http2

[akw2312]

話說說什麼 QoS...我這邊用 HTML5 看 4K 之類的 常常卡緩衝 當時速度只有 10~25Mbps..(我在台灣 直連 hinet 的 GGC)
但是用 Flash 就不會卡緩衝 能跑到 8xMbps
如果扔到 IDM 下載(已經設置成"單線程"了) 能跑到 11MB/s...

[heliopetuous]

感谢楼主提供了一个提速的新思路。

[datou]

旧电脑还是用默认 H5 外加个强制 H264 的扩展

[Khlieb]

http://www.youtube.com/html5

[wqrz]

刚我也把插件安上， 看 1080p 终于不卡了 舒服最重要不要管什么原理不原理的了

[ninggu2008]

唉呀妈呀，太 TM 显著了。。
用 html5 ，看统计，前十几秒，连接速度 200-700kbps ，经常自动切到 144p ， 360p ，糊到难受，手动切回去不方便。
禁用 html5 ，换 flash ，连接速度直接峰值到 10000kbps （其实我怀疑可能不准， windows 一个网速检测 app 显示速度 500KB 是有的），很快缓冲一大截。 480p ，不会自动给切到 144p ， 360p 。

原来优酷切片是为了缓冲控制，我以为是为了防下载。