GNOME Bugzilla – Bug 762546
Stride information is missing in buffers from vaapipostproc
Last modified: 2018-04-10 13:07:04 UTC
The buffers received from appsink don't have the correct stride information, when this buffer was processed by vaapipostproc. The pipeline looks like this: vaapidecode ! vaapipostproc ! appsink After getting the buffer from appsink I get the information about the video with buffer = gst_sample_get_buffer(_sample); caps = gst_sample_get_caps(_sample); gst_video_frame_map(&frame, &vinfo, buffer, GST_MAP_READ); The strides should be in vinfo.stride[0] vinfo.stride[1] ... But these strides don't match. For BGRx e.g. a line is rounded up to a multiple of 64 pixels, but this is not reflected in the stride.
This is a bit tricky, appsink does not support GstVideoMeta, so upstream element cannot add this meta on the buffers. That should theoretically force upstream element to copy/crop the buffers so they use a default stride. Maybe vaapipostproc does not do. So the proper behaviour here will simply kill the performance for you use case (until someone add a way to support VideoMeta in appsink). The proper fix to vaapipostproc is to copy/crop (gst_video_frame_copy() handles thats) before pushing.
This should be already fixed with the patches merged on bug 785054 This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.