[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