Fail to get image dimension when RTSP falling back from UDP to TCP

[julien23]

Summary of the bug:
When I try to record video from a RTSP/H.265 camera that does only RTSP over TCP, it fails getting dimensions although it works fine if I force RTSP/TCP in the command line (-rtsp_transport tcp).

How to reproduce:

% ./ffmpeg/ffmpeg -analyzeduration 10000000 -probesize 10000000 -i rtsp://admin:admin@192.168.51.175:80/0 -c copy -map 0:v -f segment -segment_time 600 "%03d.mp4"
ffmpeg version N-91282-gc5e6c0b5f6 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
  configuration: 
  libavutil      56. 18.102 / 56. 18.102
  libavcodec     58. 20.101 / 58. 20.101
  libavformat    58. 17.100 / 58. 17.100
  libavdevice    58.  4.101 / 58.  4.101
  libavfilter     7. 25.100 /  7. 25.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
[rtsp @ 0x56423d973680] UDP timeout, retrying with TCP
[rtsp @ 0x56423d973680] method PAUSE failed: 455 Method Not Valid In This State
[hevc @ 0x56423d976940] missing picture in access unit
[rtsp @ 0x56423d973680] Could not find codec parameters for stream 0 (Video: hevc, none): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Guessed Channel Layout for Input Stream #0.1 : mono
Input #0, rtsp, from 'rtsp://admin:admin@192.168.51.175:80/0':
  Metadata:
    title           : h264.mp4
  Duration: N/A, bitrate: 64 kb/s
    Stream #0:0: Video: hevc, none, 90k tbr, 90k tbn, 90k tbc
    Stream #0:1: Audio: pcm_mulaw, 8000 Hz, mono, s16, 64 kb/s
[segment @ 0x56423d9bdbc0] dimensions not set
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
    Last message repeated 1 times

% ./ffmpeg/ffmpeg -rtsp_transport tcp -i rtsp://admin:admin@192.168.51.175:80/0 -c copy -map 0:v -f segment -segment_time 600 "%03d.mp4"
ffmpeg version N-91282-gc5e6c0b5f6 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
  configuration: 
  libavutil      56. 18.102 / 56. 18.102
  libavcodec     58. 20.101 / 58. 20.101
  libavformat    58. 17.100 / 58. 17.100
  libavdevice    58.  4.101 / 58.  4.101
  libavfilter     7. 25.100 /  7. 25.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
Guessed Channel Layout for Input Stream #0.1 : mono
Input #0, rtsp, from 'rtsp://admin:admin@192.168.51.175:80/0':
  Metadata:
    title           : h264.mp4
  Duration: N/A, start: 0.017000, bitrate: N/A
    Stream #0:0: Video: hevc (Main), yuv420p(tv), 1920x1080, 90k tbr, 90k tbn, 90k tbc
    Stream #0:1: Audio: pcm_mulaw, 8000 Hz, mono, s16, 64 kb/s
[segment @ 0x55aa5202d540] Opening '000.mp4' for writing
Output #0, segment, to '%03d.mp4':
  Metadata:
    title           : h264.mp4
    encoder         : Lavf58.17.100
    Stream #0:0: Video: hevc (Main), yuv420p(tv), 1920x1080, q=2-31, 90k tbr, 90k tbn, 90k tbc
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
[segment @ 0x55aa5202d540] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[segment @ 0x55aa5202d540] Non-monotonous DTS in output stream 0:0; previous: 0, current: 0; changing to 1. This may result in incorrect timestamps in the output file.
frame=  288 fps= 65 q=-1.0 Lsize=N/A time=00:00:09.53 bitrate=N/A speed=2.14x    
video:2519kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Exiting normally, received signal 2.

[Carl Eugen Hoyos]

Why do you believe there is an issue that can be fixed in FFmpeg? Changing the protocol automatically works for many rtsp sources, do you know that it is supposed to work for your camera?

[julien23]

I would answer why do you believe it is not an issue in FFmpeg ?

It works when I ask FFmpeg to use RTSP/TCP in the first place but not when FFmpeg tries first doing RTSP/UDP and then fallback to RTSP/TCP. IMO, the issue seems to come from a bad behavior when rtsp module is switching from UDP to TCP.

[rtsp @ 0x56423d973680] UDP timeout, retrying with TCP

[Carl Eugen Hoyos]

Replying to julien23:

I would answer why do you believe it is not an issue in FFmpeg ?

I neither wrote nor meant this.

[Jun Li]

Replying to julien23:

The reason is there in your log: 455 repsonse

[rtsp @ 0x56423d973680] UDP timeout, retrying with TCP
[rtsp @ 0x56423d973680] method PAUSE failed: 455 Method Not Valid In This State

When UDP timeout and ffmpeg sends PAUSE request to the camera, the camera gives 455 back.
I guess the camera simply does not allow that ? Do you have more detailed logs?