如何存储音视频并支持从指定位置请求片段数据

先明确：你选择用文件系统存储音视频而非数据库，这个决策完全正确——数据库适合存元数据（比如文件路径、时长、码率），大文件放文件系统/对象存储能避免数据库膨胀，读写性能也更优。

关于你提出的JSON存片段方案 #

直接结论：不可行，核心问题有三个：

• JSON天生不适合存二进制Blob：把片段转成Base64序列化后，体积会凭空增大30%，而且序列化/反序列化的性能开销极高，大文件场景下完全扛不住
• 按秒拆分的粒度不合理：高码率视频每秒数据量可能达到几MB，单个JSON文件会迅速膨胀到GB级，读写时的IO成本爆炸
• 无标准编码支持：客户端无法直接解析这种自定义格式的片段，还要额外做解码适配，完全是舍近求远

可行的替代方案（适配Node.js+MySQL/MongoDB技术栈） #

1. 基于HTTP Range请求的原生方案（最推荐） #

不需要提前切割文件，利用HTTP标准的Range请求实现按需读取：

• 用MySQL/MongoDB存音视频元数据：比如文件ID、存储路径、总大小、时长、编码格式等
• Node.js服务器处理客户端发送的Range请求头（比如Range: bytes=1000000-2000000），直接从文件系统读取对应字节范围的内容，返回206 Partial Content状态码，同时带上Content-Range、Accept-Ranges等响应头
• 前端的<video>标签会自动触发Range请求，实现指定位置播放、断点续播，无需额外开发
• 简单代码示例：

const fs = require('fs').promises;
const path = require('path');
const http = require('http');

const server = http.createServer(async (req, res) => {
  const videoPath = path.join(__dirname, 'your-video.mp4');
  const stat = await fs.stat(videoPath);
  const totalSize = stat.size;

  if (req.headers.range) {
    const [startStr, endStr] = req.headers.range.replace('bytes=', '').split('-');
    const start = parseInt(startStr, 10);
    const end = endStr ? parseInt(endStr, 10) : totalSize - 1;
    const chunkSize = end - start + 1;

    res.writeHead(206, {
      'Content-Range': `bytes ${start}-${end}/${totalSize}`,
      'Accept-Ranges': 'bytes',
      'Content-Length': chunkSize,
      'Content-Type': 'video/mp4',
    });

    const stream = fs.createReadStream(videoPath, { start, end });
    stream.pipe(res);
  } else {
    res.writeHead(200, {
      'Content-Length': totalSize,
      'Content-Type': 'video/mp4',
    });
    fs.createReadStream(videoPath).pipe(res);
  }
});

server.listen(3000);

2. 提前转码为HLS/DASH流媒体格式 #

如果需要更精细化的分段控制（比如固定10秒一个片段），可以用FFmpeg把音视频转成HLS或DASH格式：

• 执行FFmpeg命令转码：ffmpeg -i input.mp4 -c:v h264 -c:a aac -hls_time 10 -hls_list_size 0 output.m3u8，会生成每个10秒的.ts片段和一个.m3u8索引文件
• 数据库存储索引文件路径、每个片段的时长、字节大小等信息
• Node.js只需要提供静态文件服务，客户端通过解析.m3u8文件自动请求对应时间段的片段，实现精准跳转
• 优势：兼容性好，支持自适应码率（根据网络状况切换清晰度），CDN缓存效率更高

3. MongoDB GridFS（小众场景可选） #

如果非要用数据库管理片段，MongoDB的GridFS可以考虑：

• GridFS会自动把大文件分割成256KB的小块存储，同时记录文件元数据
• 通过Node.js的mongoose GridFS API，可以读取指定范围的块并拼接返回
• 注意：性能不如直接文件系统，只适合小批量、需要数据库事务控制的场景，不推荐大规模使用

大厂的典型实现逻辑 #

• YouTube/Netflix：采用HLS/DASH自适应码率流媒体，提前把视频转成多码率的分段文件，用CDN缓存热门片段，客户端根据网络自动切换清晰度
• 国内视频平台（腾讯/爱奇艺）：结合本地文件系统+对象存储（OSS/COS），CDN加速分发，后端通过HTTP Range请求或HLS分段实现按需播放，数据库只存视频元数据（标题、时长、存储地址、播放量等）
• 核心共性：用文件系统/对象存储存实际音视频数据，数据库只存元数据，依靠HTTP标准或成熟流媒体协议实现分段播放，绝不会用JSON存Blob这种低效方案

内容的提问来源于stack exchange，提问作者monreald