From: "Rémi Denis-Courmont" <remi@remlab.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] sending RTSP keep alive even when paused
Date: Mon, 28 Aug 2023 11:50:03 +0300
Message-ID: <C221D4B4-CC09-4253-85F7-E76349AB42A0@remlab.net> (raw)
In-Reply-To: <CAMwHP3XTf=jtTXB5Nc7rreYD+Dn7YBQr5h-pNn_hnHWo-mui8A@mail.gmail.com>
No
Le 27 août 2023 17:43:13 GMT+03:00, Tmc Tmc <tmcjj2001@gmail.com> a écrit :
>Hi All,
>I found a bug in ffmpeg's RTSP implementation.
>
>The workflow is as follows:
>
>1. Have a RTSP server that supports Pause.
>2. Have ffmpeg play a video from that server (rtsp://<ipaddr>:...).
>3. Pause the video in ffmpeg.
>4. ffmpeg does NOT properly send the keep alive when Paused
>(either "GET_PARAMETER" or "OPTIONS"). This is the bug.
Neither of these are standard means of keeping alive according to the (vague) RTSP 1.0 specification. In fact, sending GET_PARAMETER is non-standard, and known to break some servers (the request is standard but there are no standard parameters with which to use it).
OPTIONS should really not keep the session alive at all.
Unfortunately this is the sad situation of RTSP 1.0. You need vendor-specific hacks.
>5. Since the RTSP server expects the keep alive, after the specified
>timeout (usually 60s) it closes the connection.
>
>The bug is in libavformat/rtspdec.c, rtsp_read_packet method.
>
>This method first does ff_rtsp_fetch_packet, which fails when the server is
>Paused, causing it to never send the "GET_PARAMETER" or "OPTIONS" which is
>placed after this call.
>
>The fix is to simply move that block of code before ff_rtsp_fetch_packet.
>That is, move the entire if block:
>if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN)) { ... }
>just before the call to:
>ret = ff_rtsp_fetch_packet(s, pkt);
>
>I have tested this and it seems to work well for our cases.
>
>Your thoughts and comments on this are welcome.
>
>Thanks.
>_______________________________________________
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>To unsubscribe, visit link above, or email
>ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2023-08-28 8:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-27 14:43 Tmc Tmc
2023-08-28 8:50 ` Rémi Denis-Courmont [this message]
2023-08-31 11:58 Tmc Tmc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C221D4B4-CC09-4253-85F7-E76349AB42A0@remlab.net \
--to=remi@remlab.net \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git