> On 2018.01.24 03:59:27 -0500, Frediano Ziglio wrote: > > There's not currently a remote solution as far as I know. > > The experimental patches sent on September 2016 were already using > > correcly gst_dmabuf_* functions without texture read back, the problem > > with GStreamer are stability and licensing. > > Licensing as missing some package (due to license) for encoding > > (like Intel encoding vaapi). > > Could you elaborate on this? We're not awared of this issue before, > and if this is intel gst-vaapi issue, we may see if there's possible > solution on that. > > thanks > See https://bugzilla.redhat.com/show_bug.cgi?id=770371 Frediano > > Stability as using GStreamer using libvirt causes some initialization > > crash due to some internal library (orc) refusing to work with > > a log an abort call. > > > > We are pushing to get the required packages into the system. > > > > Jonathon is working on separating GStreamer in another process > > to make it work. > > > > Uri and Snir are working on the H/W encoding/decoding part. > > > > Frediano > > > > > > > > Hi, > > > > > > We'd like to know if there is a plan or any progress on proper remote > > > display > > > by encoding vgpu's framebuffers as video directly through dma-buf file > > > descriptors. > > > > > > The current remote display solution is using texture readback, which has > > > performance loss. > > > > > > As SPICE can use GStreamer to encode and GStreamer has APIs like > > > "gst_dmabuf_*" which can be used to encode through dma-buf file > > > descriptors, > > > can SPICE support APIs to > > > encode vgpu's framebuffer directly through dma-buf file descriptors, > > > without > > > any copy? > > > > > > Thanks. > > > > > > BR, > > > Tina > > > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel