Skip to content
Snippets Groups Projects
  1. Apr 20, 2016
  2. Apr 19, 2016
  3. Apr 16, 2016
  4. Apr 15, 2016
  5. Apr 13, 2016
  6. Mar 31, 2016
    • Jan Schmidt's avatar
      splitmux: Handle a hang draining out at EOS · c25c9cef
      Jan Schmidt authored
      Make sure that all data is drained out when the reference pad
      goes EOS. Fixes a problem where data that arrives on other
      pads after the reference pad finishes can stall forever and
      never pass EOS.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=763711
      c25c9cef
    • Xavier Claessens's avatar
      splitmuxsink: Fix occasional deadlock when ending file with subtitle · fe31208d
      Xavier Claessens authored
      Deadlock occurs when splitting files if one stream received no buffer during
      the first GOP of the next file. That can happen in that scenario for example:
       1) The first GOP of video is collected, it has a duration of 10s.
          max_in_running_time is set to 10s.
       2) Other streams catchup and we receive the first subtitle buffer at ts=0 and
          has a duration of 1min.
       3) We receive the 2nd subtitle buffer with a ts=1min. in_running_time is set to
          1min. That buffer is blocked in handle_mq_input() because
          max_in_running_time is still 10s.
       4) Since all in_running_time are now > 10s, max_out_running_time is now set to
          10s. That first GOP gets recorded into the file. The muxer pop buffers out
          of the mq, when it tries to pop a 2nd subtitle buffer it blocks because the
          GstDataQueue is empty.
       5) A 2nd GOP of video is collected and has a duration of 10s as well.
          max_in_running_time is now 20s. Since subtitle's in_running_time is already
          1min, that GOP is already complete.
       6) But let's say we overran the max file size, we thus set state to
          SPLITMUX_STATE_ENDING_FILE now. As soon as a buffer with ts > 10s (end of
          previous GOP) arrives in handle_mq_output(), EOS event is sent downstream
          instead. But since the subtitle queue is empty, that's never going to
          happen. Pipeline is now deadlocked.
      
      To fix this situation we have to:
       - Send a dummy event through the queue to wakeup output thread.
       - Update out_running_time to at least max_out_running_time so it sends EOS.
       - Respect time order, so we set out_running_tim=max_in_running_time because
         that's bigger than previous buffer and smaller than next.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=763711
      fe31208d
  7. Mar 29, 2016
  8. Mar 28, 2016
  9. Mar 25, 2016
  10. Mar 24, 2016
  11. Mar 17, 2016
  12. Mar 15, 2016
  13. Mar 13, 2016
  14. Mar 10, 2016
  15. Mar 08, 2016
  16. Mar 07, 2016
    • Thiago Santos's avatar
      qtdemux: reset pending segment if we are already pushing one · d8fb7a9c
      Thiago Santos authored
      When upstream is running in bytes in push-mode, qtdemux will
      convert seeks from time to bytes and send it upstream. Upstream
      element will perform a byte seek and send a byte segment to qtdemux
      that will convert it to time and push it downstream.
      
      There is, however, the pending_segment variable that stores a new
      segment event to be pushed before the next data. When handling seeks
      as mentioned above this variable was being ignored and, if it contained
      some segment event, it would override the one resulting from the seek.
      This would restore a previous segment and would cause the seek segment
      to be discarded downstream.
      
      This patch fixes this issue by unrefing any pending segment as the
      seek from upstream should contain the latest one that should be
      used, as requested by the application.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=763165
      d8fb7a9c
    • Thiago Santos's avatar
      qtdemux: run gst-indent · b46af7fd
      Thiago Santos authored
      Otherwise commits will fail with our indent check hook
      b46af7fd
    • Josep Torra's avatar
      v4l2: fix colorimetry for NV12 · c65b6643
      Josep Torra authored and Nicolas Dufresne's avatar Nicolas Dufresne committed
      Replicate V4L2_MAP_QUANTIZATION_DEFAULT macro behavior.
      At #v4l it was described that documentation might be wrong and that
      we should trust this macro instead.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=762529
      c65b6643
  17. Mar 04, 2016
  18. Mar 02, 2016
Loading