1. 05 Jun, 2015 2 commits
  2. 02 Jun, 2015 5 commits
  3. 21 May, 2015 2 commits
  4. 07 May, 2015 1 commit
  5. 06 May, 2015 1 commit
  6. 04 May, 2015 2 commits
  7. 27 Apr, 2015 2 commits
  8. 24 Apr, 2015 1 commit
  9. 16 Apr, 2015 1 commit
  10. 14 Apr, 2015 2 commits
  11. 10 Mar, 2015 1 commit
  12. 04 Mar, 2015 5 commits
  13. 11 Feb, 2015 1 commit
    • Sebastian Dröge's avatar
      rtpsession: Handle first RTCP packet and early feedback correctly · b79eff7f
      Sebastian Dröge authored
      According to RFC 4585 section 3.5.3 step 1 we are not allowed to send
      an early RTCP packet for the very first one. It must be a regular one.
      
      Also make sure to not use last_rtcp_send_time in any calculations until
      we actually sent an RTCP packet already. In specific this means that we
      must not use it for forward reconsideration of the current RTCP send time.
      Instead we don't do any forward reconsideration for the first RTCP packet.
      b79eff7f
  14. 30 Jan, 2015 2 commits
  15. 26 Jan, 2015 3 commits
    • Sebastian Dröge's avatar
      rtpsession: Deprecate rtcp-immediate-feedback-threshold property · e4ed8520
      Sebastian Dröge authored
      It had no effect since quite some time and also is not needed in general,
      especially not to switch between immediate feedback mode and early feedback
      mode. The latest understanding of the RFC is that from the endpoint point of
      view, both modes are exactly the same. RTCP is only allowed to use the
      bandwidth as given by the RFC constraints, as such it is only ever possible
      to schedule a RTCP packet early but it's against the RFC to schedule more RTCP
      packets.
      
      The difference between immediate feedback mode and early feedback mode is that
      the former guarantees that an RTCP packet can be sent for every event
      "immediately", which means that the bandwidth calculations from the RFC have
      resulted in an RTCP scheduling interval that is small enough. Early feedback
      mode on the other hand means that we can schedule some packets early to make
      that happen, but it's not guaranteed at all that it's possible to schedule
      an RTCP packet per event (i.e. they need to be accumulated or dropped).
      e4ed8520
    • Sebastian Dröge's avatar
      rtpsession: Delay the next regular RTCP packet after early RTCP · b07b7736
      Sebastian Dröge authored
      This is required to not exceed the short term average RTCP bitrate when
      using early feedback as compared to without early feedback.
      b07b7736
    • Sebastian Dröge's avatar
      rtpsession: Add new send-rtcp-full signal · bc9111a0
      Sebastian Dröge authored
      This indicates with a boolean return value if scheduling a new RTCP packet
      within the requested delay was possible. Otherwise it behaves exactly like
      send-rtcp. The only reason for adding a new signal is ABI compatibility.
      bc9111a0
  16. 22 Jan, 2015 1 commit
  17. 22 Oct, 2014 1 commit
    • Miguel París Díaz's avatar
      rtpsession: fix Early Feedback Transmission · e6504e3a
      Miguel París Díaz authored
      In early retransmission we are allowed to schedule 1 regular RTCP packet
      at an earlier time. When we do that, we need to set allow_early to FALSE
      and ignore/drop (or merge) all future requests for early transmission.
      We now first check if we can schedule an early RTCP and if we can,
      actually prepare the data for the next RTCP interval.
      
      After we send the next regular RTCP after the early RTCP, we set
      allow_early to TRUE again to allow more early requests.
      
      Remove the condition for the immediate feedback for now.
      
      Fixes https://bugzilla.gnome.org/show_bug.cgi?id=738319
      e6504e3a
  18. 23 Sep, 2014 1 commit
  19. 16 May, 2014 1 commit
  20. 14 May, 2014 4 commits
  21. 03 May, 2014 1 commit
    • Olivier Crête's avatar
      rtpsession: Keep local conflicting addresses in the session · 2e54d38d
      Olivier Crête authored
      As we now replace the local RTPSource on a conflict, it's no longer possible
      to keep local conflicts in the RTPSource, so they instead need to be kept
      in the RTPSession.
      
      Also fix the rtpcollision test to generate multiple collisions instead of
      one by change the address, as otherwise we detected that it was a single one.
      2e54d38d