予观直播之业，时日既久，有得焉：

添置播放器，实为易事。

至若扩流之艰，乃在信守其序。

今之文，将吾于构筑直播与流媒体之基时所得之术，以陈于众。

*1. 播放器非系统之全，乃其微末耳。
*
初时，系统甚为简明。
<video controls autoplay>
<source src="stream.m3u8">
</video>
初试之时，正勤勉也。

然真实用户流量生患矣。

用戶網絡速率各異
移動裝置變遷矣
瀏覽器之行止殊異也
音质时好时坏

此时唯视频标签不足矣。

直播系统之层级，远超吾之预期。

*二、HLS之播，较所期更为繁复。
*
初，吾以单视频文件之法度之。

然直播之境，事殊也。

一HLS流之貌，大抵若此：
`master.m3u8

720p.m3u8
480p.m3u8
360p.m3u8

segment001.ts
segment002.ts
segment003.ts`

初视此构，似无谓焉。

继而悟之：

用户连接变换，质量随之更迭。

由此得：

低速网络卡顿渐少。
移动用户观感更稳。
数据使用得宜。

自适应码率系统，于直播之事，影响殊深。

*三、使用Flussonic时，主要问题非安装，实为交通管理
*
初试安装Flussonic，较之预期，颇为简易。

根本之发布定义：

`流渠一`

输入udp://239.1.1.1:1234

}
veya
流渠一

输入http://example.com/live.m3u8;

}`
数刻之内即启功。

然用户渐增，新患随之：

同瞬间千百连接
耗RAM甚巨
CPU之用繁
输出之费昂

要难非在Flussonic之设，而在播传之构也。

*四。技术服务器之理，速达其境
*
首系统：
`用户

↓

网页服务器

↓

流媒体服务器`
初时足矣。

然并时用户增，遂生滞碍。

其后，形神相离矣。
负载均衡器

↓

网络服务器(Webservers)

↓

流节点

↓

内容分发网络（CDN）

此法也：

山川分布益善矣
减损其抗阻之患
增其可扩展之能

直播项目之中，我所思之建筑，反不如事之要。

1. 最大之困，非CPU，乃转码之患。

初时，吾以为服务器之负，在于网页之侧。

然实则，最大之负：

视频之转换。

例：
ffmpeg -i source.ts \
-c:v libx264 \
-b:v 3000k \
-hls_time 4 \
output.m3u8
一旦多产诸般品质：

1080p
720p
480p
360p

CPU之用渐增矣.

尤以同频频道增时，视频之处理，耗资甚巨.

1. 播放器之选，较预期尤重.

初试之际，犹用标准视频播放器。

其后，于HLS（High-Level Synthesis）之道，吾尝试诸异法。

HLS.js(HLS.js)
視頻播放器視頻.js
沙卡播放器(Shaka Player)

例文
`

`

const video =
document.getElementById("player");

const hls=new Hls();

hls.loadSource(
"stream.m3u8"
);

hls.attachMedia(video);

或有器具供本地HLS支持，或需JavaScript侧处理。

浏览器差异之影响，较我所思为甚。

*7. 多余之特性，非恒致佳果。
*
初，吾欲增：

自动品质变换之面板
动态计数器
动画式频道切换
实时统计

然用户之行各异

多数用户惟求：

速启之播
低延之候
无间之观

耳

间有简系统，反得佳果

果

生视平台初看似简，然规模既广，事则全非。

其真难者：

视频之布，
迟滞之御，
网费之重，
转码之术，
可展之能，
流映之构，

是皆显于斯。

添置一播放器，需时数刻。

然，构设一永续无间之直播系统，则非同寻常之事。

所恃之资：

• Flussonic 文档：https://flussonic.com/doc
• FFmpeg 文档：https://ffmpeg.org/documentation.html
• HLS 规范：https://datatracker.ietf.org/doc/html/rfc8216
• 例：直播电视
• 视频播放器.js 文档：https://videojs.com