关于r2h-seek-mode参数调试问题请教

[bsdcpp]

感谢大佬更新，阅读https://rtp2httpd.com/guide/time-processing 关于新参数的用法，尝试在url里添加如下：

catchup?playseek=20260509123400&r2h-seek-mode=range(UTC%2B8)

报错如下:

2026/05/09 23:01:21 DEBUG [Worker 0] Found r2h-seek-name parameter: playseek
2026/05/09 23:01:21 DEBUG [Worker 0] Found r2h-seek-mode: range (TZ +28800 sec, window 3600 sec)
2026/05/09 23:01:21 DEBUG [Worker 0] Using explicitly specified seek parameter name: playseek
2026/05/09 23:01:21 DEBUG [Worker 0] Found valid playseek parameter: 20260509173300
2026/05/09 23:01:21 DEBUG [Worker 0] Stripped r2h-token from upstream URL

。。。。。。。。。。

2026/05/09 23:01:21 DEBUG [Worker 0] RTSP: Request sent completely (303 bytes)
2026/05/09 23:01:21 DEBUG [Worker 0] RTSP: Request sent completely, waiting for response
2026/05/09 23:01:21 ERROR [Worker 0] RTSP: Server returned error code 404
2026/05/09 23:01:21 DEBUG [Worker 0] RTSP: Received complete header:
RTSP/1.0 404 Not Found
CSeq: 4
Server: FonsView SS/1.0
Date: Sat, 09 May 2026 15:01:21 GMT

2026/05/09 23:01:21 ERROR [Worker 0] RTSP: Failed to receive response

2026/05/09 23:01:21 DEBUG [Worker 0] Timezone: No TZ marker in User-Agent
2026/05/09 23:01:21 DEBUG [Worker 0] Parsed seek - begin='20260509173300', end=''
2026/05/09 23:01:21 DEBUG [Worker 0] Timezone: yyyyMMddHHmmss '20260509173300' (TZ offset 0) + seek offset 0 = '20260509173300'
2026/05/09 23:01:21 DEBUG [Worker 0] Converted begin time '20260509173300' to UTC '20260509173300'
2026/05/09 23:01:21 DEBUG [Worker 0] UTC seek parameter: '20260509173300'

不知道是不是上游不支持，请问是否可以提供类似cURL请求发起例子，在日志里似乎没有看到Range发送。详细日志如附件，麻烦看下

log.txt

[stackia]

这是我这边一个成功的例子

M3U: (playseek={utc:YmdHMS}-{utcend:YmdHMS}&r2h-seek-mode=range(3600))

#EXTINF:-1 tvg-id="CCTV2" catchup="default" catchup-source="rtsp://10.255.75.73:554/008/ch24042317213873124043?AuthInfo=[redacted]&citycode=089801&usercode=[redacted]&Playtype=1&bp=0&BreakPoint=0&programid=ch00000000000000001284&contentid=ch00000000000000001284&videoid=ch17022115354287633235&recommendtype=0&userid=[redacted]&boid=001&stbid=[redacted]&terminalflag=1&profilecode=&usersessionid=[redacted]&playseek={utc:YmdHMS}-{utcend:YmdHMS}&r2h-seek-mode=range(3600)",CCTV-2
rtp://239.253.64.195:5140/?fcc=10.255.75.73:15970$高清

通过 Range seek 回放时的日志

[Worker 0] New client 192.168.50.197:60819 requested URL: /%E5%A4%AE%E8%A7%86/CCTV-2/%E9%AB%98%E6%B8%85/catchup?playseek=20260510073120-20260510073442 (method: GET)

...

[Worker 0] Found r2h-seek-name parameter: playseek
[Worker 0] Found r2h-seek-mode: range (TZ from UA fallback, window 3600 sec)
[Worker 0] Using explicitly specified seek parameter name: playseek
[Worker 0] Found valid playseek parameter: 20260510073120-20260510073442

...

第一个 RTSP 请求，注意没有 playseek=：

RTSP: Prepared request:
OPTIONS rtsp://10.255.75.73/008/ch24042317213873124043?AuthInfo=w1Yh2hKJnMhfbjmvH5HAtGrl%2BESNqqgvBRWhlkhkUPp5ZRJt3V7H6LZ29nVKRTjX5OJJfl5dtq41BnEYyjpmvg%3D%3D&citycode=089801&usercode=1165898692&Playtype=1&bp=0&BreakPoint=0&programid=ch00000000000000001284&contentid=ch00000000000000001284&videoid=ch17022115354287633235&recommendtype=0&userid=1165898692&boid=001&stbid=00100599050108602000CC242E987266&terminalflag=1&profilecode=&usersessionid=335041456 RTSP/1.0
CSeq: 1
User-Agent: rtp2httpd/3.12.1

