hls录制时间戳问题

[yh4922]

hls录制时间戳问题

[q191201771]

fragment_duration_ms设置的间隔，是数据内时间戳的时间间隔，
文件名中的字段，是现实时间，
如果数据的发送速度快，远大于数据内时间戳的时间间隔，那么可能会出现这种情况。

[yh4922]

想请教一个问题 我因为业务上的需求需要把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个小时左右

[yh4922]

想请教一个问题 我因为业务上的需求需要把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个片段的生成时间是一样的 不知道是不是这个原因