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 792620 - vaapi: don't reuse buffer pool in propose_allocation
vaapi: don't reuse buffer pool in propose_allocation
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
unspecified
Other All
: Normal normal
: 1.13.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-01-17 21:07 UTC by Víctor Manuel Jáquez Leal
Modified: 2018-01-18 12:37 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
plugins: use g_clear_object() to unref sinkpad_buffer_pool (1.05 KB, patch)
2018-01-17 21:07 UTC, Víctor Manuel Jáquez Leal 		committed Details | Review
plugins: re-using buffer pool breaks renegotiation (1.90 KB, patch)
2018-01-17 21:07 UTC, Víctor Manuel Jáquez Leal 		committed Details | Review

Description Víctor Manuel Jáquez Leal 2018-01-17 21:07:33 UTC 
Don't reuse the buffer pool instantiated in propose_allocation() since it
can break renegotiation
Comment 1 Víctor Manuel Jáquez Leal 2018-01-17 21:07:41 UTC 
Created attachment 366971 [details] [review]
plugins: use g_clear_object() to unref sinkpad_buffer_pool
Comment 2 Víctor Manuel Jáquez Leal 2018-01-17 21:07:50 UTC 
Created attachment 366972 [details] [review]
plugins: re-using buffer pool breaks renegotiation

at propose_allocation() we should not reuse the proposed buffer,
because it could break renegotiation.
Comment 3 Nicolas Dufresne (ndufresne) 2018-01-18 00:15:08 UTC 
Review of attachment 366972 [details] [review]:

Looks good to me, I see it fails if it could not provide a pool, pool is optional there, but I guess its going to fail later anyway if that happens, is that correct ?
Comment 4 Víctor Manuel Jáquez Leal 2018-01-18 09:06:29 UTC 
(In reply to Nicolas Dufresne (stormer) from comment #3)
> Review of attachment 366972 [details] [review] [review]:
> 
> Looks good to me, I see it fails if it could not provide a pool, pool is
> optional there, but I guess its going to fail later anyway if that happens,
> is that correct ?

Yes. Even gst_vaapi_plugin_base_create_pool() will trigger an GST_ELEMENT_ERROR/GST_ERROR_ELEMENT if the pool can't be instantiated. The pool is mandatory for the encoders, postprocessor and sink.
Comment 5 Víctor Manuel Jáquez Leal 2018-01-18 11:48:22 UTC 
Attachment 366971 [details] pushed as 9933dcb - plugins: use g_clear_object() to unref sinkpad_buffer_pool
Attachment 366972 [details] pushed as 6efce29 - plugins: re-using buffer pool breaks renegotiation