经过多次跳转，最终的 DESCRIBE 请求（依旧没有 playseek=）

[Worker 0] RTSP: Prepared request:
DESCRIBE rtsp://10.255.13.6:1554/iptv/import/Tvod/iptv/001/008/ch24042317213873124043.rsc/23472_Multi.sdp?lvst=3&nodeid=node24101117305062&TSTVTimeLife=10800&userid=[redacted]&userip=[redacted]&time=20260510073452.990+00&life=86400000&transferproviderid=008&ctype=01&sid=[redacted]&purl=[redacted]&domain=0&phycid=ch24042317213873124043&playtype=1&boid=001&urtm=0&agnt=[redacted]&sadr=[redacted]&iptvsessionid=[redacted]&cryptmode=0502&crypt=[redacted] RTSP/1.0
CSeq: 6
User-Agent: rtp2httpd/3.12.1
Accept: application/sdp

[Worker 0] RTSP: Response body data (state=6): v=0
o=- 0 0 IN IP4 127.0.0.1
s=ZMSS RTSP Server
c=IN IP4 239.253.64.195/16
b=AS:9196
t=0 0
a=control:*
a=x-zmssvbr:0
a=x-ZMSSTimeShiftLift:10800
a=x-ZMSSCCBitrate:9196
a=x-ZMSSProcessMode:2
a=range:clock=20260510T043453.00Z-20260510T073453.00Z
a=x-ZMSSCCStartTime:20251029T003629
a=slicetime:1800
m=video 5140 RTP/AVP 33
a=rtpmap:33 MP2T/90000
a=control:trackID=2

最后的 PLAY 请求

[Worker 0] RTSP: Prepared request:
PLAY rtsp://10.255.13.6:1554/iptv/import/Tvod/iptv/001/008/ch24042317213873124043.rsc/23472_Multi.sdp?lvst=3&nodeid=node24101117305062&TSTVTimeLife=10800&userid=1165898692&userip=10.254.35.198&time=20260510073452.990+00&life=86400000&transferproviderid=008&ctype=01&sid=470312259&purl=MTAuMjU1LjEzLjQvMDA4L2NoMjQwNDIzMTcyMTM4NzMxMjQwNDM_cmVjb21tZW5kdHlwZT0wJnByb2ZpbGVjb2RlPQ&domain=0&phycid=ch24042317213873124043&playtype=1&boid=001&urtm=0&agnt=MTAuMjU1LjEzLjQ6NTU0&sadr=MTAuMjU1LjEzLjY&iptvsessionid=335041456&cryptmode=0502&crypt=9931F2DA02EBDD32FC42092F2B587830 RTSP/1.0
CSeq: 8
User-Agent: rtp2httpd/3.12.1
Session: 6101006167962259122
Range: clock=20260510T073120Z-      <----- 注意这里有了 Range header

[stackia]

分析了一下你提供的日志

你在 23:01:21 时刻，请求了 17:33:00 时刻的回看，中间的时间差有五个多小时，超过了 range seek mode 默认的 3600 秒时间窗口，因此并没有走 range seek 路径，还是直接把 playseek 透传到了上游

[stackia]

如果想要增大时间窗口，可以这样写：

r2h-seek-mode=range(UTC%2B8/7200) 这样就是 7200 秒的窗口

像我这边运营商的节目列表，抓包时，可以获取到每一个频道支持的 range seek 时间窗口（TimeShiftLength），例如

