[FFmpeg-devel] sending RTSP keep alive even when paused

[Tmc Tmc <tmcjj2001@gmail.com>]

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".