Opened 7 months ago

Closed 2 months ago

#7810 closed defect (wontfix)

ffmpeg will automatically pause (Konx KW01 gen2)

Reported by: branqueira Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords: rtsp
Cc: junli1026@gmail.com Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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"

Attachments (3)

trace.log (46.6 KB) - added by branqueira 7 months ago.
trace.2.log (48.0 KB) - added by branqueira 7 months ago.
trace3.log (25.7 KB) - added by branqueira 6 months ago.
with rtsp_transport tcp

Download all attachments as: .zip

Change History (10)

Changed 7 months ago by branqueira

comment:1 Changed 7 months ago by 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

comment:2 Changed 7 months ago by cehoyos

  • Component changed from ffmpeg to undetermined
  • Keywords rtsp added
  • Version changed from 4.1 to unspecified

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

comment:3 follow-up: Changed 7 months ago by 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

Changed 7 months ago by branqueira

comment:4 in reply to: ↑ 3 Changed 6 months ago by Jun

  • Cc junli1026@gmail.com added

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.

Changed 6 months ago by branqueira

with rtsp_transport tcp

comment:5 Changed 6 months ago by 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

comment:6 Changed 6 months ago by 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.

rtsp.c

        /* 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 :(

Last edited 6 months ago by branqueira (previous) (diff)

comment:7 Changed 2 months ago by branqueira

  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.