Inside this last one I found rtsp_parse_transport and the following code: if (!av_strcasecmp(lower_transport, "TCP")) I analysed the code on and ffmpeg/libavformat/rtsp.c and found the intuitive following calling sequence: ff_rtsp_connect, ff_rtsp_make_setup_request, ff_rtsp_send_cmd, ff_rtsp_read_reply and ff_rtsp_parse_line. Like: Transport: RTP/AVP/('TCP' missing here). But we can see by the camera answer that in the 'Transport:' line it doesn't include 'TCP' after 'RTP/AVP' as it was requested. Response by camera: Transport: RTP/AVP unicast destination=192.168.0.100 source=192.168.0.103 interleaved=0-1Ĭomparing the messages it's clear the camera can connect using RTSP/AVP/TCP interleaved TCP. Transport: RTP/AVP unicast destination=192.168.0.100 source=192.168.0.103 interleaved=2-3įor FFMPEG you have to use -v 9 and -loglevel 99 params to see RTSP messages. ![]() Response by camera: Received a complete SETUP response: Transport: RTP/AVP/TCP unicast interleaved=2-3 OpenRTSP sends the commands OPTIONS, DESCRIBE and then SETUP. openRTSP by default already outputs a lot of verbose diagnostic. ![]() FFMPEG not very tolerant in RTSP setupĪfter struggling I started comparing the RTSP/ SETUP messages between openRTSP and ffmpeg. ![]() Unless your IP cameras and controller are all designed to play nicely together, only use ONVIF for once-only discovery and settings management. This appears to be a byproduct of the low-end of the CCTV industry playing fast and loose with standards, RTSP and ONVIF being the two most frequently abused.įortunately, you can usually work around these problems. ![]() Dealing with their RTSP streams requires a dose of fault-tolerance. IP cameras are of varying quality, some behaving erratically in my experience.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |