1. 28 Jun, 2017 2 commits
  2. 26 Jun, 2017 3 commits
  3. 25 Jun, 2017 1 commit
  4. 24 Jun, 2017 5 commits
  5. 23 Jun, 2017 7 commits
  6. 22 Jun, 2017 1 commit
  7. 19 Jun, 2017 1 commit
  8. 16 Jun, 2017 1 commit
  9. 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.
      3a0fe9c2
    • 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.
      a722f6e8
    • 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.
      deb9c62c
  10. 13 Jun, 2017 2 commits
  11. 07 Jun, 2017 2 commits
  12. 06 Jun, 2017 2 commits
  13. 05 Jun, 2017 1 commit
  14. 02 Jun, 2017 1 commit
  15. 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.
      a68a7fb6
  16. 31 May, 2017 1 commit
  17. 26 May, 2017 2 commits
  18. 25 May, 2017 1 commit
  19. 24 May, 2017 3 commits
    • Nicolas Dufresne's avatar
      v4l2videoenc: Remove unused function · 85218c69
      Nicolas Dufresne authored
      85218c69
    • Nicolas Dufresne's avatar
    • Ayaka's avatar
      v4l2: Add Video Encoder support · 27310365
      Ayaka authored
      This implements H264 encoding support using generic V4L2 interface. It is
      reported to work with Samsung MFC driver, IXM.6 CODA driver and
      Qualcomm mainline Venus driver. Other platform should be supported as
      none of this work is platform specific.
      
      The implementation consist of a GstV4l2VideoEnc base class, which
      implements the core streaming functionality. This base class is implemented
      by GstV4l2H264Enc class that implements the caps negotiation specific to
      H264 profiles and level. This implementation supports hardware with multiple
      H264 encoder. Though, to make it simplier to use, the first discovered H264
      encoder will be named v4l2h264enc. Other encoder found during discovery will
      have a unique name like v4l2video0h264enc.
      
      This work is the combined work of multiple developpers in the last 3
      years. Thanks to all of the contributors:
      
        Ayaka <ayaka@soulik.info>
        Frédéric Sureau <frederic.sureau@vodalys.com>
        Jean-Michel Hautbois <jean-michel.hautbois@veo-labs.com>
        Nicolas Dufresne <nicolas.dufresne@collabora.com>
        Pablo Anton <pablo.anton@vodalys-labs.com>
      
      https://bugzilla.gnome.org/show_bug.cgi?id=728438
      27310365