1. 26 Nov, 2018 1 commit
  2. 23 Nov, 2018 1 commit
  3. 04 Jul, 2018 1 commit
  4. 03 Jul, 2018 6 commits
    • Sreerenj Balachandran's avatar
      msdk: Set 16 bit alignment for width · 84c33be0
      Sreerenj Balachandran authored
      According to MediaSDK specification,
      Width must be a multiple of 16 and Height must be a multiple
      of 16 for progressive frame sequence and a multiple of 32 otherwise.
      
      This patch sets a 16 bit alignment for width and 32 bit alignment
      for height as default.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=796566
      84c33be0
    • Sreerenj Balachandran's avatar
      msdkdec: avoid early destruction of frame in dynamic resolution change · d63a1b4e
      Sreerenj Balachandran authored
      In cases where we do hard resest, the current code destroys the frame
      which has new resolution bit early and this causes buffer_unmap
      warnings. Keep an extra ref to the frame internally to avoid this.
      d63a1b4e
    • Sreerenj Balachandran's avatar
      msdkdec: Fix advanced profile vc1 decode when codec_data presents · ad6162e9
      Sreerenj Balachandran authored
      The gst-msdk decoders only support packetized formats for
      all codecs except VC1. For VC1, it supports codec_data for advanced
      profiles and this codec_data wan't submitting to MSDK's DecodeHeader APIs.
      Make sure the subclass deocders correctly configured so that
      the codec_data buffers are in place in the internal adapter for
      MediaSDK's DecoderHeader usage.
      ad6162e9
    • Sreerenj Balachandran's avatar
      msdkdec: Fix the PTS of output frames · 9efb4c91
      Sreerenj Balachandran authored
      Currently we use the gst_video_decoder_get_oldest_frame()
      to get the old pending frame to output. But this is not correct
      if pts re-ordering required. This patch uses a custom made
      get_old_frame() which accounts the PTS too similar to the
      v4l2decoder.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=796699
      9efb4c91
    • Sreerenj Balachandran's avatar
      msdkdec: Remove dead code · 5c88da4a
      Sreerenj Balachandran authored
      We are not using any ExtendedParams for decoding.
      5c88da4a
    • Sreerenj Balachandran's avatar
      msdk: dec: Add dynamic-configuration change support · 1e95c03c
      Sreerenj Balachandran authored
      The patch adds a serios of changes to support dynamic resolution
      change and efficient utilization of resources.
      Major changes:
      
      -- Use MSDK's apis to retrieve the headers instead of only relying
      on upsteram notification. For eg: avc decoder requires SEI header
      information for dpb count calculation which we don't get from caps.
      
      -- For all codecs other than VP9, we force the reset of decoder
      if resoultion changes to fit with gstreamer flow. VP9 enfource
      the hard reset only if the new resolution is bigger.
      
      -- delay the src caps setting till msdk api's invokation in
      handle_frame to avoid caching multiple configuration values
      
      -- ensure pool negotiation is based on decoder's allocation_caps.
      
      --dynamic resoluttion change use an explicit allocation_query
      to reclaim the buffers before closing the decoder (thanks to v4l2dec)
      
      --In case if we don't get upstream notification of res change (for eg,
      this can can happen for vp9 frames with ivfheader where ivfparse
      is not able to notify the dynamic changes), we handle the the case
      based on MFX_ERR_INCOMPATIBLE_VIDEO_PARAM which is the return value
      of MFXVideoDECODE_DecodeFrameAsync
      
      -- calculate the minimum surfaces to be preallocated based on
      msdk suggestion, downstream requirement, async depth and scratch surface
      count for smooth display.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=796566
      1e95c03c
  5. 07 May, 2018 3 commits
    • Sreerenj Balachandran's avatar
      msdk:dec: Add new propery to dump frames in decoded order · 54482a54
      Sreerenj Balachandran authored
      The new property "output-order" can be set to either "display" order
      which is the default where frames will be outputting in display order,
      or "decoded-order" which will be outputting the frames in decoded order.
      
      The "decoded order" output is generally useful for debugging. But there
      are few
      customers who use it for low-latency streaming. For eg if the customer
      already knows that the stream doesn't have b-frames (which means no
      algorithm requires for display order calculation), then they can use
      "decoded-order"
      output to skip some of the DPB logic to avoid the frame accumulation at
      start-up.
      
      The root cause of the above issue is a bit of unclarity in h264 spec +
      lazy implementation of many H264 encoders; This is well handled in
      gstreamer-vaapi using "low-latency" property:
      https://bugzilla.gnome.org/show_bug.cgi?id=762509
      
      https://bugzilla.gnome.org/show_bug.cgi?id=795783
      54482a54
    • Sreerenj Balachandran's avatar
      msdk: dec: inform msdk if the buffer contains a complete frame · a372c05f
      Sreerenj Balachandran authored
      For packetized input, inform the msdk that the buffer has
      a complete frame or complementary field pairs. For decoding,
      this means that the decoder can proceed with this buffer without
      waiting for the start of the next frame, which effectively reduces
      decoding latency.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=795783
      a372c05f
    • Sreerenj Balachandran's avatar
      msdk: dec: reset async depth to one · 978bcf8a
      Sreerenj Balachandran authored
      Currently we use an async depth of 4 as default (based on
      recommendations
      in msdk apps), which indicates how many asynchronous operations an
      application performs
      before the application explicitly synchronizes the result. As a result,
      we
      queue four frames in decoder which might not be good approach for
      live streaming.
      
      This patch reset the async-depth to 1 as default so that we do sync for
      each frame we decode without queuing. Customer can play with already
      exposed "async-depth" property for other use cases
      
      https://bugzilla.gnome.org/show_bug.cgi?id=795783
      978bcf8a
  6. 02 Apr, 2018 1 commit
  7. 30 Mar, 2018 1 commit
  8. 29 Mar, 2018 1 commit
  9. 08 Mar, 2018 2 commits
  10. 13 Feb, 2018 9 commits
  11. 23 Nov, 2017 1 commit
  12. 22 Nov, 2017 1 commit
  13. 20 Jan, 2017 1 commit
  14. 12 Dec, 2016 1 commit