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 663298 - RTSPServer broken on windows
RTSPServer broken on windows
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
0.10.x
Other Windows
: Normal critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-11-03 09:39 UTC by matzepopatze
Modified: 2015-02-24 12:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (2.69 KB, patch)
2011-11-03 09:39 UTC, matzepopatze
none Details | Review

Description matzepopatze 2011-11-03 09:39:16 UTC
Created attachment 200575 [details] [review]
Patch

The current RTSP Server does not work on windows. On bug lies in the RTSP library used by the server. Basically no client is able to connect to the server (no response). The problem is in the library gst-plugins-base/gst-libs/gst/rtsp.
The io watch always returns nothing.

I am not sure whether this is the best solution- but it works.
Comment 1 Wim Taymans 2011-11-03 11:16:20 UTC
Can you explain what this patch does?
Comment 2 Levente Farkas 2011-11-03 11:39:23 UTC
is there any reason you change the component? the patch is for gst-plugins-base files and probably effects other part of gstreamer compiled for windows (eg rtspsrc etc...) even if the reporter find it during try to use gst-rtsp-server on windows.
Comment 3 matzepopatze 2011-11-04 09:19:54 UTC
Yes, of course i can:

The I/O watches doesn't seem to work on windows correctly. This might be related to the bug reported here (glib) - but it's still a different issue:
https://bugzilla.gnome.org/show_bug.cgi?id=338943

The main problem is that on windows sockets are handled totally different than I/O resources/files. GLib might have a problem there.

The read/write events that should be triggered are never send. Therefore we used GstPoll to monitor the sockets. In detail:

- we monitor the resources for read/write access
- we poll the sockets explicitly

The underlying problem might be: The initial server socket created works fine (and watches dispatch). On client-connection the server will create a new client-socket. That second socket doesn't trigger read/write events. In the end this seems to be a GLib problem.
Comment 4 Wim Taymans 2012-12-12 15:25:44 UTC
Any new status on this?
Comment 5 Tobias Mueller 2013-04-08 15:04:09 UTC
Reopening as I can't see any open non developer question.
Comment 6 Tim-Philipp Müller 2013-04-08 15:15:34 UTC
Comment #3 stated that it seems like a GLib problem.

More importantly, is this still an issue with GStreamer 1.x ? The network stack is now based on glib/gio.
Comment 7 Tim-Philipp Müller 2015-02-24 12:08:43 UTC
Closing, as the network stack used is completely different now and chances are good the issue got fixed as part of that.