Send_content_length=0, send_content=0x0, content_ptr=0x0, #2 ff_network_wait_fd_timeout (fd=6, libavformat/network.c:90 Should I be able to do that? Now that I can reproduce this consistently I'm able to help out in debugging this. I can see part of that in buf in frame 4 below.
The Session header used when I got the backtrace was "$$8fytI8KQRmjSJ_". I made gst-rtsp-server unconditionally _always_ choose to emit Session-headers starting with two dollar signs. I used gst-rtsp-server to reproduce this locally at my machine just now. Perhaps the problem with $ is that the session id is mixed up with the $ used to separate multiple channels multiplexed over the same RTSP TCP connection? I'm far from certain about this, but at least it is part of the parsing and uses the same character as delimiter.Ĭhristian if you can still reproduce this, please chime in here and help out in getting a better fix for this problem. Finally I did quickly look at the RTSP header parsing code in ffmpeg and I fail to find any code that actually cares about the session id's constituing characters. While I have not reproduced this myself I'm CCing christian who reported it. Instead the argument is that ffmpeg should not hang if it encounters $ or + in the header.
Therefore GStreamer recently accepted a patch to refrain from URI-escaping the session id in the RTSP session header. However whitespace is not among the allowed characters in a session id, and neither is % which would be the result of URI-escaping. Now, RFC 2326 actually does not state that characters can or should be URI-escaped in a session id, only that linear whitespace should be. GStreamer got a bug report a while back where christian mentioned that ffmpeg hangs when RTSP session ids in gst-rtsp-server contain $ or +
0 kommentar(er)
