[FFmpeg-devel] [libavformat rtsp] RTSP protocol not sending the ending TEARDOWN packet

Nicolas Adenis-Lamarre nicolas.adenis.lamarre at gmail.com
Thu Oct 15 07:54:06 CEST 2015


When a client close a rtsp connexion, it is supposed to send the TEARDOWN
packet according to
‚Äčhttps://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol to tell to the
server to stop the streaming.
ffmpeg doesn't (controlled by wireshark, works with some other soft), while
i guess it worked at a given time while the code to do it is inside ffmpeg.

In short, because my tv provider allows only 1 channel at a time, i've to
wait 30 seconds between each channel change. However, even with 2 channels
at a time, the traffic is higer for 30 secondes and there are troubles
until the end of the server streaming of the 1st channel.

Below, you'll find more detail, and a not perfect at all but working in my
case patch to show the problem more in detail.

How to reproduce:

% ffplay 'rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=201&flavour=ld'

The attached file is not really a patch while it's not the good way to fix.
However, it works in my case.

I found that ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
doesn't send the teardown packet, but the same command for DESCRIBE works,
so i tried to call this function before (i supposed that something is
closed too soon, or not flushed) :

The thing is that

rtsp::read_close function
containing ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);

is called after

is->abort_request = 1;
SDL_WaitThread(is->read_tid, NULL);

and at the end, the packet is never sent.
To quickly and badly fix, i've added a preclose function called before the
sdl_waitthread.

I'have troubleshooted this bug for 1 week, and only yesterday i finally
found it was related to ffmpeg, so i'm new to the ffmpeg code, so for the
moment, i don't the architecture and the best place to put the TEARDOWN
packet. (at the end of the thread ? or at the same place but fixing
something else). You guess i didn't found immediatly it was a missing
teardown packet in the rtsp protocol (i'm new to that protocol too...).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: teardown.patch
Type: text/x-patch
Size: 3849 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151015/0904b33c/attachment.bin>


More information about the ffmpeg-devel mailing list