Opened 5 years ago

Closed 4 years ago

#3781 closed defect (invalid)

Malfunction of the program with rtsp protocol.

Reported by: iRidium_mobile Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: rtsp
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug: When using ffmpeg versions 2.1.1 and 2.2 I came across malfunction of the program with rtsp protocol. When receiving rtsp stream without indicating low-level transport, the program can’t get the stream, as when switching from UDP to TCP, the device to which ffmpeg is attached, doesn’t get TEARDOWN command and hangs up. (as the old session is not closed). I commented a line if (rt->server_type == RTSP_SERVER_REAL) in rtsp_read_packet method of rtspdec.c file and the program began to get a stream of data.
How to reproduce:

% ffmpeg -i input ... output
ffmpeg version
built on ...

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

Change History (7)

comment:1 Changed 5 years ago by cehoyos

  • Component changed from ffmpeg to undetermined

Please test current FFmpeg git head and provide your failing command line together with the complete, uncut console output to make this a valid ticket.

comment:2 Changed 5 years ago by cehoyos

  • Component changed from undetermined to avformat
  • Keywords rtsp added
  • Version changed from unspecified to git-master

Please tell us which server needs the TEARDOWN command so a proper patch can be written.

comment:3 follow-up: Changed 5 years ago by iRidium_mobile

I found a problem when working in ffmpeg with RSTP protocol. When working with several problem cameras I found out that a mistake appears when changing low-level transport in rtsp protocol. I compared the work of ffmpeg and vlc and saw that the programs behave differently when working with the same camera. Here is the sequence of commands (C=Client, S=Server)
Case 1.
ffmpeg
C:OPTIONS
S:OK
C: DESCRIBE
S:OK
C:SETUP (transport = UDP)
S: OK
C: PLAY
S:OK
... timeout 10 sec
C: PAUSE
S: OK
C: SETUP (transport=TCP)
S: OK
vlc
C:OPTIONS
S:OK
C: DESCRIBE
S:OK
C:SETUP (transport = UDP)
S: OK
C: PLAY
S:OK
... timeout 10 sec
C: TEARDOWN
S: OK
C:OPTIONS
S:OK
C: DESCRIBE
S:OK
C:SETUP (transport = TCP)
S: OK
C: PLAY
S:OK
S: stream (the stream goes)
In this case if we comment in rtsp_read_packet method in rtspdec.c file
if (rt->server_type == RTSP_SERVER_REAL)
In this case ffmpeg starts to work and the stream comes.
Case 2.
In the second case the camera has 2 streams and a mistake appears when doing the SETUP command with TCP transport. The SETUP command, when initializing with TCP, is sent only for the first stream, it does not reach the second one.
ffmpeg
C:OPTIONS
S:OK
C: DESCRIBE
S:OK
C:SETUP (transport = UDP for stream 1)
S: OK
C:SETUP (transport = UDP for stream 2)
S: OK
C: PLAY
S:OK
... timeout 10 sec
C: PAUSE
S: OK
C: SETUP (transport=TCP for stream 1)
S: OK
Nothing happens further.
vlc
C:OPTIONS
S:OK
C: DESCRIBE
S:OK
C:SETUP (transport = UDP for stream 1)
S: OK
C:SETUP (transport = UDP for stream 2)
S: OK
C: PLAY
S:OK
... timeout 10 sec
C: TEARDOWN
S: OK
C:OPTIONS
S:OK
C: DESCRIBE
S:OK
C:SETUP (transport = TCP for stream 1)
S: OK
C:SETUP (transport = TCP for stream 2)
S: OK
C: PLAY
S:OK
S: stream (the stream goes)

comment:4 in reply to: ↑ 3 Changed 5 years ago by cehoyos

Replying to iRidium_mobile:

I found a problem when working in ffmpeg with RSTP protocol. When working with several problem cameras I found out that a mistake appears when changing low-level transport in rtsp protocol. I compared the work of ffmpeg and vlc and saw that the programs behave differently when working with the same camera. Here is the sequence of commands (C=Client, S=Server)
Case 1.
ffmpeg
C:OPTIONS
S:OK
C: DESCRIBE
S:OK
C:SETUP (transport = UDP)
S: OK
C: PLAY
S:OK
... timeout 10 sec
C: PAUSE
S: OK
C: SETUP (transport=TCP)
S: OK
vlc
C:OPTIONS
S:OK
C: DESCRIBE
S:OK
C:SETUP (transport = UDP)
S: OK
C: PLAY
S:OK
... timeout 10 sec
C: TEARDOWN
S: OK
C:OPTIONS
S:OK
C: DESCRIBE
S:OK
C:SETUP (transport = TCP)
S: OK
C: PLAY
S:OK
S: stream (the stream goes)
In this case if we comment in rtsp_read_packet method in rtspdec.c file
if (rt->server_type == RTSP_SERVER_REAL)
In this case ffmpeg starts to work and the stream comes.

Please tell us how we can identify the cameras that need TEARDOWN, I am sure you saw the comment in the code that explains why the check cannot be removed unconditionally.

Case 2.
In the second case the camera has 2 streams and a mistake appears when doing the SETUP command with TCP transport. The SETUP command, when initializing with TCP, is sent only for the first stream, it does not reach the second one.

Do I understand correctly that this is completely unrelated to the TEARDOWN issue? If yes, please open a new ticket: Provide the ffmpeg command line that you tested together with the complete, uncut console output and explain what goes wrong.

comment:5 Changed 5 years ago by iRidium_mobile

As for Case 1. The point is that cameras do nor have unique prjperties, that define the necessity to make TEARDOWN. Testing in vlc showed that teardown is always done, if before it a session with low level transport was opened.

comment:6 Changed 5 years ago by cehoyos

As said, please add the command line that allows to reproduce the TEARDOWN issue together with the complete, uncut console output to make this a valid ticket.

comment:7 Changed 4 years ago by compn

  • Resolution set to invalid
  • Status changed from new to closed

no sample rtsp url , cant fix!
reopen this if you have a url that we can test with.

Note: See TracTickets for help on using tickets.