- Sep 01, 2016
-
-
Sebastian Dröge authored
-
- Aug 30, 2016
-
-
- Aug 26, 2016
-
-
Josep Torra authored
Fixes "clang: error: argument unused during compilation: '-pthread'"
-
- Aug 02, 2016
-
-
With additional fixes by Kseniya Vasilchuk <vasilchukkseniia@gmail.com> and myself to make the media refcounting a bit easier to follow. https://bugzilla.gnome.org/show_bug.cgi?id=755632
-
-
- Jul 11, 2016
-
-
Stefan Sauer authored
From f363b32 to f49c55e
-
- Jul 06, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Jun 24, 2016
- Jun 21, 2016
-
-
Nicolas Dufresne authored
From ac2f647 to f363b32
-
- Jun 14, 2016
-
-
We add different crypto sessions in MIKEY, one for each sender SSRC. Currently, all of them will have the same security policy, 0. The rollover counters are obtained from the srtpenc element using the "stats" property. https://bugzilla.gnome.org/show_bug.cgi?id=730539
-
- Jun 07, 2016
-
-
Tim-Philipp Müller authored
-
- May 25, 2016
-
-
Tim-Philipp Müller authored
It's what introspection.mak does as well. Should fix spurious build failures on gnome-continuous (caused by g-ir-scanner getting compiler details via python which is broken in some environments so passing the compiler details bypasses that).
-
- May 19, 2016
-
-
This works with rtspsrc and live555, but fails with e.g. ffmpeg. https://bugzilla.gnome.org/show_bug.cgi?id=766619
-
- Apr 29, 2016
-
-
Edward Hervey authored
And just make sure we always have 0/0 if we have an error CID #1352031
-
- Unicast udpsrcs are now managed in a hash table. This allows for proper cleanup in with shared streams and fixes a memory leak. - Unicast udpsrcs are now properly cleaned up when shared connections exit. See the update_transport() function. - Create unit test for shared media. https://bugzilla.gnome.org/show_bug.cgi?id=764744
-
Sebastian Dröge authored
For IPv6 addresses, binding to a multicast group does not work on Linux either. Always bind to ANY and then later join the multicast group. https://bugzilla.gnome.org/show_bug.cgi?id=764679
-
- Apr 14, 2016
-
-
Julien Isorce authored
From 6f2d209 to ac2f647
-
- Apr 06, 2016
-
-
Clarified why it is necessary to add source information to GstRTSPThreadImpl. See the reported bug in GLib: https://bugzilla.gnome.org/show_bug.cgi?id=720186 for more information. https://bugzilla.gnome.org/show_bug.cgi?id=761702
-
- Apr 04, 2016
-
-
Sebastian Dröge authored
The internal .la should come first and is part of LDADD, as is GST_CFLAGS/LIBS.
-
Sebastian Dröge authored
-
- Apr 03, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
For NTP and PTP clocks we signal the actual clock that is used and signal the direct media clock offset. For all other clocks we at least signal that it's the local sender clock. This allows receivers to know which clock was used to generate the media and its RTP timestamps. Receivers can then implement network synchronization, either absolute or at least relative by getting the sender clock rate directly via NTP/PTP instead of estimating it from RTP timestamps and packet receive times. https://bugzilla.gnome.org/show_bug.cgi?id=760005
-
- Mar 25, 2016
-
-
- Mar 24, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
- Mar 16, 2016
-
-
Sebastian Dröge authored
This would get us NO_PREROLL in the bin again and break seeking. Thanks to Carlos Rafael Giani for helping to debug this! https://bugzilla.gnome.org/show_bug.cgi?id=740509
-
- Mar 15, 2016
-
-
Sebastian Dröge authored
-
- Mar 10, 2016
-
-
Sebastian Dröge authored
rtsp-stream: Ensure that the pipeline is live and later-added udpsrcs are syncing the state with the parent bin Without this, RECORD pipelines are broken because a) we wait for ASYNC_DONE which never happens anymore because udpsrc would be added later. Previously it was there earlier and due to NO_PREROLL caused the pipeline to preroll immediately b) the udpsrc for the pipeline is added later and never set to PLAYING state, as the corresponding code previously was only for PLAY pipelines. https://bugzilla.gnome.org/show_bug.cgi?id=763281
-
Jan Schmidt authored
gst_rtsp_stream_set_client_side -> gst_rtsp_stream_is_client_side
-
- Mar 05, 2016
-
-
Sebastian Dröge authored
On Windows this is a receiver-side setting, on Linux a sender-side setting. As we provide a socket ourselves to udpsrc, udpsrc is never setting the multicast loopback setting on the socket... while udpsink does which unfortunately has no effect here on Windows but on Linux. https://bugzilla.gnome.org/show_bug.cgi?id=757488
-
Test a case when the address pool only contains multicast addresses and the client is requesting unicast udp. Added tests for multicast ports allocation. https://bugzilla.gnome.org/show_bug.cgi?id=757488
-
- Mar 04, 2016
-
-
Sebastian Dröge authored
On Linux it is still needed to bind to the multicast address to filter out random other packets, while on Windows binding to multicast addresses just fails.
-
- Mar 03, 2016
-
-
Sebastian Dröge authored
Otherwise we fail to allocate UDP ports if the pool only contains multicast addresses, which is something that used to work before. For unicast addresses if the pool contains none, we just allocate them as if there is no pool at all. https://bugzilla.gnome.org/show_bug.cgi?id=757488
-
- Mar 02, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
This works on Linux but fails completely on Windows. You're supposed to bind to ANY and then join the multicast group. https://bugzilla.gnome.org/show_bug.cgi?id=757488
-
- Mar 01, 2016
-
-
Sebastian Dröge authored
-
- Feb 26, 2016
-
-
Sebastian Dröge authored
From b64f03f to 6f2d209
-