1. 10 Aug, 2017 1 commit
  2. 27 Jul, 2017 2 commits
  3. 25 Jul, 2017 1 commit
  4. 19 Jul, 2017 2 commits
  5. 18 Jul, 2017 1 commit
  6. 13 Jul, 2017 1 commit
  7. 09 Jul, 2017 3 commits
  8. 05 Jul, 2017 1 commit
  9. 04 Jul, 2017 2 commits
  10. 03 Jul, 2017 1 commit
  11. 01 Jul, 2017 2 commits
  12. 29 Jun, 2017 2 commits
  13. 28 Jun, 2017 3 commits
  14. 24 Jun, 2017 5 commits
  15. 22 Jun, 2017 1 commit
  16. 16 Jun, 2017 1 commit
  17. 15 Jun, 2017 3 commits
    • Tim-Philipp Müller's avatar
      qtmux: add support for muxing PNG · 3a0fe9c2
      Tim-Philipp Müller authored
      Demuxer already supported it.
    • Sebastian Dröge's avatar
      rtspsrc: Use a mutex for protecting against concurrent send/receives · a722f6e8
      Sebastian Dröge authored
      We currently send data to the RTSP connection from multiple threads:
      whenever a command is to be handled and whenever RTCP is generated. This
      can cause data corruption or worse if both happen at the same time.
      As such, protect gst_rtsp_connection_send() and gst_rtsp_connection_receive()
      calls with a mutex. While this means that we hold a mutex during the IO
      operation, this is not actually a problem as the IO operation can be
      interrupted (gst_rtsp_connection_flush()) at any time and is blocking by
      itself anyway.
    • Sebastian Dröge's avatar
      qtmux: Un-merge the last two stsc entries after serializing · deb9c62c
      Sebastian Dröge authored
      The last entry will most likely get new samples added to it in "robust"
      muxing mode, changing the samples_per_chunk and thus making it wrong to
      keep the last two entries merged. It will run into an assertion later
      when adding a new sample to the chunk.
      Thanks to gdiener@cardinalpeak.com for the analysis of the bug and
      proposal for a solution.
  18. 13 Jun, 2017 2 commits
  19. 07 Jun, 2017 1 commit
  20. 06 Jun, 2017 1 commit
  21. 02 Jun, 2017 1 commit
  22. 01 Jun, 2017 1 commit
    • Tim-Philipp Müller's avatar
      rtph264depay: simplify buffer accumulation control flow · a68a7fb6
      Tim-Philipp Müller authored
      There is no difference between pushing out a buffer directly
      with gst_rtp_base_depayload_push() and returning it from the
      process function. The base class will just call _depayload_push()
      on the returned buffer as well.
      So instead of marshalling buffers through three layers and back,
      just push them from one place in handle_nal() and always return
      NULL from the process vfunc. This simplifies the code a little.
      Also rename _push_fragmentation_unit() to _finish_fragmentation_unit()
      for clarity. Push sounds like it means being pushed out, whereas
      it might just be pushed into an adapter.
      This change has the side-effect that multiple NALs in a single STAP
      (such as SPS/PPS) may no longer be pushed out as a single buffer if
      we output NALs in byte-stream format (i.e. not aggregate AUs), but
      that shouldn't really make any difference to anyone.
  23. 31 May, 2017 1 commit
  24. 24 May, 2017 1 commit
    • Tim-Philipp Müller's avatar
      rtpopusdepay: minor perf improvements · a9f91660
      Tim-Philipp Müller authored
      Use the ::process_rtp_packet() vfunc to avoid mapping the
      RTP buffer twice.
      gst_rtp_buffer_get_payload_buffer() returns a new sub-buffer
      which will always be writable, so no need to make it writable.