[Bug 719506] gst-rtsp-server leaks file descriptors and sometimes service is unavailable

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=719506
  GStreamer | gst-rtsp-server | git

Wim Taymans <wim.taymans> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wim.taymans at gmail.com

--- Comment #1 from Wim Taymans <wim.taymans at gmail.com> 2013-11-29 16:00:34 UTC ---
(In reply to comment #0)
> 1. Number of file descriptors open by server process increases until service is
> denied because of allowed FD limit reached. These FDs are not sockets, because
> netstat -napt does not show excessive entries, but /proc/$PID/fdinfo shows that
> there is a lot of them. When all clients disconnect (which should lead to
> destruction of GstRTSPMedia instance) excessive FDs are not freed, too.

Still investigating this. It seems to all free things correctly here from a
quick check with valgrind and 2 ffmpeg sources.

Maybe this fix helps:

commit 3b4894c4f1ea28cc317f0c53b110cf678d27bf10
Author: Ognyan Tonchev <ognyan at axis.com>
Date:   Fri Nov 29 15:50:23 2013 +0100

    media: also do state change in suspended state


> 
> 2. Sometimes clients fail getting "503 Service Unavailable" reply for DESCRIBE
> request.
> I've noticed such server log messages which may be related to the issue (they
> go together):
> ERROR rtspclient rtsp-client.c:599:find_media: client 0x7f3224002960: can't
> prepare media
> ERROR rtspclient rtsp-client.c:1819:handle_describe_request: client
> 0x7f3224002960: no media
> FIXME rtspmedia rtsp-media.c:2392:gst_rtsp_media_suspend: suspend for dynamic
> pipelines needs fixing
> WARN basesrc gstbasesrc.c:1586:gst_base_src_perform_seek:<videotestsrc13>
> duplicate event found 5210

The warning is unrelated and the fix for the 503 is here:

commit 53859ac34be48bc3b8210e4598e885ea04e3efa8
Author: Wim Taymans <wtaymans at redhat.com>
Date:   Fri Nov 29 10:53:08 2013 +0100

    media: also handle prepare and range in suspended state

    When we are suspended, we are already prepared.
    We can get the range in the suspended state.

> 
> 3. There may be some issue with timestamps: ffmpeg laments "Application
> provided invalid, non monotonically increasing dts to muxer in stream 0: 87001
> >= 36000". Such messages never appear when there is single client. And when
> second client connects, a lot of such errors are produced to the first one
> infinitely.

This looks like a bug in ffmpeg. I don't see timestamps go backwards.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.