[FFmpeg-trac] #3781(avformat:new): Malfunction of the program with rtsp protocol.

[FFmpeg]

#3781: Malfunction of the program with rtsp protocol.
-------------------------------------+-------------------------------------
             Reporter:               |                    Owner:
  iRidium_mobile                     |                   Status:  new
                 Type:  defect       |                Component:  avformat
             Priority:  normal       |               Resolution:
              Version:  git-master   |               Blocked By:
             Keywords:  rtsp         |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by cehoyos):

 Replying to [comment:3 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.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/3781#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker