* [FFmpeg-devel] sending RTSP keep alive even when paused
@ 2023-08-31 11:58 Tmc Tmc
0 siblings, 0 replies; 3+ messages in thread
From: Tmc Tmc @ 2023-08-31 11:58 UTC (permalink / raw)
To: ffmpeg-devel
Thank you for the response.
With all due respect, my email is NOT about the RTSP standard, or the
vendor specifics.
FFmpeg code already does the necessary stuff by sending either
GET_PARAMETER or OPTIONS.
I was merely talking about moving that a little above, so that it
works the same way in even more cases - i.e., even when the video is
paused.
Hope that clarifies.
Thanks.
Le 27 août 2023 17:43:13 GMT+03:00, Tmc Tmc <tmcjj2001 at gmail.com
<https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>> 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 at ffmpeg.org <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
*>*https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
<https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
*>>*To unsubscribe, visit link above, or email
*>*ffmpeg-devel-request at ffmpeg.org
<https://ffmpeg.org/mailman/listinfo/ffmpeg-devel> 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".
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [FFmpeg-devel] sending RTSP keep alive even when paused
2023-08-27 14:43 Tmc Tmc
@ 2023-08-28 8:50 ` Rémi Denis-Courmont
0 siblings, 0 replies; 3+ messages in thread
From: Rémi Denis-Courmont @ 2023-08-28 8:50 UTC (permalink / raw)
To: FFmpeg development discussions and patches
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".
^ permalink raw reply [flat|nested] 3+ messages in thread
* [FFmpeg-devel] sending RTSP keep alive even when paused
@ 2023-08-27 14:43 Tmc Tmc
2023-08-28 8:50 ` Rémi Denis-Courmont
0 siblings, 1 reply; 3+ messages in thread
From: Tmc Tmc @ 2023-08-27 14:43 UTC (permalink / raw)
To: ffmpeg-devel
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.
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".
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-08-31 11:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-31 11:58 [FFmpeg-devel] sending RTSP keep alive even when paused Tmc Tmc
-- strict thread matches above, loose matches on Subject: below --
2023-08-27 14:43 Tmc Tmc
2023-08-28 8:50 ` Rémi Denis-Courmont
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