[Bug 781039] Suspecting unnecessary memcopy with encode use cases

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Fri Apr 7 18:21:17 UTC 2017


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

--- Comment #2 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #1)
> This isn't usually the kind of pipeline someone cares to optimize. If you
> feel like this is needed critically for you let us know, otherwise, don't
> expect anyone to look at it.
> 
> Here's the break down, and it's not vaapi related.
> 
> - filesrc copy from file to GstBuffer/Memory in 1024byte chunk
> - videoparse copy the chunks into single frame, with "default" alignement"
> - vaapiencoder copy the unlaligned normal memory to aligned "special" memory
> 
> An important aspect here, videoparse is now deperated, look at rawvideoparse
> instead. rawvideoparse could spare a copy by using vaapi buffer pool when
> copying the chunks (that might already be done in rawvideoparse).
> 
> Going further is more complex, would require having videoparse is some half
> passthrough mode. This is far from trivial, but you could get the allocation
> query to reach filesrc, teach filesrc to use the allocation query, set the
> chunk size base on the downstream reported size, and read directly in
> vaapidecode provided memory.
> 
> Now, do you still care optimizing this ?

Thanks for the details :), IIUC , irrespective of videoparse/rawvideoparse,
filesrc  is going to do one copy. Would be a good feature if we can avoid it,
right?

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


More information about the gstreamer-bugs mailing list