GNOME Bugzilla – Bug 781039
Implement rawvideosrc in debug utils to test raw encoder/decoder performance
Last modified: 2018-11-03 14:06:50 UTC
Just noticed the encoder pipeline is doing extra memcopy. sample pipeline: gst-launch-1.0 filesrc location=sample.yuv ! videoparse format=nv12 width=1280 height=720 framerate=30 ! vaapih264enc ! filesink location=sample.264 vaapiencode (precisely gst_vaapi_plugin_base_get_input_buffer() ) is not receiving buffers from the pre-allocated pool, so it end up with an extra copy and attach vaapivideometa. It would be good to investigate it since it may significantly affect the performance.
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 ?
(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?
Since it is not a practical use case, I lowered the priority. But I think it is good to have a "videofilesrc" (do we have something like that already?) for zero copy testing purpose , may in in gst-plugins-bad.
(In reply to sreerenj from comment #3) > But I think it is good to have a "videofilesrc" (do we have something like > that already?) for zero copy testing purpose , may in in gst-plugins-bad. I don't think so. fakevideosink would similarly be useful (a sink that advertsize support for GstVideoMeta and any caps feature, avoiding upstream copies)
I think lower copy for you use case would be obtained adding rawvideosrc element (a rawvideoparse but exposed as a src).
(In reply to Nicolas Dufresne (stormer) from comment #5) > I think lower copy for you use case would be obtained adding rawvideosrc > element (a rawvideoparse but exposed as a src) I hope you agree with adding a rawvideosrc and rawvideosink to gst-plugins-bad/gst/debugutils. If so I can change the bug description and assign to gst-plugins-bad.
(In reply to sreerenj from comment #6) > I hope you agree with adding a rawvideosrc and rawvideosink to > gst-plugins-bad/gst/debugutils. If so I can change the bug description and > assign to gst-plugins-bad. Feel free do to so.
Quick implementation (copy&paste of filesrc mostly) of rawvideosrc written for a customer in order to do the benchmarking. https://github.com/sreerenjb/gst-rawvideosrc Need more fixes in order to make it upstreamable, eg: properties need to be added similar to rawvideoparse(format, width, height, strides, use-sink-caps etc..).
moving to gst-plugins-bad because these elements shall be added there.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/541.