关于如何传输视频流的讨论

[m13253]

#3 太跑题，于是新立一 issue。

建议不同问题在不同的 issue 里汇报，弹幕渲染问题去 CommentCoreLibrary 汇报。

@zzjin @Yangff @sgdxpdqqzh @superwbd

[ikeraiza]

我觉得视频流传输直接依赖现有的云当然最方便，cloudfront什么的，国内有骑牛。
要是自己的服务器的话直接切片？
还记得之前看过hmod计划，感觉那个很需要实现啊。
2014/04/16 20:26 "Star Brilliant" notifications@github.com:

#3 #3 太跑题，于是新立一 issue。
建议不同问题在不同的 issue 里汇报，弹幕渲染问题去 CommentCoreLibraryhttps://github.com/jabbany/CommentCoreLibrary/issues汇报。

@zzjin https://github.com/zzjin @Yangff https://github.com/Yangff
@sgdxpdqqzh https://github.com/sgdxpdqqzh @superwbdhttps://github.com/superwbd

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8
.

[Yangff]

一个建议是 http://bgrins.github.io/videoconverter.js/ 在本地处理，或者考虑插件，NaCl之类的。

如果你说在本地做不到real time，你可以考虑一下用户数量和你的服务器的承受能力。
用云的话考虑一下CPU 费用/时间 + 流量收费模式下准备烧多少钱的问题。
以上两点还要考虑在天朝政策范围能是否允许建立这样的服务器。

[ikeraiza]

当然能烧钱最好，我没有视频处理服务器配置的经验，目前我有从prq.se
，sakurainternet租用的服务器，还有托管在朋友乌克兰机房的服务器，都至少可以拿出100m带宽和100g硬盘，有人有兴趣合建一个小型视频云吗？乌克兰线路可以无视dmca，prq的就更方便了。
2014/04/16 21:23 "Yangff" notifications@github.com:

一个建议是 http://bgrins.github.io/videoconverter.js/ 在本地处理，或者考虑插件，NaCl之类的。

如果你说在本地做不到real time，你可以考虑一下用户数量和你的服务器的承受能力。
用云的话考虑一下CPU 费用/时间 + 流量收费模式下准备烧多少钱的问题。
以上两点还要考虑在天朝政策范围能是否允许建立这样的服务器。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-40597644
.

[Yangff]

@sgdxpdqqzh 国外的服务器到国内的话，稳定性基本是坑吧。

[ikeraiza]

还可以，我有个5m独享的景安云，下载三个地方的都是满速，现在租了colocrossing的机器给loli.al提供下载服务感觉也不错。
2014/04/16 21:52 "Yangff" notifications@github.com:

@sgdxpdqqzh https://github.com/sgdxpdqqzh 国外的服务器到国内的话，稳定性基本是坑吧。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-40600865
.

[jabbany]

@sgdxpdqqzh 不知道国内载境外视频是不是得要那一堆许可证。。。。？

[jabbany]

@Yangff 那个 ffmpeg编译到js的东西理念挺有意思，但是载进来经常会把浏览器搞crash了。。。而且转码速度实在堪忧，尤其是移动设备就基本不能指望了。。

[ikeraiza]

应该不用吧，nico都解墙了

2014-04-17 0:34 GMT+09:00 Jim Chen notifications@github.com:

@sgdxpdqqzh https://github.com/sgdxpdqqzh 不知道国内载境外视频是不是得要那一堆许可证。。。。？

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-40613732
.

[cnbeining]

按理说不需要许可证，但是被封也没办法。如果不考虑墙的问题，我在考虑Openshift这种PAAS乃至GAE这种saas的可行性。

RCPPK notifications@github.com于2014年4月16日星期三写道：

应该不用吧，nico都解墙了

2014-04-17 0:34 GMT+09:00 Jim Chen <notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com');>:

@sgdxpdqqzh https://github.com/sgdxpdqqzh 不知道国内载境外视频是不是得要那一堆许可证。。。。？

—
Reply to this email directly or view it on GitHub<
https://github.com/jabbany/ABPlayerHTML5/issues/8#issuecomment-40613732>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-40626247
.

[Yangff]

@jabbany 我本来是考虑NaCl之类，或者是客户端程序协助转码的，转码对计算的需求实在太大，特别是在高清的情况下。

[Yangff]

另外，用asm.js的话性能其实也还算过得去吧。

[jabbany]

@Yangff 性能还好（虽然也远（？）比不过native，而且就算是native ffmpeg要是真的需要“转码”的话也挺慢的）主要是稳定性。浏览器的JS跑高内存高处理的东西容易被杀掉。之前测试的时候就反正Chrome在Win和Linux下都会偶尔Crash（标签Crash）。

[jabbany]

NaCl好像只有Chrome 系支持？这个兼容性是个问题。。。

[m13253]

B站不是有乐视云转码/海外加速么？用的是MP4啊。

[ikeraiza]

可以让用户直接上传视频，服务器再通过各种手段上传到迅雷离线，百度网盘，dropbox，box等有在线播放并且会做压制处理的云上，服务器再下载回来吗？
应该可以节约很大量的服务器开销就解决转码问题，只要有带宽和流量就好。
2014/04/17 23:12 "Star Brilliant" notifications@github.com:

B站不是有乐视云转码/海外加速么？用的是MP4啊。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-40725017
.

[cnbeining]

需要那么复杂么。。。

拆分一下步骤：

1.用户要求观看某视频：有无数用户与服务器通信的实践了吧。。。
2.服务器下载视频：you-get之类的有不少，最不济还可以抓flvcd
3.concat&remux：An speed over 1000 fps can be expected on a low-end KVM VPS. 几秒钟的问题。最大的视频不过3小时吧。
4.服务器将数据流送回用户：吃带宽的麻烦事情，存储也是问题。参见bilidown的实践。之前站长对我说他用了BPCS，不知道现在还是不是。

或者一个基于BPCS与BAE的办法：
1.服务器在PaaS上。
2.下载使用BPCS的离线下载API。
3.使用媒体云API进行转码。
4.使用BPCS的API推送回用户。

当然这还有咱们啥事了。。

离线也可以。模拟用户的正常登陆，当然会留下不少垃圾文件就是了。https://github.com/iambus/xunlei-lixian 有实现。

Dropbox：没有离线下载的API，需要吃服务器。但是，如果服务器国外，速度不会太慢。

box：没大用过，不大清楚。

[jabbany]

我觉得可以创建一个视频倒流平台，分成三个主要服务和一个数据库：

• 视频入口：提供Web界面直接上传、或者拖Torrent、或者you-get等等
• 视频转码运算机：实现转码和封包，转码完上传云服务并通知数据库
• 云存储：存储大量视频信息，可以大面积采用免费或者廉价数据存储中心（比如各种云上传，允许外链的网盘，CDN，或者Amazon S3、SAE、GAE、BAE之类）
• 数据库：存储视频元数据（Metadata）

流程可以这样来：
视频入口一旦得到视频（有可能是通过人为上传、cron抓到了新的Torrent，定时抓取或者被索要视频），下载后先在本地缓存，然后通知数据库，视频被分配唯一的ID。这样用户就能至少有一个入口可以获得视频。

接下来视频入口把视频转交给转码运算机（可以在同一台虚拟或者实体主机上），进行队列转码，一旦有视频转码/再封装完毕，转码服务就会联系一套预设好的API，随机选取一些云服务把视频传上去，并且相应的记录到数据库里面。这时用户获取视频就有多个途径了。

入云之后就可以把原来最早入口缓存的视频标记成“可清理”，然后按照LRU缓存模式去清理就可以了。云服务上的还可以定义一些比如保质期，然后跑一些后台程序，一旦检测到一个视频的存储地点少于指定数字（比如三个）就重新配布。

带宽问题：

大部分云服务内网不算带宽，所以只会经过一次下载。如果能保存一些meta信息比如文件HASH之类的，就能避免多次索取视频。实在不行同一台主机又转码又接受视频也可以。

