After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 628820 - media cleanup
media cleanup
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-09-05 14:33 UTC by Nicola
Modified: 2012-02-18 20:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Logs when I unplug the network cable from the source (19.16 KB, text/plain)
2010-09-27 15:48 UTC, Nicola
Details

Description Nicola 2010-09-05 14:33:33 UTC
After building an application based on gst-rtsp-server here are the steps to reproduce the issue:

1) open a vlc client and connect to a stream generated by gst-rtsp-server
2) launch a pipeline to connect to the same stream with gst-launch
3) make the stream no more available (for example poweroff the source camera)
4) the gst-launch window remain open
5) make the stream available again
6) until the above gst-launch window is open you no other client can connect to the stream, the old pipeline remain referenced and is not cleaned up
7) if you close the gst-launch window you are able to connect to the stream again with any client

Another use case that may be collegated with the above is the following:

1) add a new stream
2) connect to the stream with a client
3) remove the stream from gst-rtsp-server
4) the connected client will continue to see the video stream even if it was removed from gst-rtsp-server

So the actual gst-rtsp-server implementation can suffer from network problems. Sometime after the network come up again after a failure you are not able to see the video
Comment 1 Wim Taymans 2010-09-23 09:56:44 UTC
I tried with v4l2src and it all worked as expected. The server sends EOS to all clients and the media is destroyed when all clients are gone. Then new clients restart the pipeline and can continue.

Maybe your problem is that the disconnected camera is not properly detected by the rtsp server pipeline somehow. To fix that, I need more info. What pipeline are you using? 

Can you make a log of the server with GST_DEBUG=*rtsp:5 when the error is happening.
Comment 2 Nicola 2010-09-27 15:24:34 UTC
the problem is that the media is not destroyed until a client try to connect to it, gst_rtsp_media_finalize is called only when all clients disconnect, so imagine this scenario:

1) the source go down
2) for some reasons some clients still try to connect to it
3) the source come up again
4) new clients are unable to connect until all the old ones disconnect

so gst-rtsp server is not reliable on network error or generic source error, all the clients should be disconnected on error and the gst_rtsp_media_finalize should be called

you can simply reproduce this behavior:

1) add a media mapping for v4l2src
2) connect to this mapping with a client (I used vlc)
3) remove the media_mapping
4) you'll continue to see the stream
5) add a new mapping with same source and name
6) you'll be unable to connect to the mapping with any client until you stop the client connected at 2)

I hope this time the explaination and the use case is clear enough,

please note that I noted this problem testing on a simple lan (gst-rtsp<-hub->source stream) and after some time I was unable to connect to the media even if the source was available

thanks
Nicola
Comment 3 Nicola 2010-09-27 15:48:49 UTC
Created attachment 171215 [details]
Logs when I unplug the network cable from the source
Comment 4 Nicola 2011-12-28 09:23:20 UTC
this report is now obsolete, the latest git doesn't show this issue