Skip to content
Snippets Groups Projects
  1. Jun 07, 2024
  2. May 29, 2024
    • Vivek Kasireddy's avatar
      video-stream: Don't stop a stream associated with gl_draw (v2) · ddc33588
      Vivek Kasireddy authored
      
      We do not want to stop a stream associated with gl_draw as a result
      of timeout because we may not get another opportunity to create a
      new stream if the current one gets stopped. However, when the
      stream does get stopped for other reasons, we need to clear the
      gl_draw_stream pointer associated with the relevant DC.
      
      v2: (suggestions from Frediano)
      - Don't stop the stream regardless of whether gl_draw is ongoing
        or not
      
      Cc: Frediano Ziglio <freddy77@gmail.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
      Cc: Dongwon Kim <dongwon.kim@intel.com>
      Signed-off-by: default avatarVivek Kasireddy <vivek.kasireddy@intel.com>
      Acked-by: default avatarFrediano Ziglio <freddy77@gmail.com>
      ddc33588
    • Vivek Kasireddy's avatar
      gstreamer-encoder: Add an encoder function that takes dmabuf fd as input (v3) · 5a6c0329
      Vivek Kasireddy authored
      
      This patch adds a new function to enable the creation of Gst memory with
      the dmabuf fd as the source by using a dmabuf allocator. And, it also
      adds a mechanism to register and invoke any callbacks once the Gst memory
      object is no longer used by the pipeline.
      
      This patch also ensures that the source_fps value is always non-zero.
      
      v2: (suggestions from Frediano)
      - Moved the code associated with add_frame() and pipeline configuration
        into separate functions that are used when encoding dmabuf fd
      
      v3:
      - Add the new gstreamer-allocators dependency in autoconf as well
        (Frediano)
      - Ensure that VIDEO_ENCODER_FRAME_UNSUPPORTED is returned when an
        error is encountered in spice_gst_encoder_encode_dmabuf()
      
      Cc: Frediano Ziglio <freddy77@gmail.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
      Cc: Dongwon Kim <dongwon.kim@intel.com>
      Signed-off-by: default avatarVivek Kasireddy <vivek.kasireddy@intel.com>
      5a6c0329
    • Vivek Kasireddy's avatar
      dcc-send: Encode and send gl_draw stream data to the remote client (v4) · 762b4b0d
      Vivek Kasireddy authored
      
      For remote (or non-gl) clients, if a valid gl_draw stream exists,
      then we first extract the dmabuf fd associated with the scanout and
      share it with the encoder along with other key parameters such as
      stride, width and height. Once the encoder finishes creating an
      encoded buffer (using the dmabuf fd as input), we then send it
      over to the client. And, as soon as the encoder notifies that it
      is no longer using the dmabuf fd, we send a gl_draw_done async to
      the application.
      
      v2: (suggestions and fixups from Frediano)
      - Moved the DisplayStreamData initialization code from
        red_marshall_stream_data() into a separate function that is reused
        when marshalling gl_draw_stream.
      - Used new/delete instead of g_new/g_free for creating and destroying
        dmabuf_data object
      - s/notify_mem_free/free
        s/red_gst_mem_free_cb/red_free_fb
      - Removed the usage of opaque from red_free_cb
      
      v3:
      - Obtain the key params such as fd, stride, etc from the stream instead
        of the scanout
      - Replace the switch with if in red_marshall_gl_draw_stream() to avoid
        printing a warning (and spamming the console) when a frame is dropped
      
      v4:
      - Slightly improve the readability of red_marshall_gl_draw_stream() by
        adding checks at the start
      
      Cc: Frediano Ziglio <freddy77@gmail.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
      Cc: Dongwon Kim <dongwon.kim@intel.com>
      Signed-off-by: default avatarVivek Kasireddy <vivek.kasireddy@intel.com>
      762b4b0d
    • Vivek Kasireddy's avatar
      dcc: Create a stream associated with gl_draw for non-gl clients (v6) · 1624dede
      Vivek Kasireddy authored
      
      For non-gl/remote clients, if there is no stream associated with
      the DisplayChannel, then we create a new stream. Otherwise, we
      just update the current stream's timestamp.
      
      v2: (suggestions and fixups from Frediano)
      - Moved the gl_draw_stream object from DCC to DC
      - Moved the stream initialization code from display_channel_create_stream()
        into a separate function that is reused when creating gl_draw_stream
      
      v3:
      - Create a new primary surface whenever a new stream gets created
      
      v4:
      - Use nullptr instead of NULL and true instead of TRUE (Frediano)
      - Create the stream as part of gl scanout instead of gl draw operation
        so that if would be easily possible to obtain key params such as
        stride, flags, etc
      - Store key params such as fd, flags, stride, etc in the stream so that
        we do not have to look at scanout again
      
      v5: (Frediano)
      - No need to pass scanout object to create_gl_draw_stream as it is
        always NULL
      - Don't compute the stream's last_time if drawable is valid
      - Let the default input_fps be MAX_FPS
      - Use uint32_t type for stride
      - Make sure that a newly created stream is provided to all connected clients
      - When the scanout's drm_dma_buf_fd is associated with a stream, take
        an additional reference on the fd to ensure that it is not closed
        when the stream might still be using it
      
      v6:
      - Add a new helper is_new_stream_needed() to determine when to create new
        stream
      - Add more checks to see if the encoder is created or not
      - Don't share the dmabuf fd with the stream and instead keep the
        ownerhip of the fd with the scanout
      
      Cc: Frediano Ziglio <freddy77@gmail.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
      Cc: Dongwon Kim <dongwon.kim@intel.com>
      Signed-off-by: default avatarVivek Kasireddy <vivek.kasireddy@intel.com>
      1624dede
  3. May 28, 2024
    • Vivek Kasireddy's avatar
      dcc: Check to see if the client supports multiple codecs (v2) · 05bab80b
      Vivek Kasireddy authored
      
      We need to determine if the client is new enough to support multiple
      codecs -- which might include any of the Gstreamer based ones.
      
      v2: (suggestions and fixups from Frediano)
      - Add is_gl_client() method to DisplayChannelClient instead of a
        dcc_is_gl_client() function.
      - Avoid the usage of XXX_CAST macro.
      
      Cc: Frediano Ziglio <freddy77@gmail.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
      Cc: Dongwon Kim <dongwon.kim@intel.com>
      Signed-off-by: default avatarVivek Kasireddy <vivek.kasireddy@intel.com>
      Acked-by: default avatarFrediano Ziglio <freddy77@gmail.com>
      05bab80b
    • Vivek Kasireddy's avatar
      gstreamer-encoder: Use a h/w based encoder with Intel GPUs if possible (v5) · 34e342a2
      Vivek Kasireddy authored
      
      Once it is determined that an Intel GPU is available/active (after
      looking into udev's database), we try to see if there is a h/w
      based encoder (element) available (in Gstreamer's registry cache)
      for the user selected video codec. In other words, if we find that
      the Intel Media SDK Gstreamer plugin (libgstmsdk.so) and associated
      libraries (such as va or vaapi) are all installed properly, we add
      the appropriate h/w based encoder and post-processor/converter
      elements to the pipeline (along with any relevant options) instead
      of the s/w based elements.
      
      For example, if the user selects h264 as the preferred codec format,
      msdkh264enc and vapostproc will be preferred instead of x264enc
      and videoconvert.
      
      v2: (addressed some review comments from Frediano)
      - Moved the udev helper into spice-common
      - Refactored the code to choose plugins in order msdk > va > vaapi
      
      v3: (Frediano)
      - Added relevant encoder options for mjpeg and vp9 codecs (Jin Chung)
      
      v4: (Fixups from Frediano)
      - Free the encoder when we cannot find vpp
      - Change type and find plugins array length using G_N_ELEMENTS
      - Fix gstenc_name UAF by freeing it at the end of the function
      - Use g_str_has_prefix instead of strstr
      - Include the string "_hw_" in function names that deal with
        h/w based plugins
      - Rebase on master
      
      v5: rebase on master
      
      Cc: Frediano Ziglio <freddy77@gmail.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
      Cc: Dongwon Kim <dongwon.kim@intel.com>
      Signed-off-by: default avatarVivek Kasireddy <vivek.kasireddy@intel.com>
      Co-developed-by: default avatarJin Chung Teng <jin.chung.teng@intel.com>
      Co-developed-by: default avatarHazwan Arif Mazlan <hazwan.arif.mazlan@intel.com>
      34e342a2
  4. May 27, 2024
    • Frediano Ziglio's avatar
      tests: Remove warning compiling · b92149f2
      Frediano Ziglio authored
      
      Remove:
      
          test-display-streaming.c: In function 'get_commands':
          test-display-streaming.c:218:42: error: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
            218 |     *commands = (Command*) calloc(sizeof(Command), *num_commands);
                |                                          ^~~~~~~
          test-display-streaming.c:218:42: note: earlier argument should specify number of elements, later size of each element
      
      Signed-off-by: default avatarFrediano Ziglio <freddy77@gmail.com>
      b92149f2
  5. May 26, 2024
  6. Nov 22, 2023
    • Frediano Ziglio's avatar
      test-listen: Use OpenSSL BIO instead of GIO library · fe1c25f5
      Frediano Ziglio authored and Frediano Ziglio's avatar Frediano Ziglio committed
      
      test-listen using GIO had issues running under CI for a while.
      GIO is reading some desktop configuration so it's not very CI
      friendly.
      So instead of using GIO use OpenSSL BIO. The code does not
      get much bigger or complicated.
      We are already using OpenSSL so we are not adding dependencies.
      
      This fixes CI for Fedora 39 (just released and available on docker).
      
      This allowed to remove an old workaround for GIO in .gitlab-ci.yml
      (cfr commit 89edf808
      "ci: Workaround an issue with GLib on Fedora 30")
      
      Signed-off-by: default avatarFrediano Ziglio <freddy77@gmail.com>
      fe1c25f5
  7. Nov 15, 2023
    • Frediano Ziglio's avatar
      red-stream: Fix typo in comment · 7cfebdf6
      Frediano Ziglio authored
      
      renogotiation -> renegotiation
      
      Signed-off-by: default avatarFrediano Ziglio <freddy77@gmail.com>
      7cfebdf6
    • Vivek Kasireddy's avatar
      gstreamer-encoder: Use an env var to override converter format · 3208be45
      Vivek Kasireddy authored and Frediano Ziglio's avatar Frediano Ziglio committed
      
      If we use the x264enc encoder to encode a stream, then videoconvert
      would convert the BGRx data into Y444, which is the preferred format
      for x264enc. However, some decoders particularly the ones that are
      h/w based cannot work with Y444 if it was the format used by the
      encoder. Therefore, to address these situations, we need a way to
      override the format used during the encoding stage which can be
      accomplished by using the environment variable introduced in this
      patch: SPICE_CONVERTER_PREFERRED_FORMAT.
      
      For example, using NV12 as the output format for the videoconvert
      element would allow us to pair a s/w based encoder (such as x264enc)
      with a h/w based decoder (such as msdkh264dec) for decoding the
      stream as most h/w based decoders only work with NV12 format given
      its popularity.
      
      Note that choosing an encoder format such as NV12 over Y444 would
      probably result in decreased video quality although it would be
      compatible with more decoders. Ideally, the client and server need
      to negotiate a suitable format dynamically but the current
      capabilities do not allow for such exchange.
      
      Cc: Frediano Ziglio <freddy77@gmail.com>
      Cc: Dongwon Kim <dongwon.kim@intel.com>
      Based-on-patch-by: default avatarHazwan Arif Mazlan <hazwan.arif.mazlan@intel.com>
      Signed-off-by: default avatarJin Chung Teng <jin.chung.teng@intel.com>
      Signed-off-by: default avatarVivek Kasireddy <vivek.kasireddy@intel.com>
      Acked-by: default avatarFrediano Ziglio <freddy77@gmail.com>
      3208be45
  8. Sep 17, 2023
  9. May 30, 2023
  10. May 26, 2023
    • orbea's avatar
      server: add SSL_OP_NO_RENEGOTIATION fallback path · 5e580eef
      orbea authored and Frediano Ziglio's avatar Frediano Ziglio committed
      
      With LibreSSL SSL_OP_NO_CLIENT_RENEGOTIATION is opaque which is not
      compatible with the OpenSSL 1.0.2 and earlier code path in
      red-stream.cpp while SSL_OP_NO_RENEGOTIATION is not yet defined for the
      newer OpenSSL code path in reds.cpp.
      
      So with OpenSSL 1.1.0 and later if SSL_OP_NO_RENEGOTIATION is undefined
      and SSL_OP_NO_CLIENT_RENEGOTIATION is defined then define the former as
      the latter. This will allow the build to succeed with LibreSSL 3.7.2 and
      in the future when newer LibreSSL versions add SSL_OP_NO_RENEGOTIATION
      that code path will then be used automatically.
      
      Signed-off-by: default avatarorbea <orbea@riseup.net>
      Acked-by: default avatarFrediano Ziglio <freddy77@gmail.com>
      5e580eef
  11. May 11, 2023
  12. May 10, 2023
  13. Oct 22, 2022
  14. Sep 13, 2022
  15. Aug 03, 2022
  16. Jul 19, 2022
Loading