资费问题：

云存储只要有直接访问就可以，哪怕每次都需要获取动态链接也可以，建一个薄层登录，获取链接，然后转交用户，用户就能下载观看了。很多网盘还都是免费的，有的不带外链，但是可以通过API获得一个临时下载地址，这就够了。

不过这个要真写的话足够做一个新的项目了。

[cnbeining]

这是bilidown和下一代JSharer融合的节奏啊。

入口好办。远有furk，近有离线，有的是办法。
转码需要大量运算能力，除非视频源特殊remux就可以完成。
存储是个问题，放进去了变成死数据也是个问题，都是成本啊。还有traffic的问题等，AWS的traffic贵的一B。。多个云是可行的，但是不知道最终需要成本多少。。。会很高。
metadata有办法。

有一些类似项目。都实现了部分。
简单实现1：（已经死了）
https://www.youtube.com/watch?v=cSgaFM8nJEs
简单实现2：
http://www.bilidown.tv/
计划3：
JSharer的下一代已经不知道在哪的计划。有想法，当时没做起来。
（真应该众筹点钱把JSharer收购了，我想弄成ACG界的https://archive.org/web/ 。。。想多了。）

[jabbany]

JSharer现在叫ra.gg

[cnbeining]

原来ra.gg 是个资讯+社区，JSharer是网盘。。。
现在都完蛋了 萌购倒是活的好好的。。。唉。。

在 2014年4月17日，下午5:40，Jim Chen notifications@github.com 写道：

JSharer现在叫ra.gg

—
Reply to this email directly or view it on GitHub.

[jabbany]

不太清楚，反正当时ra.gg就说自己是 JSharer的后代╮(╯_╰)╭

[jabbany]

话说印象里 @Yangff 就有一个Node的百度网盘API实现？

[cnbeining]

JS说自己弄了个JSLC”计划。
简单的说，之前的FTP网盘烧钱太多，单线就没钱了。然后服务器就停了，说清理资源，然后就生存战略，已经2年了。其实很可惜的。
总之吧，他们也准备了基于云存储+P2P的计划。超强的multiupload。但是当时云存储贵啊，就没弄起来。
真是很好的东西，但是商业化我看不出来怎么办。恐怕还是需要像NPO一样做。募集资金也好得多啊。
太可惜了。其实吧，离熬出来就差1年。

上香。

BPCS的API已无数人封装了，python啥的都有了。。。直接拿来就有。。
在 2014年4月17日，下午5:46，Jim Chen notifications@github.com 写道：

话说印象里 @Yangff 就有一个Node的百度网盘API实现？

—
Reply to this email directly or view it on GitHub.

[ikeraiza]

现在云存储是降价了，但是免费公开还是烧钱。
自建的话还是ftp划算，下载我觉得可以考虑使用pt+bt方式，服务器直接做种
高级用户进pt，一般用户通通到bt。
不过这种貌似无法用于视频播放。。。
感觉视频文件自己分发还算是靠谱的，经过测试从景安云（10m）下载乌克兰和prq.se的文件都可以满速。
从樱花主机租用的也不错，kddi也有cdn服务。
这样的话几个人可以合作来建立一个分发网络。
视频的转码通通抛给百度网盘之类的，租一片ovz vps去分发。
2014/04/18 5:49 "David.Zhuang" notifications@github.com:

JS说自己弄了个JSLC”计划。
简单的说，之前的FTP网盘烧钱太多，单线就没钱了。然后服务器就停了，说清理资源，然后就生存战略，已经2年了。其实很可惜的。
总之吧，他们也准备了基于云存储+P2P的计划。超强的multiupload。但是当时云存储贵啊，就没弄起来。
真是很好的东西，但是商业化我看不出来怎么办。恐怕还是需要像NPO一样做。募集资金也好得多啊。
太可惜了。其实吧，离熬出来就差1年。

上香。

