hls录制时间戳问题
yh4922 opened this issue · comments
fragment_duration_ms设置的间隔,是数据内时间戳的时间间隔,
文件名中的字段,是现实时间,
如果数据的发送速度快,远大于数据内时间戳的时间间隔,那么可能会出现这种情况。
想请教一个问题 我因为业务上的需求需要把m3u8
格式化成下面的格式
我现在的方式是开启LAL的 cleanup_mode = 2 的录制模式 然后我实时读取playlist.m3u8文件解析最新的片段信息
#EXTINF:3.597,
rtsp_192_168_18_103_live_fall1-1698910754482-2.ts
因为业务的需求需要把m3u8文件格式化成下面这种格式
#${片段时间}.ts,${开始时间},${结束时间}
2023-11-02-12.04.03.ts,0.000000,10.790000
2023-11-02-12.04.14.ts,10.790000,21.578999
.....
2023-11-02-13.38.01.ts,5638.600586,5649.390625
2023-11-02-13.38.12.ts,5649.390625,5660.179688
# 如果中途录像有中断会重新开始计时
2023-11-02-13.36.07.ts,0.000000,10.790000
2023-11-02-13.36.18.ts,10.790000,21.578999
新生成的片段时间我是用上一个片段的时间累加上片段的duration得到的
这种方式有个问题 我录制了一天之后 我累加的时间会比当前时间慢5个小时左右
想请教一个问题 我因为业务上的需求需要把
m3u8
格式化成下面的格式我现在的方式是开启LAL的 cleanup_mode = 2 的录制模式 然后我实时读取playlist.m3u8文件解析最新的片段信息
#EXTINF:3.597, rtsp_192_168_18_103_live_fall1-1698910754482-2.ts
因为业务的需求需要把m3u8文件格式化成下面这种格式
#${片段时间}.ts,${开始时间},${结束时间} 2023-11-02-12.04.03.ts,0.000000,10.790000 2023-11-02-12.04.14.ts,10.790000,21.578999 ..... 2023-11-02-13.38.01.ts,5638.600586,5649.390625 2023-11-02-13.38.12.ts,5649.390625,5660.179688 # 如果中途录像有中断会重新开始计时 2023-11-02-13.36.07.ts,0.000000,10.790000 2023-11-02-13.36.18.ts,10.790000,21.578999
新生成的片段时间我是用上一个片段的时间累加上片段的duration得到的
这种方式有个问题 我录制了一天之后 我累加的时间会比当前时间慢5个小时左右
我在pkg/hls/muxer.go
调试发现,会同时创建3个片段 3个片段的生成时间是一样的 不知道是不是这个原因