1. 05 Feb, 2015 3 commits
    • Jan Schmidt's avatar
      splitmux: Implement new elements for splitting files at mux level. · 5e2214d3
      Jan Schmidt authored
      Implement 2 new elements - splitmuxsink and splitmuxsrc.
      splitmuxsink is a bin which wraps a muxer and takes 1 video stream,
      plus audio/subtitle streams, and starts a new file
      whenever necessary to avoid overrunning a threshold of either bytes
      or time. New files are started at a keyframe, and corresponding audio
      and subtitle streams are split at packet boundaries to match
      video GOP timestamps.
      splitmuxsrc is a corresponding source element which handles
      the splitmux:// URL and plays back all component files,
      reconstructing the original elementary streams as it goes.
    • Thiago Santos's avatar
      tests: souphttpsrc: update ssl key/cert pair · 59431f66
      Thiago Santos authored
      Our ones were expired. The new ones were copied from libsoup's
      tests files.
      Also sets the property to use our own cert to validate the
      server, otherwise the default system certs would be used
      and it would fail.
    • Thiago Santos's avatar
      rtph264depay: prevent trying to get 0 bytes from adapter · a6d73797
      Thiago Santos authored
      This causes an assertion and would lead to getting a NULL instead
      of a buffer. Without proper checking this would easily lead to
      a segfault
  2. 04 Feb, 2015 1 commit
  3. 03 Feb, 2015 1 commit
  4. 02 Feb, 2015 2 commits
  5. 31 Jan, 2015 3 commits
  6. 30 Jan, 2015 4 commits
  7. 28 Jan, 2015 1 commit
  8. 27 Jan, 2015 2 commits
  9. 26 Jan, 2015 4 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
      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).
    • 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.
    • 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.
    • Ohn Yongjin's avatar
      pulsesink: Free format_info in query_getcaps · bf10d33b
      Ohn Yongjin authored
      If we can not create probe stream in query_getcaps function, it will appear
      memory leakage from format info.
      The following patch prevent memory leakage in pulsesink.
  10. 23 Jan, 2015 3 commits
  11. 22 Jan, 2015 2 commits
  12. 21 Jan, 2015 4 commits
  13. 19 Jan, 2015 2 commits
  14. 13 Jan, 2015 3 commits
  15. 12 Jan, 2015 1 commit
  16. 10 Jan, 2015 2 commits
  17. 09 Jan, 2015 2 commits