BPCS的API已无数人封装了，python啥的都有了。。。直接拿来就有。。
在 2014年4月17日，下午5:46，Jim Chen notifications@github.com 写道：

话说印象里 @Yangff 就有一个Node的百度网盘API实现？

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-40766911
.

[Yangff]

@jabbany 那个实现的比较搓，但是api地址基本就那些。
@sgdxpdqqzh
百度转码非常不给力，这个不多说，记得根本不支持高清。
而且网络你要考虑同时使用的用户数，就算给你满100m的流量，放个720p的，千号个人同时使用就sb了。这是真烧钱的。
低清的话直接从视频站解析手机/平板用的地址，只要考虑到iOS的视频站都会有低清晰度的。

[ikeraiza]

可以考虑要求用户上传经过压制mp4档吗？
或者转码交给云，租用一片ovz来存储高频率播放的视频来节约流量开支。
字幕组目前压制用4xe7的一个服务器，实际操作来看要是在发展初期只有一台这样的服务器就可以支撑转码。在某raw组干活的时候从edis租了个vps压制做种就很流畅了。
视频播放无法使用p2p技术，但是从wht荡上一片vps，每月开销不超过300$应该就可以支撑少数视频的大量同时播放。
要是使用现有商业云的话，流量费用一月岂止300。而且还有存储空间的计费。
2014/04/18 13:06 "Yangff" notifications@github.com:

@jabbany https://github.com/jabbany 那个实现的比较搓，但是api地址基本就那些。
@sgdxpdqqzh https://github.com/sgdxpdqqzh
百度转码非常不给力，这个不多说，记得根本不支持高清。
而且网络你要考虑同时使用的用户数，就算给你满100m的流量，放个720p的，千号个人同时使用就sb了。这是真烧钱的。
低清的话直接从视频站解析手机/平板用的地址，只要考虑到iOS的视频站都会有低清晰度的。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-40787188
.

[Yangff]

@sgdxpdqqzh p2p的话，技术上很难做到。
而且怎么看这么高的成本正常情况下都很难长时间支持吧。

[cnbeining]

P2P视频播放在HTML5下的实现：http://peer5.com/website/video.html
商业云是别想了。LEB上弄个机器还算靠谱。但是如果自己弄服务器，成本肯定是极高。
低清各个站都有，288P，绝对瞎眼。已经的成熟实现是@zythum 的妈妈计划。
虽然听起来不错，但是涉及到存储的时候，还是需要考虑是不是用私有的BPCS吧。否则一切成本自己出，受不了的。

[ikeraiza]

我觉得月支出在200$左右还是可以个人承受的。
2014/04/18 15:40 "David.Zhuang" notifications@github.com:

P2P视频播放在HTML5下的实现：http://peer5.com/website/video.html
商业云是别想了。LEB上弄个机器还算靠谱。但是如果自己弄服务器，成本肯定是极高。
低清各个站都有，288P，绝对瞎眼。已经的成熟实现是@zythum https://github.com/zythum 的妈妈计划。
虽然听起来不错，但是涉及到存储的时候，还是需要考虑是不是用私有的BPCS吧。否则一切成本自己出，受不了的。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-40792758
.

[m13253]

p2p的话，技术上很难做到。

P2P的话，HTML5的WebRTC技术你们不知道？

[cnbeining]

问题是，如果同时观看数不高，P2P意义不大。真正能省多少traffic还是未知的啊。

[Yangff]

@m13253 知道，但是那个东西问题挺多的。

[cnbeining]

http://biliplus.sinaapp.com/html/html5player.html
倒是有人简单的弄了一下，当然是最简单的MP4方式。用到了HTML5，不知道为什么作者选择故意略过ABPlayerHTML5这一名词。

[jabbany]

大概是因为听起来很山寨(´・ω・`)。。。。

[jabbany]

其实About里面有提到

[cnbeining]

https://github.com/binux/xunlei-lixian-proxy

三天不学习 赶不上刘少奇啊。

[jabbany]

这个会占用主机的上行和下行流量吧。。。