1. 13 Jul, 2020 1 commit
  2. 12 Jul, 2020 1 commit
  3. 09 Jul, 2020 3 commits
    • Víctor Manuel Jáquez Leal's avatar
      vaapidecode: Remove NO_SURFACE error handling · 2a934551
      Víctor Manuel Jáquez Leal authored
      Since surfaces are not bounded to decoding context it makes no sense
      to keep the surface semaphore. This patch removes the handling of
      this error.
      
      Part-of: <!353>
      2a934551
    • Víctor Manuel Jáquez Leal's avatar
      Revert "vaapidecode: drop non-keyframe in reverse playback" · a4c4314b
      Víctor Manuel Jáquez Leal authored
      Since the number of surfaces are not bounded to decoder context,
      this hack is no longer needed.
      
      This reverts commit 19c0c8a9.
      
      Part-of: <!353>
      a4c4314b
    • He Junyan's avatar
      libs: decoder: context: remove surfaces binding from context. · ac3e8c7c
      He Junyan authored
      The vaCreateContext do not need to specify the surfaces for the
      context creation now. So we do not need to bind any surface to the
      context anymore. Surfaces should be the resource belong to display
      and just be used in encoder/decoder context.
      
      The previous manner has big limitation for decoder. The context's
      surface number is decided by dpb size. All the surfaces in dpb will
      be attached to a gstbuffer and be pushed to down stream, and the
      decoder need to wait down stream free the surface and go on if not
      enough surface available. For more and more use cases, this causes
      deadlock. For example,
      
      gst-launch-1.0 filesrc location=a.h264 ! h264parse ! vaapih264dec
      ! x264enc ! filesink location=./output.h264
      
      will cause deadlock and make the whole pipeline hang.
      the x264enc encoder need to cache more than dpb size surfaces.
      
      The best solution is seperating the surfaces number and the dpb size.
      dpb and dpb size shoule be virtual concepts maintained by the decoder.
      And let the surfaces_pool in context maintain the re-use of all surfaces.
      
      For encoder, the situation is better, all the surfaces are just used
      as reference frame and no need to be pushed to down stream. We can
      just reserve and set the capacity of the surfaces_pool to meet the
      request.
      
      Fix: #147
      Fix: #88
      
      Co-Author: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
      Part-of: <!353>
      ac3e8c7c
  4. 08 Jul, 2020 3 commits
  5. 07 Jul, 2020 1 commit
  6. 05 Jul, 2020 3 commits
  7. 03 Jul, 2020 2 commits
    • He Junyan's avatar
      libs: encoder: h265: no need to check the high compression tune. · abea5e81
      He Junyan authored
      The h265 encoder just support tune mode:
        (0): none             - None
        (3): low-power        - Low power mode
      So, no need to check and set the high compression parameters.
      
      And by the way, the current ensure_tuning_high_compression manner
      of choosing the hightest profile idc as the best compression profile
      is not correct. Unlike h264, in h265 the higher profile idc number
      does not mean it has more compression tools, and so it has better
      compression performance. It may even be un-compatible with the lower
      profile idc. For example, the SCREEN_CONTENT_CODING profile with idc
      9 is not compatible with 3D_MAIN profile with idc 8.
      
      Part-of: <!348>
      abea5e81
    • Tim-Philipp Müller's avatar
      Back to development · 19903e1a
      Tim-Philipp Müller authored
      19903e1a
  8. 02 Jul, 2020 1 commit
  9. 23 Jun, 2020 1 commit
  10. 22 Jun, 2020 2 commits
  11. 19 Jun, 2020 3 commits
  12. 17 Jun, 2020 1 commit
    • Michael Olbrich's avatar
      libs: wayland: display: only handle the first output · 4b2f7a18
      Michael Olbrich authored
      Right now, all outputs are handled. The means that the registry object for
      all but the last are leaked. As a result the sizes are not used correctly.
      
      With two outputs, at first the mode and physical size of the second output
      are used. If the first output changes the mode, then the physical size of
      the second output is used in combination with the resolution of the first
      output. The resulting pixel aspect ratio is incorrect.
      
      There seems to be no way to determine on which output the window is shown,
      so just use the first one to get consistent results.
      
      Part-of: <!341>
      4b2f7a18
  13. 11 Jun, 2020 1 commit
    • He Junyan's avatar
      plugins: pluginbase: Do not destroy display when _close() · 72c4a161
      He Junyan authored
      When the element's state changes to NULL, it can still receive
      queries, such as the image formats. The display is needed in such
      queries but not well protected for MT safe.
      For example, ensure_allowed_raw_caps() may still use the display
      while it is disposed by gst_vaapi_plugin_base_close() because of
      the state change.
      
      We can keep the display until the element is destroyed. When the
      state changes to NULL, and then changes to PAUSED again, the display
      can be correctly set(if type changes), or leave untouched.
      
      Fix: #260
      Part-of: <!343>
      72c4a161
  14. 09 Jun, 2020 1 commit
  15. 05 Jun, 2020 16 commits