时移回看功能的核心不是“录下来”，而是用切片存储和实时转码把直播流切成小文件，按时间轴快速定位；存储开销取决于码率、频道数和保留时长，转码则决定回看能否在手机、电视、电脑上流畅播放。
时移回看需要多大存储空间？先算清码率和时长
很多人一上来就问服务器要多大硬盘,其实先得搞清楚一个频道一天到底吃多少空间，码率是决定因素，计算方式很直白：把码率从 Mbps 换算成 MB/s，再乘以时间。
以常见的高清频道 8Mbps 码率为例，单频道 24 小时的存储量约为：
8Mbps ÷ 8 × 3600 × 24 ≈ 86.4GB
也就是说,一个高清频道存满一整天，差不多要吃掉 86GB 左右，不同码率的差异很明显：
| 码率类型 | 参考码率 | 单频道24小时存储量 |
|---|---|---|
| 标清 | 4Mbps | 约43GB |
| 高清 | 8Mbps | 约86GB |
| 超清 | 12Mbps | 约130GB |
| 4K | 25Mbps | 约270GB |
这个表是估算值,实际存储还会受编码格式影响，H.265 比 H.264 在同等画质下码率能低不少，存储量也会相应下降。
频道数量和保留天数怎么配
有了单频道日存储量,再乘频道数，再乘保留天数，总容量就出来了，比如一个酒店有 50 个高清频道，要求回看保留 7 天：
50 × 86GB × 7 ≈ 30.1TB
这还没算时移缓存,时移通常只保留最近 2 到 6 小时，占用空间小，但回看是完整节目单，按天算，占大头，多数项目里，回看存储占整体容量的 80% 以上，时移缓存只占一小块。
所以规划存储时,先列频道清单，分清楚哪些频道需要时移，哪些需要回看，哪些只需要直播，不要所有频道都开回看，那样硬盘费用会翻着倍涨。
存储盘阵和冷热分层
存储不能只堆容量,还要考虑读写速度，时移对延迟极其敏感，用户拖动进度条时，系统要在几百毫秒内定位到切片文件，所以时移缓存一般放在 SSD 或 NVMe 盘上，保证随机读取速度。
回看文件是顺序读取,对速度要求没那么苛刻，可以用 HDD 机械盘阵列，RAID5 或 RAID6，更早的节目可以做冷归档，用大容量低转速盘甚至磁带库，成本低很多。
时移回看服务器价格里，存储硬件往往占一半以上，冷热分层设计能明显降低整体投入，行业共识认为，时移切片时长控制在 4 到 6 秒，能在索引精度和文件数量之间取得较好平衡。
时移和回看有什么区别？存储策略完全不同
这两个功能经常被一起提起,但底层逻辑差得挺远，时移像是给直播流装了一个“倒带键”，只能回看最近几小时的内容；回看则是按节目表录制的完整节目，可以看昨天、前天的内容。
时移是临时缓存，回看是长期归档
时移的数据是环形覆盖的,比如设置保留 4 小时，系统就只存最近 4 小时的切片，新切片写入时，最老的切片自动删除，用户最多往回拖到 4 小时前，再往前就没有了。
回看不一样,回看按 EPG 节目单切条，一个节目一个文件或一组切片，节目结束后，这个文件从时移缓存区转移到回看存储区，按保留天数长期保存，7 天、14 天，过期后再统一清理。
所以时移和回看虽然都靠切片,但生命周期管理完全不同，一个像临时停车位，随停随走；一个像长期车库，按天计费。
切片与索引技术
切片是时移回看的基础,主流做法是把直播流切成 TS 切片，配合 HLS 协议生成 m3u8 索引文件，每个切片时长一般设为 4 到 6 秒，这样用户拖动进度条时，系统能快速跳到对应时间点。
用 FFmpeg 可以一条命令生成 HLS 切片：
ffmpeg -i input.ts -c copy -f hls -hls_time 6 -hls_list_size 0 output.m3u8
这条命令不重新编码,只是把输入流转封装成 HLS 切片。-hls_time 6 控制切片时长，-hls_list_size 0 表示保留全部切片，不做自动删除。
回看场景下,还可以把每个节目转封装成单个 MP4 文件，方便点播和 CDN 分发，命令同样简单：
ffmpeg -i input.ts -c copy -f mp4 output.mp4
这里的关键是 -c copy，表示只换容器不重新编码，速度极快，几乎不消耗 CPU。
转封装和转码的取舍
转封装（remux）和转码（transcode）是两个概念，转封装只是换文件格式，视频编码不变，比如从 TS 流变成 MP4，速度快、资源占用低，转码则是重新编码视频，比如把 H.265 转成 H.264，或者把 4K 降到 720p，消耗大量 CPU 或 GPU 资源。
时移回看系统里,能用转封装就不用转码，只有遇到终端不支持原编码时，才需要转码，比如有些老款手机只认 H.264，而直播源是 H.265，这时才启动转码任务。
酒店IPTV时移回看方案：转码能省则省
酒店 IPTV 场景有个天然优势：终端统一，房间里都是同一型号或同一系列的机顶盒，解码能力一致，不用考虑五花八门的手机、平板兼容问题。
所以酒店 IPTV 时移回看方案里，多数情况下不需要实时转码，直播源是 H.264 TS 流，机顶盒也支持 H.264，直接切片存储，回看时原样吐给机顶盒就行，省掉了转码卡，服务器成本能降一大块。
酒店频道的数量通常不多,一般 30 到 50 个，码率也以高清为主，按前面算的，50 个高清频道回看 7 天需要约 30TB 存储，一台带 8 盘位 HDD 的服务器，配 RAID5，可以轻松扛下来。
北京地区酒店或运营商在部署时移回看时,更倾向采用中心机房集中存储、边缘节点不落盘的方式，楼层交换机只做直播转发，回看请求统一回到中心服务器，这样维护简单，硬盘故障风险也集中管控。
实操：三步搭一个简易时移回看服务
想快速验证时移回看流程,不用上复杂平台，一台 Linux 服务器加 FFmpeg 就能跑通。
第一步：拉流并转切片
先用 FFmpeg 从直播源拉流，同时生成 HLS 切片，假设直播源是 UDP 组播地址：
ffmpeg -i udp://239.1.1.1:1234 -c copy -f hls -hls_time 6 -hls_list_size 0 /data/hls/channel01.m3u8
这条命令会把组播流转成 6 秒一个的 TS 切片，存放在 /data/hls/ 目录下，channel01.m3u8 是索引文件。
第二步：配置 Nginx 提供切片访问
切片生成后,用 Nginx 做一个静态文件服务，把 /data/hls/ 目录暴露出去：
location /hls/ {
alias /data/hls/;
add_header Cache-Control no-cache;
}
这样播放器就能直接请求 http://服务器IP/hls/channel01.m3u8 获取时移流。
第三步：实现回看查询接口
时移直接拿 m3u8 就行，回看则需要根据节目单找到对应时间段的切片，简单做法是把每个节目开始和结束时间记录到数据库，回看时根据时间戳拼出切片文件名。
比如一个节目从 20:00 到 20:45，切片文件命名规则是 channel01_20260601_200000.ts 这种，查询接口只要返回前一条 m3u8 里对应时间范围内的切片列表即可。
业内专家指出,回看存储的冷热分层设计能显著降低整体硬件投入，尤其适合频道多、保留天数长的项目。
时移回看服务器价格怎么定？先看存储和转码卡
时移回看服务器价格没有统一标准，主要受三个因素影响：存储容量、转码能力和网络带宽。
存储容量越大,硬盘和阵列卡成本越高，8 盘位和 24 盘位的服务器，价格能差好几倍，转码能力要看是否需要实时转码，如果需要多路同时转码，通常要加独立 GPU 转码卡，单卡能同时处理十几路高清转码，但成本不低。
网络带宽也要考虑,尤其时移拖动频繁时，切片小文件很多，对 IOPS 和带宽都有要求，千兆网卡是基础，万兆网卡在频道多、用户多的情况下更稳妥。
实际项目中,一台支持 20 路高清时移回看的入门级服务器，不加转码卡，存储为主，硬件成本里存储盘通常占 50% 以上，CPU 和主板次之，网卡和电源再次，具体价格因品牌、渠道、采购数量差异很大，建议按需询价，不要盲目比价。
统一思路：先算码率，再定硬件
时移回看的底层设计不复杂,抓住两条线就够了，一条是存储线：码率乘以时间乘以频道数，得出容量，再按时移和回看分开配置介质，另一条是转码线：能用转封装就不用转码，终端统一时直接省掉转码环节。
切片是连接这两条线的桥梁,4 到 6 秒一个切片，既能保证拖动响应速度，又不会产生过多小文件拖垮文件系统，先把切片策略定下来，存储和转码的设计就有了共同基准。
Q&A
时移回看功能怎么实现？
时移回看通过把直播流切片存储实现,直播流进入服务器后，用 FFmpeg 或专用转封装工具切成 TS 切片，同时生成 m3u8 索引，时移直接读取最近几小时的切片，回看则根据节目单把对应时间段的切片返回给播放器，核心是切片时间和索引机制。
时移回看需要多大存储空间怎么估算？
先确定单频道码率,用公式 码率(Mbps) ÷ 8 × 3600 × 24 算出单频道日存储量，再乘以频道数和保留天数，8Mbps 高清频道一天约 86GB，50 个频道保留 7 天约需 30TB，时移缓存通常保留 2 到 6 小时，占用空间小，按总容量的 10% 到 20% 预留即可。
时移和回看可以共用一套存储吗？
可以共用物理存储,但逻辑上要分层，时移缓存放在 SSD 上，保证随机读取速度；回看文件放在 HDD 阵列上，按天保留，同一个切片文件可以先在 SSD 上完成时移服务，节目结束后迁移到 HDD 作为回看归档，这样既满足性能要求，又控制整体存储成本。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/647818.html