Authentication.CTCSetConfig('Channel','ChannelID="3954",ChannelName="CCTV-1高清",UserChannelID="1",ChannelURL="igmp://239.93.0.184:5140",TimeShift="1",TimeShiftLength="7200",...

[bsdcpp]

如果想要增大时间窗口，可以这样写：

r2h-seek-mode=range(UTC%2B8/7200) 这样就是 7200 秒的窗口

像我这边运营商的节目列表，抓包时，可以获取到每一个频道支持的 range seek 时间窗口（TimeShiftLength），例如

Authentication.CTCSetConfig('Channel','ChannelID="3954",ChannelName="CCTV-1高清",UserChannelID="1",ChannelURL="igmp://239.93.0.184:5140",TimeShift="1",TimeShiftLength="7200",...

感谢，我看了我这边是3600秒，然后我改成: playseek={utc:YmdHMS}-{utcend:YmdHMS}&r2h-seek-mode=range(3600)或者playseek={utc:YmdHMS}&r2h-seek-mode=range(3600)
现在可以出来一个range，但是似乎不正确a=range:npt=0.000-18000.000，中间出来一下，然后最终请求没有。

具体日志：

log.txt

[stackia]

你请求的回放时间点是否是最近一小时？

从你最新的日志看，在 18:22:18 时间点，请求了 20260510 030300 (utc) 也就是 11:03:00 的回放，这样的话不在 3600 秒窗口内，不会触发 Range seek 路径

[bsdcpp]

你请求的回放时间点是否是最近一小时？

从你最新的日志看，在 18:22:18 时间点，请求了 20260510 030300 (utc) 也就是 11:03:00 的回放，这样的话不在 3600 秒窗口内，不会触发 Range seek 路径

哦，我正想问这个时间问题，大佬火眼金睛，请求最近一小时的确实可以了：

2026/05/10 18:39:29 DEBUG [Worker 0] RTSP: Response body data (state=6): v=0
o=- 1 1 IN IP4 0.0.0.0
s=RTSP Session
t=0 0
c=IN IP4 0.0.0.0
m=video 0 RTP/AVP 33
a=range:clock=20260510T063929Z-20260510T103929Z
.............

2026/05/10 18:39:29 DEBUG [Worker 0] RTSP: Prepared request:
PLAY rtsp://124.75.28.17:55554/LIVE/1202?AuthInfo=...=MP2T/UDP&DURATION=20260510T063929Z-20260510T103929Z&LID=1202&Provider_id=SHDXFH_live&Pcontent_id=00000001000000050000000000111128&FvSeid=4907e6c2a4455adc&FvTSDesb=1778409569-336426&TSDescribeResp=1778409569-344785 RTSP/1.0
CSeq: 8
User-Agent: rtp2httpd/3.12.1
Session: 620219162
Range: clock=20260510T101400Z-

哦，就是上一段rtsp录像播放完毕后，进入当前直播时间段直接接入实时播放对吧。

还有rtp2httpd的内置播放器，是支持实时Live直播的时移，其他aptv似乎不支持live的拖动，这是aptv的问题吧？

[stackia]

假设你正在看直播，然后突然想要往前退 30 秒，看 30 秒前的内容。如果按照传统的 playseek 方式的话，播放器只会请求最近 30 秒的片段（因为一般上游不支持在 playseek 的结束时间传入一个未来的时间），播放完之后才会请求下一个 30 秒的片段，会导致每 30 秒卡顿一次，因为这两个 30 秒片段，它们的 RTP 包序号不一定衔接，中间可能会存在少量丢包

而采用 Range Seek 方式，我们会在一次 RTSP Play 请求传入 Range Header，并且只传入 Start 的时间点，上游就会传输给我们从这个时间点开始所有的媒体包，包括直播正在进行中的媒体都会无缝拼接上来，播放器不需要反复多次请求，就不会产生卡顿

[bsdcpp]

内置播放器测试下来没问题，
aptv填入playseek={utc:YmdHMS}-{utcend:YmdHMS}&r2h-seek-mode=range(3600)
或者playseek=${(b)yyyyMMddHHmmss}&r2h-seek-mode=range(3600)只能播放最近一个小时的回看，其余回看全部无法播放。
而且它始终不支持live或者rtsp回看拖动。
感觉aptv都不如内置播放器香了，就等大佬出app了 :P

[stackia]

playseek=${(b)yyyyMMddHHmmss}-${(e)yyyyMMddHHmmss}&r2h-seek-mode=range(UTC+8/3600) APTV 可以尝试一下这样写

[bsdcpp]

playseek=${(b)yyyyMMddHHmmss}-${(e)yyyyMMddHHmmss}&r2h-seek-mode=range(UTC+8/3600) APTV 可以尝试一下这样写

好的，感谢，发现aptv不支持缺少end时间

[stackia]

而且它始终不支持live或者rtsp回看拖动

APTV 后续有计划去支持拖动

Kimentanm/aptv#139 (comment)

[bsdcpp]

playseek=${(b)yyyyMMddHHmmss}-${(e)yyyyMMddHHmmss}&r2h-seek-mode=range(UTC+8/3600) APTV 可以尝试一下这样写

感谢，暂时可以了，aptv无法拖动，比较难测试这个过程。看debug日志有正常range传递