1. 21 Jan, 2020 10 commits
    • Haihao Xiang's avatar
      msdk: Fix compiler warning · 8fa24240
      Haihao Xiang authored
      This patch fixed compiler warning below:
      [1/4] Compiling C object 'sys/msdk/dc44ea0@@gstmsdk@sha/gstmsdkvpp.c.o'.
      ../../gst-plugins-bad/sys/msdk/gstmsdkvpp.c: In function
      ../../gst-plugins-bad/sys/msdk/gstmsdkvpp.c:214:7: warning: suggest
      parentheses around operand of ‘!’ or change ‘&’ to ‘&&’ or ‘!’ to ‘~’
    • Haihao Xiang's avatar
      msdkvp9enc: output video/x-vp9 raw data · 296d99af
      Haihao Xiang authored
      video/x-vp9 is required in the src pad, however the output includes a
      IVF header, which makes the pipeline below doesn't work
        gst-launch-1.0 videotestsrc ! msdkvp9enc ! msdkvp9dec ! fakesink
      Since mfx 1.26, the VP9 encoder supports bitstream without IVF header,
      so in this patch, the mfx version is checked and msdkvp9enc is enabled
      only if mfx 1.26+ is available
    • Haihao Xiang's avatar
      msdk: use cached response for DMABuf when the frame size is same · a74f538c
      Haihao Xiang authored
      User is seeing corrupted display when running `videotestsrc !
      video/x-raw,format=NV12,width=xxx,height=xxx ! msdkh265enc ! msdkh265dec
      ! glimagesink` with changed frame size, e.g. from 1920x1080 to 1920x240
      The root cause is a same dmabuf fd is used for frames with
      different size, which causes some unexpected result. This patch requires
      cached response is used for frames with same size only for DMABuf, so a
      dmabuf fd can't be used for frames with different size any more.
    • Haihao Xiang's avatar
      Revert "msdk: fix surface allocation" · ac948a1d
      Haihao Xiang authored
      This reverts commit 24ecb3f8.
    • Haihao Xiang's avatar
      msdk: fix surface allocation · a783d447
      Haihao Xiang authored
    • Haihao Xiang's avatar
      msdk: reuse GST_MSDK_BUFFER_SURFACE · cccf5ed3
      Haihao Xiang authored
    • Nirbheek Chauhan's avatar
      msdk: Fix increasing memory usage in dynamic pipelines · 1bcf44bb
      Nirbheek Chauhan authored and Haihao Xiang's avatar Haihao Xiang committed
      Our context is non-persistent, and we propagate it throughout the
      pipeline. This means that if we try to reuse any gstmsdk element by
      removing it from the pipeline and then re-adding it, we'll clone the
      mfxSession and create a new gstmsdk context as a child of the old one
      inside `gst_msdk_context_new_with_parent()`.
      Normally this only allocates a few KB inside the driver, but on
      Windows it seems to allocate tens of MBs which leads to linearly
      increasing memory usage for each PLAYING->NULL->PLAYING state cycle
      for the process. The contexts will only be freed when the pipeline
      itself goes to `NULL`, which would defeat the purpose of dynamic
      Essentially, we need to optimize the case in which the element is
      removed from the pipeline and re-added and the same context is re-set
      on it. To detect that case, we set the context on `old_context`, and
      compare it to the new one when preparing the context. If they're the
      same, we don't need to do anything.
      Fixes gstreamer/gst-plugins-bad#946
    • Nirbheek Chauhan's avatar
      msdk: Reorganize context preparation code · 6834a121
      Nirbheek Chauhan authored and Haihao Xiang's avatar Haihao Xiang committed
      Split it out into a separate function with early exits to make the
      flow clearer, and document what the function is doing clearly.
      No functional changes.
    • Nirbheek Chauhan's avatar
      msdk: Fix warning about unused variable on Windows · e83d5fd8
      Nirbheek Chauhan authored and Haihao Xiang's avatar Haihao Xiang committed
    • Nirbheek Chauhan's avatar
      msdk: Use gst_clear_object() · c0d778c2
      Nirbheek Chauhan authored and Haihao Xiang's avatar Haihao Xiang committed
      `gst_object_replace()` is not supposed to be used for unreffing and
      NULLing objects.
  2. 20 Jan, 2020 3 commits
  3. 19 Jan, 2020 16 commits
  4. 16 Jan, 2020 2 commits
  5. 15 Jan, 2020 6 commits
  6. 14 Jan, 2020 3 commits