[Bug 796521] msdk: Playback not smooth by using ximagesink.

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796521

sreerenj <bsreerenj at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW

--- Comment #6 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Nicolas Dufresne (ndufresne) from comment #4)
> (In reply to sreerenj from comment #2) 
> > Somehow, dmabuf backed NV12 to regular NV12 VA surface (not dmabuf)
> > operation is taking more time. Extremely slow and fps dropping more than 50%.
> 
> Did you check the backing memory type ? Sounds like the NV12 data is
> non-cpu-cachable and BGRx data is cpu-cachable. The performance impact on
> CPU processing will be huge if that is the case.

IIUC the video memory is USWC (uncacheable, speculative write-combining) and
regular memcpy() from uswc to system memory is always slow. But I don't know
why BGRx giving better performance. Might be related to the size and alignment
of BGRx data?..

This issue is reproducible with both gstreamer-vaapi and gst-msdk with any 720p
videos.

gstreamer-vaapi:

GST_VAAPI_ENABLE_DIRECT_RENDERING=1 gst-launch-1.0 -v  filesrc location=
Sally.ts ! tsdemux ! mpegvideoparse ! vaapimpeg2dec !  vaapipostproc ! 
video/x-raw, format=NV12 ! videoconvert ! xvimagesink

Here we Explicitly enable direct_rendering (internally use mapping of vasurface
with vaDeriveImage).

In normal use cases, GStreamer-vaapi won't use direct rendering.

gst-msdk:

gst-msdk always use direct mapping. So the issue is easily reproducible with
any pipeline, for eg:
gst-launch-1.0 -v  filesrc location= Sally.ts ! tsdemux ! mpegvideoparse !
msdkmpeg2dec ! msdkvpp !  video/x-raw, format=NV12 ! videoconvert ! xvimagesink

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.