[Bug 786054] mapping vaapi buffer slow
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Wed Aug 30 12:57:16 UTC 2017
https://bugzilla.gnome.org/show_bug.cgi?id=786054
--- Comment #3 from frank.huber at barco.com ---
Created attachment 358757
--> https://bugzilla.gnome.org/attachment.cgi?id=358757&action=edit
reproducer with time measurement for gst_buffer_map()
Attached is a small reproducer with time measurement, appsink-src.c
Tested with ./repro Highway_1080p60_8M.mp4
Highway_1080p60_8M.mp4 is a HD video with 60 Hz
Printouts are:
./repro Highway_1080p60_8M.mp4
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/va/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
Let's run!
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/va/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/va/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
==> map : average: 2092 us min: 1236 us max: 5076 us <==
==> copy: average: 480 us min: 354 us max: 1747 us <==
==> map : average: 3573 us min: 1236 us max: 5228 us <==
==> copy: average: 504 us min: 348 us max: 1747 us <==
==> map : average: 3843 us min: 1236 us max: 5412 us <==
==> copy: average: 468 us min: 335 us max: 1747 us <==
==> map : average: 3710 us min: 1236 us max: 6291 us <==
==> copy: average: 471 us min: 335 us max: 1747 us <==^C
Why the time need for gst_buffer_map () is so high?
If we start this example multiple times the time for gst_buffer_map() increases
dramatically
The time for memcpy is always lower and does not increase if we start the
example multiple times
In our product we run 16 HD videos with 30 Hz and measure around 16 ms for
gst_buffer_map()
This example started 16 times shows the values below:
only the time for gst_buffer_map (), the time for memcpy is always lower. Only
the last line of all 16 jobs are listed
16 times 1920x1080 at 30Hz
1: average: 3694 us min: 1184 us max: 18074 us
2: average: 2426 us min: 1150 us max: 18953 us
3: average: 2352 us min: 1173 us max: 19834 us
4: average: 3931 us min: 1164 us max: 14376 us
5: average: 3082 us min: 1196 us max: 15445 us
6: average: 2982 us min: 1186 us max: 16830 us
7: average: 2499 us min: 1159 us max: 8703 us
8: average: 3804 us min: 1208 us max: 18760 us
9: average: 3444 us min: 1172 us max: 14467 us
10: average: 3363 us min: 1193 us max: 15844 us
11: average: 4407 us min: 1177 us max: 16361 us
12: average: 4865 us min: 1155 us max: 19826 us
13: average: 3928 us min: 1156 us max: 12244 us
14: average: 3911 us min: 1149 us max: 19119 us
15: average: 4213 us min: 1174 us max: 15549 us
16: average: 3946 us min: 1189 us max: 14073 us
Another observations,
The time for gst_buffer_map() depends on the resolution of the video and it
depends also on the framerate
The values above are measured with sync=FALSE
With sync=TRUE, the values are a bit lower, but IMHO still too high
Play with the sync parameter, FALSE/TRUE in line 245 in appsink-src.c
Maybe we are completely wrong….
Can anybody explain why gst_buffer_map() needs so much time
Thanks.
--
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