[Bug 786054] mapping vaapi buffer slow

[GStreamer (GNOME Bugzilla)]

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.