rtsp-relay
rtsp-relay copied to clipboard
Not working with H265 (hevc) streams :(
Works goregeously with the rtsp server I have on my phone for testing, but my IPCAM streams in HEVC which does not play nice. I'm in the process of tweaking with the ffmpeg options but it really doesn't want to play ball. Here's what I'm getting on stderr:
[rtsp @ 0x1bd71e0] max delay reached. need to consume packet
[rtsp @ 0x1bd71e0] RTP: missed 1 packets
[rtsp @ 0x1bd71e0] max delay reached. need to consume packet
[rtsp @ 0x1bd71e0] RTP: missed 2 packets
[rtsp @ 0x1bd71e0] max delay reached. need to consume packet
[rtsp @ 0x1bd71e0] RTP: missed 3 packets
Guessed Channel Layout for Input Stream #0.1 : mono
Input #0, rtsp, from 'rtsp://myusername:[email protected]/ch0_0.264':
Metadata:
title : ch0_0.264
comment :
minisdp
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Video: hevc (Main), yuv420p(tv, bt470bg), 1920x1080 [SAR 1:1 DAR 16:9], 15 fps, 15 tbr, 90k tbn, 15 tbc
Stream #0:1: Audio: pcm_alaw, 8000 Hz, mono, s16, 64 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (hevc (native) -> mpeg1video (native))
Stream #0:1 -> #0:1 (pcm_alaw (native) -> mp2 (native))
Press [q] to stop, [?] for help
[mpeg1video @ 0x1c2b840]
warning, clipping 1 dct coefficients to -255..255
frame= 10 fps=0.0 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 32 fps= 31 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 52 fps= 33 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 73 fps= 35 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
[rtsp @ 0x1bd71e0] max delay reached. need to consume packet
[rtsp @ 0x1bd71e0] RTP: missed 204 packets
[hevc @ 0x1cac9b0] The cu_qp_delta 26 is outside the valid range [-26, 25].
[rtsp @ 0x1bd71e0] max delay reached. need to consume packet
[rtsp @ 0x1bd71e0] RTP: missed 16 packets
frame= 87 fps= 33 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
[hevc @ 0x1c827f0] Could not find ref with POC 8
frame= 94 fps= 29 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 108 fps= 29 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 113 fps= 26 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 116 fps= 24 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 132 fps= 25 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 139 fps= 24 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 147 fps= 23 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 155 fps= 22 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 161 fps= 22 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 167 fps= 21 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
[rtsp @ 0x1bd71e0]
max delay reached. need to consume packet
[rtsp @ 0x1bd71e0]
RTP: missed 4 packets
frame= 177 fps= 21 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 187 fps= 21 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 195 fps= 19 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 212 fps= 20 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 220 fps= 20 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 228 fps= 19 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 236 fps= 19 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 241 fps= 19 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 254 fps= 19 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
I'm aware the stream URL ends in .264, but I've verified with VLC that it's in fact a hevc stream.
Also, may be unrelated but why does it spawn several ffmpeg instances?
Hi @TippyLion28 i suspect the two issues are related. Normally only one ffmpeg instance would be spawned per stream.
I can't easily test this, but if I get my hands on a H265 capable camera I'll investigate - possibly next week...
Obtive o mesmo problema