Re: GStreamer's zero-copy code is broken

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> On Thu, 2 Mar 2017, Frediano Ziglio wrote:
> [...]
> > Before I forgot this.
> > 
> > Looks like GStreamer when you call gst_buffer_add_video_meta_full
> > assume that buffer is contiguous. The 8 pixel shift (more or less)
> > you can see are artifacts due to how the guest send the frames but
> > basically are bytes inside 2 chunks of data.
> > 
> > Problems happens specifically in gst_video_frame_map_id.
> 
> Did you report this bug to GStreamer?
> If not it would be nice if you could dump your current understanding
> into a bug for future reference.
> 

Just done, see
https://bugzilla.gnome.org/show_bug.cgi?id=779524

> 
> > (passing metadata is also required to pass texture directly to VAAPI).
> 
> Interesting. Does it need the same type of GstVideoMeta data or some
> other type of metadata?
> 
> Did you get the pipeline to work with VAAPI?
> 

Yes, no and more!
Yes: just using vaapipostproc, vaapih264enc and some settings (like 0 b frames)
mainly work.
No: require some additional testing and tuning, seems that last frame is sent
later (didn't investigate much).
More: these video meta information allows VAAPI to get the texture from the
DRM prime. Basically the texture never exit the graphic card not encoded :-)

The CPU utilization reduction is visible.

Frediano
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]