V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
horou
V2EX  ›  程序员

请教兄弟们一个关于服务器视频存储的问题

  •  
  •   horou · 2023-01-11 15:05:46 +08:00 · 2189 次点击
    这是一个创建于 689 天前的主题,其中的信息可能已经有所发展或是发生改变。

    目前网站上是使用的 m3u8 的方式播放的视频

    视频文件的存储是该如何存储呢,是存储 mp4 的源文件还是存储分片后的 m3u8 文件?

    目前使用的是对象存储直接存储的 m3u8 文件,但是我发现对象存储还会根据请求数量收费,一个视频会被切分为几百上千个文件,感觉成本会很高啊。

    还有如果我想提供一个用户下载视频的功能,该如何做,让下载下来的视频就是个 mp4 的文件

    18 条回复    2023-01-12 12:12:42 +08:00
    ysc3839
        1
    ysc3839  
       2023-01-11 15:09:16 +08:00 via Android
    那就直接存 mp4
    horou
        2
    horou  
    OP
       2023-01-11 15:12:21 +08:00
    @ysc3839 那该如何用 hls 的方式播放视频,服务端实时切片吗...
    opengps
        3
    opengps  
       2023-01-11 15:18:55 +08:00
    需要找个折中点,MP4 的不是按需请求,请求次数会少但是流量费可能会更高
    learningman
        4
    learningman  
       2023-01-11 15:21:40 +08:00
    MP4 的 range 请求请求数也不会少吧,还是说如果是 range 请求一个文件就算一次请求数?
    dream4ever
        5
    dream4ever  
       2023-01-11 15:25:00 +08:00
    我们公司的业务只有视频点播的需求,没有直播的需求也没有下载视频的需求,所以我写了一个 JS 脚本,调用 FFmpeg 对所有视频进行规范化处理,最后生成一个 m3u8 文件 + 一个 ts 文件传到云服务器上,Web 前端用 hls.js 播放。这个解决方案兼容性也 OK ,这几年一直用着。
    biguokang
        6
    biguokang  
       2023-01-11 15:27:33 +08:00
    好奇问下什么场景下会使用 m3u8 格式储存视频文件,在我印象里 m3u8 要么就是用来做直播业务,要么就是一些流媒体平台用来规避视频窃取的风险,加大视频窃取难度。

    如果没有这方面的需求,直接存 mp4 不是更好吗??

    如果要我猜,你的做的网站是提供有版权视频的在线播放,所以用 m3u8 规避视频窃取(其实只是增加窃取操作成本,网络上一堆免费在线 m3u8 提取服务),然后付费用户则是可以直接下载 mp4 文件???
    horou
        7
    horou  
    OP
       2023-01-11 15:43:37 +08:00
    @biguokang 这两个你都猜对了,还有就是视频播放时的缓冲速度相对 mp4 来说会快些
    darling19961030
        8
    darling19961030  
       2023-01-11 15:45:48 +08:00   ❤️ 1
    1. 网页播放 mp4 需要下载下来
    2. 切分成 m3u8 是为了解决 1
    3. ffmpeg 可以切分也可以合流,可以在下载 mp4 时先合并再下载
    4. 或者搭建流媒体服务器,存储 mp4 ,网页播放时转为 m3u8
    biguokang
        9
    biguokang  
       2023-01-11 15:47:05 +08:00
    不过如果网站是以在线视频为主的,那目前大多数的方案的确是 m3u8 为主。

    可惜现在纯前端方案是没办法做 m3u8 converter mp4 工作的,这种目前只能在后端做,好在相关的后端库 github 一大堆,如果下载视频的使用量很大对于后端转换也是个负担。

    如果这样只能建议视频存两份,一份存 m3u8 提供在线播放,一个存 mp4 提供下载。

    想节省点空间资源的话,可以两种方案结合,如果这个视频从来没人下载,那么就一直是 m3u8 ,如果有第一个人下载,那就把该视频在后端转换成 mp4 然后传到云厂商的对象储存,以后下载该视频的人直接去取 mp4 就行了。
    learningman
        10
    learningman  
       2023-01-11 15:59:06 +08:00
    @biguokang #9 其实是可以的,ffmpeg 编译成 wasm 放到 webworker 里跑,生成的文件放进 indexedDB 再转成 Blob 给用户下载
    考虑到 m3u8 转 mp4 完全就是拼接,其实也不会有太大开销。
    ysc3839
        11
    ysc3839  
       2023-01-11 16:09:23 +08:00 via Android
    @horou 不切不就好了?
    @opengps 个人认为流量不会多,请求也不会更多,因为浏览器会用 range 请求。如果是 m3u8 切了,要对切片进行 range 请求,次数反而会变多,除非切得很碎,但是切太碎的话正常播放请求数也会变多。
    有完整 mp4 下载需求的话还是别切好,省空间。
    ysc3839
        12
    ysc3839  
       2023-01-11 16:11:55 +08:00 via Android   ❤️ 1
    @horou 缓冲慢我怀疑是没有处理 mp4 。没记错的话普通的 mp4 是把一些元数据放在末尾的,浏览器播放时就要先请求头部,发现没有元数据再请求末尾,然后才能开始播放。处理过后元数据也在头部,就没有这种问题了。建议监控浏览器的请求看看是不是这个问题。
    biguokang
        13
    biguokang  
       2023-01-11 16:13:23 +08:00   ❤️ 1
    等等,我倒是在 github 上找到了纯前端的方案,你可以参考下这个项目

    https://github.com/Momo707577045/m3u8-downloader


    看了下原理是用 mux.js 实现前端转码,你可以看看他的源码把有效部分 copy 下来,然后就能在纯前端实现转码了,不用耗费服务器资源
    ysc3839
        14
    ysc3839  
       2023-01-11 16:16:13 +08:00 via Android
    @dream4ever 只用一个 ts 的话相比 mp4 没有优势。mpegts 是把数据拆成一个个固定长度(188 字节)的数据包,每个包里面都有元数据,会让体积变大。
    horou
        15
    horou  
    OP
       2023-01-11 16:43:12 +08:00
    @ysc3839 感谢详细的解答,我大概清楚怎么做了

    @biguokang 非常感谢,回头我研究一下这个项目

    @darling19961030 谢谢解答,不过搭建流媒体服务成本应该很高吧,暂时还是不考虑这个方案了
    IvanLi127
        16
    IvanLi127  
       2023-01-12 01:06:49 +08:00 via Android
    一个 mp4 就好。不过建议看看新格式,从编码格式上减少体积,或许也有改善。 话说套 cdn 会不会更便宜点?
    dream4ever
        17
    dream4ever  
       2023-01-12 11:08:23 +08:00
    @ysc3839 对视频这块儿一直没有深入研究,公司阿里云服务器用的 Windows + IIS ,之前不知道遇到了什么问题,mp4 视频只能全部下载完之后才可以播放,当时大概研究了一下解决方案,就定下来用 m3u8 + ts 了,之后也一直没有再改。
    ysc3839
        18
    ysc3839  
       2023-01-12 12:12:42 +08:00 via Android
    @dream4ever 应该是我前面说的元数据在末尾的问题吧
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2821 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 07:39 · PVG 15:39 · LAX 23:39 · JFK 02:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.