ffmpeg will automatically pause (Konx KW01 gen2)

[branqueira]

ffmpeg connects rtsp to the konx gen2 camera via a router, it automatically pause.
if you access directly with the internal ip(192.168.1.100), there is no problem.

This problem only occurs with ffmpeg because there is no problem with vlc.

The version used is 4.1.1 and the problem occurs on windows 10 and also with a raspberrypi.

if start ffmpeg with trace log level, ffmpeg is freeze and the last trace is :

[rtsp @ 0000029a95d39580] Sending:
PAUSE rtsp://5.51.X.Y:554/onvif1 RTSP/1.0

CSeq: 7

User-Agent: Lavf58.20.100

Session: 13fe36af

Authorization: Digest username="admin", realm="HIipCamera", nonce="6f31e2303b0c36b83e421e7aa5e71b5c", uri="rtsp://5.51.X.Y:554/onvif1", response="9892f43f95c9cd8820fc8e90f711d731"

[branqueira]

the command line that does not work :
ffmpeg -i rtsp://admin:password@5.51.X.Y:554/onvif1 -loglevel trace -f mpegts -codec:v mpeg1video -an -b:a 0 -q 1 ​http://127.0.0.1:1234/live.ts

with local ip is works :
ffmpeg -i rtsp://admin:password@192.168.1.100:554/onvif1 -loglevel trace -f mpegts -codec:v mpeg1video -an -b:a 0 -q 1 ​http://127.0.0.1:1234/live.ts

[Carl Eugen Hoyos]

Please test current FFmpeg git head to make this a valid ticket, feel free to test this patch: ​http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241428.html

[branqueira]

I checkout the code and build the head branch with the patch provided.
I always get the same error

Moi@CARL MINGW64 /d/ffmpeg/build/ffmpeg
$ git remote show origin
* distante origin
  URL de rapatriement : git://source.ffmpeg.org/ffmpeg
  URL push : git://source.ffmpeg.org/ffmpeg
  Branche HEAD : master
  Branches distantes :
    master       suivi

	
D:\ffmpeg\build\ffmpeg>git status
HEAD detached at origin/master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   libavformat/http.c
        modified:   libavformat/icecast.c
        modified:   libavformat/rtsp.c

[Jun Li]

Replying to branqueira:

I checkout the code and build the head branch with the patch provided.
I always get the same error

Moi@CARL MINGW64 /d/ffmpeg/build/ffmpeg
$ git remote show origin
* distante origin
  URL de rapatriement : git://source.ffmpeg.org/ffmpeg
  URL push : git://source.ffmpeg.org/ffmpeg
  Branche HEAD : master
  Branches distantes :
    master       suivi

	
D:\ffmpeg\build\ffmpeg>git status
HEAD detached at origin/master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   libavformat/http.c
        modified:   libavformat/icecast.c
        modified:   libavformat/rtsp.c

Trace2.log says UDP timeout and ffmpeg start retry with tcp, and the last request is TEARDOWN in the log.
But the code tells me, if the TEARDOWN succeeds, a new SETUP will be sent out, which I didnot see in the log.

1. So do you mind sharing more log here ?
2. Could you have a try with "-rstp_transport tcp"? it will run in RTP/RTSP interleaving mode, all traffic is tunneled in TCP, it may work in your case.

[branqueira]

with rtsp_transport tcp

[branqueira]

with the rtsp_transport tcp option, there is no longer the same behavior.
I have this message:

[rtsp @ 0000000000f59580] Nonmatching transport in server reply
rtsp://admin:password@5.51.X.Y:554/onvif1: Invalid data found when processing input

after ffmpeg is stopped

[branqueira]

I found the cause of the problem, the answer is in the log file "trace3.log"

We want to use tcp instead of udp and ffmpeg responds : "Nonmatching transport in server reply".

This means that the server wants to use udp while the client (rtsp_transport tcp) only uses tcp.

        /* Fail if the server responded with another lower transport mode
         * than what we requested. */
        if (reply->transports[0].lower_transport != lower_transport) {
            av_log(s, AV_LOG_ERROR, "Nonmatching transport in server reply\n");
            err = AVERROR_INVALIDDATA;
            goto fail;
        }

The ffmpeg client sends this SETUP request:

SETUP rtsp://5.51.X.Y:554/onvif1/track1 RTSP/1.0

Transport: RTP/AVP/TCP;unicast;interleaved=0-1
CSeq: 4
User-Agent: Lavf58.26.101

The client requests to use tcp (RTP / AVP / TCP)

The server responds with:

Transport: RTP/AVP;unicast;destination=82.255.9.82;source=192.168.1.100;interleaved=0-1

note the server didn't add TCP (RTP/AVP)

if we read the specification ​https://www.ietf.org/rfc/rfc2326.txt page 58, we see that the default transport protocol is UDP when nothing is specified.

this value is retrieved in the "rtsp_parse_transport" method

if (!av_strcasecmp (transport_protocol, "rtp")) {
            get_word_sep(profile, sizeof(profile), "/;,", &p);
			printf("********** profile : %s\n", profile);
            lower_transport[0] = '\0';
            /* rtp/avp/<protocol> */
            if (*p == '/') {
				printf("********** protocol");
                get_word_sep(lower_transport, sizeof(lower_transport),
                             ";,", &p);
            }
            th->transport = RTSP_TRANSPORT_RTP;

we try to recover the transport protocol but since * p is not equal to "/" the value of lower_transport is empty.

then we define the value of the protocol but since lower_transport is empty:

if (!av_strcasecmp(lower_transport, "TCP"))
               th->lower_transport = RTSP_LOWER_TRANSPORT_TCP;
           else
               th->lower_transport = RTSP_LOWER_TRANSPORT_UDP;

UDP is chosen

By doing a hack to test my reasoning by modifying the code slightly:

   if (!av_strcasecmp(lower_transport, "TCP"))
               th->lower_transport = RTSP_LOWER_TRANSPORT_TCP;
           else
               th->lower_transport = RTSP_LOWER_TRANSPORT_TCP; //beurg dirty hack, it's just for test
			

Now it's work

In conclusion, ffmpeg respects the specification, it is not the case of my camera :(