Skip to content
Snippets Groups Projects
  1. Sep 08, 2021
  2. Sep 06, 2021
  3. Aug 27, 2021
  4. Aug 24, 2021
  5. Aug 23, 2021
  6. Aug 20, 2021
  7. Aug 18, 2021
  8. Aug 11, 2021
  9. Jul 22, 2021
    • Seungha Yang's avatar
      basesink: Don't swap rstart/rstop when stepping · 0a63363f
      Seungha Yang authored and GStreamer Marge Bot's avatar GStreamer Marge Bot committed
      Step handling is implemented based on unmodified start/stop
      segment running time, and basesink takes rate into account for
      stepping. This commit is partially undoing new behavior introduced by
      the commit of 39b9cc55 when stepping.
      
      Part-of: <gstreamer/gstreamer!858>
      0a63363f
    • Nirbheek Chauhan's avatar
      gstptpclock: Don't leak the GList · 49ae75f2
      Nirbheek Chauhan authored and GStreamer Marge Bot's avatar GStreamer Marge Bot committed
      120 bytes in 5 blocks are definitely lost in loss record 7,615 of 9,510
         at 0x484486F: malloc (vg_replace_malloc.c:380)
         by 0x58A2938: g_malloc (gmem.c:106)
         by 0x58BA1F4: g_slice_alloc (gslice.c:1069)
         by 0x588F059: g_list_prepend (glist.c:335)
         by 0x5B9C5C0: select_best_master_clock (gstptpclock.c:756)
         by 0x5B9CA8E: cleanup_cb (gstptpclock.c:1930)
         by 0x589AD20: g_timeout_dispatch (gmain.c:4889)
         by 0x589A4CE: UnknownInlinedFun (gmain.c:3337)
         by 0x589A4CE: g_main_context_dispatch (gmain.c:4055)
         by 0x58EE4E7: g_main_context_iterate.constprop.0 (gmain.c:4131)
         by 0x5899A92: g_main_loop_run (gmain.c:4329)
         by 0x5B9BA4C: ptp_helper_main (gstptpclock.c:1980)
         by 0x58C8C31: g_thread_proxy (gthread.c:826)
      
      576 bytes in 24 blocks are definitely lost in loss record 8,782 of 9,510
         at 0x484486F: malloc (vg_replace_malloc.c:380)
         by 0x58A2938: g_malloc (gmem.c:106)
         by 0x58BA1F4: g_slice_alloc (gslice.c:1069)
         by 0x588F059: g_list_prepend (glist.c:335)
         by 0x5B9C5C0: select_best_master_clock (gstptpclock.c:756)
         by 0x5B9EFA0: handle_announce_message (gstptpclock.c:934)
         by 0x5B9EFA0: handle_ptp_message (gstptpclock.c:1765)
         by 0x5B9EFA0: have_stdin_data_cb (gstptpclock.c:1851)
         by 0x589A4CE: UnknownInlinedFun (gmain.c:3337)
         by 0x589A4CE: g_main_context_dispatch (gmain.c:4055)
         by 0x58EE4E7: g_main_context_iterate.constprop.0 (gmain.c:4131)
         by 0x5899A92: g_main_loop_run (gmain.c:4329)
         by 0x5B9BA4C: ptp_helper_main (gstptpclock.c:1980)
         by 0x58C8C31: g_thread_proxy (gthread.c:826)
         by 0x5DA4298: start_thread (pthread_create.c:481)
      
      Part-of: <gstreamer/gstreamer!857>
      49ae75f2
    • Nirbheek Chauhan's avatar
      gstpad: Don't spam INFO when default-chaining a buffer list · bbbf0c10
      Nirbheek Chauhan authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      This is being logged for each buffer, so it should not use INFO.
      
      Part-of: <gstreamer/gstreamer!856>
      bbbf0c10
  10. Jul 08, 2021
  11. Jun 24, 2021
  12. Jun 11, 2021
  13. May 14, 2021
  14. May 06, 2021
  15. Apr 20, 2021
    • Miguel París Díaz's avatar
      pad: clear probes holding mutex · 0d1fad0e
      Miguel París Díaz authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      Protect clearing probes against concurrent modification which might happen
      due to dispose does NOT guarantee that the object is not used anymore, as
      it could be referenced again and so being continued used.
      So, as in the rest of places where probes hook list is used, on dispose
      it should be accessed holding the mutex "GST_OBJECT_LOCK (pad);" as
      GHookList is not thread-safe.
      
      Part-of: <gstreamer/gstreamer!800>
      0d1fad0e
  16. Apr 17, 2021
    • Edward Hervey's avatar
      queue2: Refuse all serialized queries when posting buffering messages · b566cbe0
      Edward Hervey authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      When posting buffering messages there are no safe places or timing to avoid
      deadlocks.
      
      Previously the code was trying to be "smart" by only forwarding serialized
      queries if the queue was empty ... but that could happen when queue2 hadn't yet
      posted a 100% buffering message. Meaning the pipeline might be paused and
      pushing a serialized query downstream might never complete.
      
      Therefore let's completely disable forwarding of serialized queries when
      `queue2` is used as a buffering element (meaning `ALLOCATION` and `DRAIN`
      queries).
      
      Part-of: <gstreamer/gstreamer!797>
      b566cbe0
  17. Apr 13, 2021
  18. Apr 06, 2021
  19. Mar 15, 2021
  20. Mar 11, 2021
  21. Jan 31, 2021
  22. Jan 30, 2021
  23. Jan 28, 2021
  24. Jan 14, 2021
  25. Jan 13, 2021
  26. Jan 12, 2021
Loading