After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769248 - plugins: Update buffer pool size with new va allocator's image
plugins: Update buffer pool size with new va allocator's image
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
git master
Other Linux
: Normal normal
: 1.9.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-07-28 01:23 UTC by Hyunjun Ko
Modified: 2016-10-31 14:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
plugins: update buffer pool size with new allocator's image size (1.84 KB, patch)
2016-07-28 01:25 UTC, Hyunjun Ko
none Details | Review
plugins: update buffer pool size with new allocator's image size (1.31 KB, patch)
2016-07-29 09:08 UTC, Hyunjun Ko
committed Details | Review

Description Hyunjun Ko 2016-07-28 01:23:19 UTC
During test, I found something wrong.

In some media, there happens video size update in allocator_configure_image_info.
And the updated size is used when allocating gst memory.

But bufferpool's each buffer size is already set by caps/query info.
This leads to dismatch between bufferpool's set size and real allocated buffer size.

In this case, it causes every buffer is freed during release in bufferpool,
which should be reused. This would affect performance.
Comment 1 Hyunjun Ko 2016-07-28 01:25:15 UTC
Created attachment 332248 [details] [review]
plugins: update buffer pool size with new allocator's image size

Depends on media, video size is sometimes updated with new allocator.
It leads to dismatch between bufferpool's set size and real allocated buffer size.
 
In this case, it causes every buffer is freed during release in bufferpool,
which should be reused. This kills performance.
Comment 2 Víctor Manuel Jáquez Leal 2016-07-28 13:47:35 UTC
good catch!

Still I think we can do this better. I need the review the format handling again to see if we can ditch the force of nv12 format internally for VA surfaces
Comment 3 Víctor Manuel Jáquez Leal 2016-07-29 08:41:09 UTC
Review of attachment 332248 [details] [review]:

::: gst/vaapi/gstvaapipluginbase.c
@@ +559,3 @@
+    /* Update video size with allocator's image size */
+    size = GST_VIDEO_INFO_SIZE (&GST_VAAPI_VIDEO_ALLOCATOR_CAST
+        (allocator)->image_info);

The thing is that size is a value received as a parameter in gst_vaapi_plugin_base_create_pool(), so the error comes out of the scope of this function, more specifically in gst_vaapi_plugin_base_decide_allocation()
Comment 4 Hyunjun Ko 2016-07-29 09:08:36 UTC
Created attachment 332336 [details] [review]
plugins: update buffer pool size with new allocator's image size

Indeed, victor :)
Comment 5 Víctor Manuel Jáquez Leal 2016-07-29 09:44:39 UTC
Review of attachment 332336 [details] [review]:

::: gst/vaapi/gstvaapipluginbase.c
@@ +836,3 @@
+    /* Update video size with allocator's image size */
+    size = GST_VIDEO_INFO_SIZE (&GST_VAAPI_VIDEO_ALLOCATOR_CAST
+        (plugin->srcpad_allocator)->image_info);

That looks better!

But, now we should remove the previous size calculations in the function, since they will be overiwritten by this one.

And I would add a function in gstvideomemory.{c,h} like gboolean gst_vaapi_video_allocator_get_image_size(GstAllocator * allocator, gsize * size);
Comment 6 Víctor Manuel Jáquez Leal 2016-07-29 13:23:03 UTC
Attachment 332336 [details] pushed as d0ee0b4 - plugins: update buffer pool size with new allocator's image size