1. 13 Nov, 2018 1 commit
    • Linus Svensson's avatar
      rtpsession: Implement reset · 8fc8b7ee
      Linus Svensson authored
      Reset RTPSession when rtpsession changes state from PAUSED to READY.
      Without this change, a stored last_rtptime in RTPSource could interfere
      with RTP timestamp generation in RTCP Sender Report.
      
      Fixes #510
      8fc8b7ee
  2. 12 Jul, 2018 1 commit
  3. 23 Jun, 2018 1 commit
  4. 15 May, 2018 1 commit
  5. 19 Apr, 2017 1 commit
  6. 02 Feb, 2017 1 commit
  7. 14 Dec, 2016 1 commit
  8. 01 Nov, 2016 1 commit
  9. 23 Aug, 2016 1 commit
  10. 29 Mar, 2016 1 commit
  11. 24 Mar, 2016 1 commit
  12. 05 Nov, 2015 1 commit
  13. 11 Oct, 2015 1 commit
  14. 07 Oct, 2015 1 commit
  15. 02 Oct, 2015 1 commit
  16. 26 Sep, 2015 1 commit
  17. 25 Sep, 2015 1 commit
  18. 25 Jun, 2015 1 commit
  19. 12 Jun, 2015 1 commit
    • Sebastian Dröge's avatar
      rtpbin/session: Add new ntp-time-source property and deprecate use-pipeline-clock property · dc513eb9
      Sebastian Dröge authored
      The new property allows to select the time source that should be used for the
      NTP time in RTCP packets. By default it will continue to calculate the NTP
      timestamp (1900 epoch) based on the realtime clock. Alternatively it can use
      the UNIX timestamp (1970 epoch), the pipeline's running time or the pipeline's
      clock time. The latter is especially useful for synchronizing multiple
      receivers if all of them share the same clock.
      
      If use-pipeline-clock is set to TRUE, it will override the ntp-time-source
      setting and continue to use the running time plus 70 years. This is only kept
      for backwards compatibility.
      dc513eb9
  20. 10 Jun, 2015 1 commit
  21. 05 Jun, 2015 1 commit
  22. 02 Jun, 2015 1 commit
  23. 27 Apr, 2015 1 commit
  24. 24 Apr, 2015 1 commit
  25. 21 Mar, 2015 2 commits
    • Sebastian Dröge's avatar
      rtpsession: Fix another instance of sticky event misordering warnings · 0e3609a6
      Sebastian Dröge authored
      Make sure that the sync_src pad has caps before the segment event.
      Otherwise we might get a segment event before caps from the receive
      RTCP pad, and then later when receiving RTCP packets will set caps.
      This will results in a sticky event misordering warning
      
      This fixes warnings in the rtpaux unit test but also in the
      rtpaux and rtx examples in tests/examples/rtp
      
      https://bugzilla.gnome.org/show_bug.cgi?id=746445
      0e3609a6
    • Sebastian Dröge's avatar
      rtpsession: Also start the RTCP send thread when receiving RTP or RTCP · 17d90b45
      Sebastian Dröge authored
      Before we only started it when either:
      - there is no send RTP stream
      or
      - we received an RTP packet for sending
      
      This could mean that if the send RTP pads are connected but never receive any
      RTP data, and the same session is also used for receiving RTP/RTCP, we would
      never start the RTCP thread and would never send RTCP for the receiving part
      of the session.
      
      This can be reproduced with a pipeline like:
      
      gst-launch-1.0 rtpbin name=rtpbin \
      udpsrc port=5000 ! "application/x-rtp, media=video, clock-rate=90000, encoding-name=H264" ! rtpbin.recv_rtp_sink_0 \
      udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
      rtpbin.send_rtcp_src_0 ! fakesink name=rtcp_fakesink silent=false async=false sync=false \
      rtpbin.recv_rtp_src_0_2553225531_96 ! decodebin ! xvimagesink \
      fakesrc ! valve drop=true ! rtpbin.send_rtp_sink_0 \
      rtpbin.send_rtp_src_0 ! fakesink name=rtp_fakesink silent=false async=false sync=false -v
      
      Before this change the rtcp_fakesink would never send RTCP for the receiving
      part of the session (i.e. no receiver reports!), after the change it does.
      
      And before and after this change it would send RTCP for the receiving part of
      the session if the sender part was omitted (the last two lines).
      17d90b45
  26. 19 Feb, 2015 1 commit
  27. 09 Dec, 2014 1 commit
  28. 26 Apr, 2014 1 commit
  29. 18 Apr, 2014 1 commit
  30. 14 Feb, 2014 1 commit
  31. 03 Jan, 2014 2 commits
  32. 30 Dec, 2013 2 commits
  33. 16 Nov, 2013 1 commit
  34. 15 Nov, 2013 1 commit
  35. 11 Nov, 2013 2 commits
  36. 23 Sep, 2013 1 commit