优化措施总览
培训视频压缩
培训视频，多为PPT讲解的MP4视频，画面长时间静止，变化很慢，即“低动态”特性，本可以进行极限压缩，但目前没有极限压缩，50分钟的视频高达2.2G，理论上可压到400M以内。
前端播放优化
前端若把整个视频当做静态资源，浏览器全部下载完成后才能开始播放，极不合理，急需优化。要改成流式播放机制。
上CDN加速
上CDN、点播加速。
详细优化方案 （仅供参考）
文档对象：开发组、运维组、测试组
项目背景：基于300M出口带宽与局域网对象存储，为全国用户提供培训视频点播服务。
核心挑战：现有视频体积过大（2.2G/50min），前端加载方式错误（全量下载），导致带宽击穿及播放延迟。
一、 总体架构设计
摒弃原有的“全量下载后播放”模式，采用“高效转码 + 伪流媒体传输 (Pseudo-streaming)”架构。
[存储层: MinIO/Ceph] [应用层: Nginx Server] [传输层: 300M带宽] [终端: 浏览器/App] | | | | | <--- (1) 读取文件流 ------ | | | | | <--- (2) HTTP Range 请求 ---- | <--- (3) 按需取流 ------- | [原始视频库] | | | | | ------- (4) 返回 206 Partial Content 数据块 ------------> | +--[转码工作流]---> [成品库] | | [前端播放组件: XGPlayer] (FFmpeg压缩) (MP4/H265)| | (边下边播，带缓存)二、 核心模块实施细节
1. 媒体处理模块（后端/转码组）
现状问题：培训视频码率过高（~6Mbps），存在大量冗余数据；MP4元数据在文件尾部。（51分钟的PPT视频，大小高达2.2G）
实施目标：将文件压缩至200MB-350MB（码率 < 800Kbps），并实现秒开。
FFmpeg 标准转码指令（生产环境配置）：
请编写脚本，对所有历史视频和新上传视频执行以下处理：
ffmpeg -i input_source.mp4\-c:v libx264\-preset veryslow\-crf26\-r15\-g150\-sc_threshold0\-tune stillimage\-c:a aac -b:a 64k\-movflags +faststart\output_optimized.mp4关键参数说明（必读）：
-r 15：强制帧率降为15fps（PPT讲解类视频流畅度阈值），直接减少50%体积。-tune stillimage：针对PPT/静态画面优化的核心算法，大幅降低静态帧码率。-crf 26：恒定质量因子，平衡画质与体积。-movflags +faststart：极重要！将moov元数据移至文件头，浏览器只需下载前几KB即可开始播放，无需等待全量下载。
2. 前端播放模块（前端开发组）
现状问题：使用axios/fetch下载 Blob 对象，导致首屏加载极慢，且容易内存溢出。
实施目标：实现“边下边播”，支持倍速播放。
整改要求：
- 废除所有将视频作为静态资源全量下载的代码逻辑。
- 引入成熟的开源播放器组件（推荐XGPlayer或 Video.js）。
代码参考实现 (Vue/React/Vanilla JS通用)：
<!-- 引入西瓜播放器 SDK --><scriptsrc="//unpkg.com/xgplayer@2.31.2/browser/index.js"></script><divid="mse"></div><script>letplayer=newPlayer({id:'mse',url:'http://your-domain.com/video/training_001.mp4',// 指向优化后的视频地址width:'100%',height:'auto',playbackRate:[0.5,0.75,1,1.5,2],// 开启倍速播放功能pip:true,// 支持画中画autoplay:false,videoInit:true,// 初始化时预加载首帧，提升体验// 关键配置：确保请求是分段的download:false});</script>3. 服务端网络配置（运维组）
Nginx 配置优化：
确保 Nginx 正确响应Range请求，并开启大文件传输优化。
http { # 开启高效文件传输模式 sendfile on; tcp_nopush on; tcp_nodelay on; server { location /video/ { alias /data/video_storage/; # 允许跨域（如果前后端分离） add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods 'GET, HEAD, OPTIONS'; # 浏览器缓存策略：强制缓存1年（视频文件不会变） expires 365d; add_header Cache-Control "public, max-age=31536000"; # 确保服务器支持断点续传/Range请求（Nginx默认支持，需确认未被关闭） # 验证方式：Response Header 中包含 Accept-Ranges: bytes } } }三、 性能与带宽测算（验证）
优化后指标预测：
| 指标项 | 优化前 | 优化后 | 备注 |
|---|---|---|---|
| 单视频大小 | 2.2 GB | ~0.25 GB | 体积减少约 88% |
| 平均码率 | 6 Mbps | ~0.7 Mbps | |
| 80人并发带宽需求 | 480 Mbps | 56 Mbps | 部局互联网出口300M带宽利用率仅需 18% |
| 首屏加载时间 | > 60秒 (下载完) | < 2秒(边下边播) | 用户体验质变 |
结论：在优化后，现有的300M带宽不仅能满足80人并发，理论上可支持300-400人同时观看而不卡顿。
四、 验收测试标准（QA Checklists）
- 视频元数据检查：
- 使用工具
MediaInfo查看转码后的视频，确认Writing library包含x264，且帧率为15.000 fps。
- 使用工具
- 网络请求检查（关键）：
- 在 Chrome 开发者工具 -> Network 栏。
- 拖动进度条时，必须看到新的 HTTP 请求产生。
- 请求状态码（Status Code）必须是206 Partial Content（而非 200 OK）。
- Response Headers 中必须包含
Content-Range和Accept-Ranges: bytes。
- 并发压力测试：
- 在公司内部组织 10-20 人同时播放不同视频，观察拖拽进度条是否流畅，防火墙出口流量是否在控制范围内（预计20人约占15Mbps）。
五、 应急预案
虽然带宽已足够，但为了防止极端情况（如所有人在同一秒点击播放）：
- Nginx 限流：配置
limit_conn，限制单个IP的最大连接数为 5，防止多线程下载工具抢占带宽。 - 前端降级：如果播放器检测到加载失败，提示“正在为您切换线路”（实际是重试机制），避免直接报错。
