1. 24 Jul, 2019 1 commit
  2. 23 Jul, 2019 2 commits
  3. 22 Jul, 2019 5 commits
    • Seungha Yang's avatar
      nvenc: Register elements per GPU device with capability check · 92afa749
      Seungha Yang authored
      * By this commit, if there are more than one device,
      nvenc element factory will be created per
      device like nvh264device{device-id}enc and nvh265device{device-id}enc
      in addition to nvh264enc and nvh265enc, so that the element factory
      can expose the exact capability of the device for the codec.
      
      * Each element factory will have fixed cuda-device-id
      which is determined during plugin initialization
      depending on the capability of corresponding device.
      (e.g., when only the second device can encode h265 among two GPU,
      then nvh265enc will choose "1" (zero-based numbering)
      as it's target cuda-device-id. As we have element factory
      per GPU device, "cuda-device-id" property is changed to read-only.
      
      * nvh265enc gains ability to encoding
      4:4:4 8bits, 4:2:0 10 bits formats and up to 8K resolution
      depending on device capability.
      Additionally, I420 GLMemory input is supported by nvenc.
      92afa749
    • Seungha Yang's avatar
      nvdec: Create CUDA context with registered device id · 0239152b
      Seungha Yang authored
      Only the default device has been used by NVDEC so far.
      This commit make it possible to use registered device id.
      To simplify device id selection, GstNvDecCudaContext usage is removed.
      0239152b
    • Seungha Yang's avatar
      nvdec: Register elements per device/codec with capability check · 1df2f13d
      Seungha Yang authored
      By this commit, each codec has its own element factory so the
      nvdec element factory is removed. Also, if there are more than one device,
      additional nvdec element factory will be created per
      device like nvh264device{device-id}dec, so that the element factory
      can expose the exact capability of the device for the codec.
      1df2f13d
    • Seungha Yang's avatar
      msdk: Do not expose DMA buffer caps feature on Windows · 9ec62418
      Seungha Yang authored
      On Windows, DMA buffer is not supported. PadTemplate with actually
      supported feature seems to more make sense.
      9ec62418
    • Seungha Yang's avatar
      nvcodec: Drop cudaGL.h dependency · afe3c7e3
      Seungha Yang authored
      nvcodec does not use any type/define/enum in cudaGL.h.
      afe3c7e3
  4. 19 Jul, 2019 2 commits
  5. 17 Jul, 2019 2 commits
  6. 16 Jul, 2019 1 commit
    • Seungha Yang's avatar
      kmssink: Fix implicit declaration build error · c64cdf2f
      Seungha Yang authored
      ffs() and strcmp() require string.h
      
      gstkmssink.c:255:28: error: implicit declaration of function ‘ffs’ [-Werror=implicit-function-declaration]
             crtc_id = res->crtcs[ffs (crtcs_for_connector) - 1];
                                  ^~~
      
      gstkmssink.c:590:10: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration]
           if (!strcmp (property->name, prop_name)) {
                ^~~~~~
      c64cdf2f
  7. 15 Jul, 2019 1 commit
    • Sebastian Dröge's avatar
      decklinkvideosrc: Don't report that we have signal until we know for sure · bf9ecd65
      Sebastian Dröge authored
      Previously we would've reported that there is signal unless we know for
      sure that we don't have signal. For example signal would've been
      reported before the device is even opened.
      
      Now keep track whether the signal state is unknown or not and report no
      signal if we don't know yet. As before, only send an INFO message about
      signal recovery if we actually had a signal loss before.
      bf9ecd65
  8. 09 Jul, 2019 2 commits
  9. 08 Jul, 2019 3 commits
    • Marc Leeman's avatar
    • Seungha Yang's avatar
      nvdec,nvenc: Port to dynamic library loading · c18fda03
      Seungha Yang authored
      ... and put them into new nvcodec plugin.
      
      * nvcodec plugin
      Now each nvenc and nvdec element is moved to be a part of nvcodec plugin
      for better interoperability.
      Additionally, cuda runtime API header dependencies
      (i.e., cuda_runtime_api.h and cuda_gl_interop.h) are removed.
      Note that cuda runtime APIs have prefix "cuda". Since 1.16 release with
      Windows support, only "cuda.h" and "cudaGL.h" dependent symbols have
      been used except for some defined types. However, those types could be
      replaced with other types which were defined by "cuda.h".
      
      * dynamic library loading
      CUDA library will be opened with g_module_open() instead of build-time linking.
      On Windows, nvcuda.dll is installed to system path by CUDA Toolkit
      installer, and on *nix, user should ensure that libcuda.so.1 can be
      loadable (i.e., via LD_LIBRARY_PATH or default dlopen path)
      Therefore, NVIDIA_VIDEO_CODEC_SDK_PATH env build time dependency for Windows
      is removed.
      c18fda03
    • Seungha Yang's avatar
      d3d11videosink: Add new Direct3D11 video render plugin · 5c3879ac
      Seungha Yang authored
      Direct3D11 was shipped as part of Windows7 and it's obviously
      primary graphics API on Windows.
      
      This plugin includes HDR10 rendering if following requirements are satisfied
      * IDXGISwapChain4::SetHDRMetaData is available (decleared in dxgi1_5.h)
      * Display can support DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020 color space
      * Upstream provides 10 bitdepth format with smpte-st 2084 static metadata
      5c3879ac
  10. 07 Jul, 2019 3 commits
    • Haihao Xiang's avatar
      msdk: add msdkvp9enc element · f5b1c75d
      Haihao Xiang authored
      f5b1c75d
    • Haihao Xiang's avatar
      msdk: workaround for MFX_FOURCC_VP9_SEGMAP surface · ba7f3f48
      Haihao Xiang authored
      MFX_FOURCC_VP9_SEGMAP surface in MSDK is an internal surface however
      MSDK still call the external allocator for this surface, so this plugin
      has to return UNSUPPORTED and force MSDK allocates surface using the
      internal allocator.
      
      See https://github.com/Intel-Media-SDK/MediaSDK/issues/762 for details
      ba7f3f48
    • Haihao Xiang's avatar
      msdkenc: allow encode element requires extra frames · 12218984
      Haihao Xiang authored
      The call of MFXVideoENCODE_EncodeFrameAsync may not generate output and
      the function returns MFX_ERR_MORE_DATA with NULL sync point, the input
      frame is cached in this case, so it is possible that all allocated
      frames go into the surfaces_used list after calling
      MFXVideoENCODE_EncodeFrameAsync a few times, then the encoder will fail
      to get an available surface before releasing used frames
      
      This patch adds a new field of num_extra_frames to GstMsdkEnc and allows
      encode element requires extra frames, the default value is 0.
      
      This patch is the preparation for msdkvp9enc element.
      12218984
  11. 30 Jun, 2019 1 commit
    • Haihao Xiang's avatar
      msdk: don't share context between msdkvpp and msdkenc · 98e49673
      Haihao Xiang authored
      msdkenc supports CSC implicitly, so it is possible that two VPP
      processes are required when a pipeline contains msdkvpp and msdkenc.
      Before this fix, msdkvpp and msdkenc may share the same context, hence
      the same mfx session, which results in MFX_ERR_UNDEFINED_BEHAVIOR
      in MSDK because a mfx session has at most one VPP process only
      
      This fixes the broken pipelines below:
      
      gst-launch-1.0 videotestsrc ! video/x-raw,format=I420 ! msdkh264enc ! \
      msdkh264dec ! msdkvpp ! video/x-raw,format=YUY2 ! fakesink
      
      gst-launch-1.0 videotestsrc ! msdkvpp ! video/x-raw,format=YUY2 ! \
      msdkh264enc ! fakesink
      98e49673
  12. 29 Jun, 2019 17 commits