q191201771 / lal

🔥 Golang audio/video live streaming lib/client/server. support RTMP, RTSP(RTP/RTCP), HLS, HTTP[S]/WebSocket-FLV/TS, GB28181, H264/H265/AAC/G711/OPUS, relay, cluster, record, HTTP Notify/API/UI. 直播

Home Page:https://pengrl.com/lal

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

hls录制时间戳问题

yh4922 opened this issue · comments

请问大佬 hls 录制时文件名里面的时间戳是怎么生成的
900a4bb7b0a7a99a916d7a6644b571f
我的fragment_duration_ms间隔设置的是10000ms

按理说 第二个的时间戳应该等于 上一个的时间戳加上时长这样 但是实际上两个时间戳相差只有几十毫秒

commented

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个片段的生成时间是一样的 不知道是不是这个原因