GNOME Bugzilla – Bug 766611
gl: buffer pool configuration error with caopengllayersink
Last modified: 2016-06-09 06:34:55 UTC
Created attachment 328142 [details] gl*:6 logs In our OSX application that uses caopengllayersink, we are encountering the following issue using a recent build from the 1.8 branch: 04:04:48:212: 0x101ed6450 WARN basetransform gstbasetransform.c:965:gboolean gst_base_transform_default_decide_allocation(GstBaseTransform *, GstQuery *):<glcolorconvertelement0> error: Failed to configure the buffer pool 04:04:48:212: 0x101ed6450 WARN basetransform gstbasetransform.c:965:gboolean gst_base_transform_default_decide_allocation(GstBaseTransform *, GstQuery *):<glcolorconvertelement0> error: Configuration is most likely invalid, please report this issue. I am attaching a debug log with gl*:6, and a pipeline graph that was taken at the time of the reported error (the log contains some other stuff in the beginning, please just ignore it).
Created attachment 328143 [details] pipeline graph at time of error-event
FWIW, the error does not seem to occur on GIT master, although there we only get flickering green displayed on the CA GL sink (not sure if related).
I forgot to mention that our application works using 1.8.1, so it must be some regression between 1.8.1 and the current 1.8 branch.
I suspect dd1529e3f3fac2a3a11e38f85ca577f114dae163 in -bad may have caused this. Although glcolorconvert failing isn't a great side effect. Could you get a *:6 log of this failure? The gl*:6 doesn't have enough information for this.
Created attachment 328178 [details] *:6 debug logs
Created attachment 328179 [details] pipeline graph at time of error-event
12:49:10:359: 0x102a88370 DEBUG caopengllayersink caopengllayersink.m:796:gst_ca_opengl_layer_sink_propose_allocation:<sink> check existing pool caps 12:49:10:359: 0x102a88370 DEBUG GST_PADS gstpad.c:3927:gboolean gst_pad_query(GstPad *, GstQuery *):<sink:sink> sent query 0x101e734a0 (allocation), resu lt 1 12:49:10:359: 0x102a88370 DEBUG GST_PADS gstpad.c:3927:gboolean gst_pad_query(GstPad *, GstQuery *):<glcolorbalance0:sink> sent query 0x101e734a0 (alloca tion), result 1 12:49:10:359: 0x102a88370 DEBUG basetransform gstbasetransform.c:1010:gboolean gst_base_transform_do_bufferpool(GstBaseTransform *, GstCaps *):<glcolorconvert element0> calling decide_allocation 12:49:10:359: 0x102a88370 LOG basetransform gstbasetransform.c:882:gboolean gst_base_transform_default_decide_allocation(GstBaseTransform *, GstQuery *):<gl colorconvertelement0> filter_meta for api GstGLSyncMetaAPI returned: keep 12:49:10:359: 0x102a88370 INFO bufferpool gstbufferpool.c:685:gboolean gst_buffer_pool_set_config(GstBufferPool *, GstStructure *):<glbufferpool0> can't change config, we are active 12:49:10:359: 0x102a88370 INFO bufferpool gstbufferpool.c:685:gboolean gst_buffer_pool_set_config(GstBufferPool *, GstStructure *):<glbufferpool0> can't change config, we are active 12:49:10:359: 0x102a88370 WARN basetransform gstbasetransform.c:965:gboolean gst_base_transform_default_decide_allocation(GstBaseTransform *, GstQuery *):<glcolorconvertelement0> error: Failed to configure the buffer pool 12:49:10:359: 0x102a88370 WARN basetransform gstbasetransform.c:965:gboolean gst_base_transform_default_decide_allocation(GstBaseTransform *, GstQuery *):<glcolorconvertelement0> error: Configuration is most likely invalid, please report this issue. So, the problem is that caopengllayersink proposes an already running pool which is not valid usage anymore. Taking the propose_allocation () code from glimagesink (which has been changed for this issue) will make it work. I won't have my mac available for another week.
Created attachment 328277 [details] [review] Here's a completely untested (not even built) patch that should address this issue. I had completly forgotten about this one. Please give it a try as I can't. caopengllayersink: Don't cache buffer pool Pools cannot be used by the two elements at the same time.
Thanks, I can test this in the course of this week and will report back.
I just tried the patch, I don't get an error now, but the displayed buffers are corrupt (one or two valid frames, then green+some artefacts, then solid green). I also found out more: The error we saw before (the pool error) and after the patch (the green buffers), only occurs when using vtdec_hw. When usinv avdec_h264, it always works. Also, it looks like this commit... commit dd1529e3f3fac2a3a11e38f85ca577f114dae163 Author: Alessandro Decina <alessandro.d@gmail.com> Date: Wed May 4 11:30:11 2016 +1000 applemedia: vtdec: output sysmem by default ... actually unveiled the error. Reverting this commit makes everything work, for both before/after Nicolas' patch. I presume the GL buffer type somehow work around the normal pool handling? I'll attach a new pipeline graph and *:6 log.
Created attachment 328428 [details] *:6 debug logs
Created attachment 328429 [details] pipeline graph while running
We should probably merge my patch then, as it does fix the error. What's wrong with vtdec these days ? It's coming out as non-working quite often. Was there some regression in the RECTANGLE texture handling ?
Rectangle textures aren't used on OS X anymore (and it appears they cannot be used with GL3), instead it's IOSurface's now.
Small correction, rectangle textures can be used with GL3, just not the texture cache thingy we were using before with vtdec and avfvideosrc that's still used on iOS as IOSurface is not public there (yet?).
Nicolas, your patch does indeed remove the ERROR message about the pooling, but I don't know whether the remaining corrupt frames are solely due to vtdec's misbehaviour or some issues with your patch. Note that without your patch, and with reverting dd1529e3f3fac2a3a11e38f85ca577f114dae163, usage of avdec_h264 and vtdec was both correct. I am happy to further test and look into this, but I'll need some guidance. If it's an issue with vtdec, then it should be able to reconstruct the issue using a gst-launch line with glimagesink. I haven't been able to reconstruct it that way, but I am looking at it.
The reason I encourage merging this patch is that if you offer the same pool twice in propose allocation you are doing it wrong. At some point it will stop working, and the error is not obvious in general. If it's not merged within this pass, then please file a separate bug and re-attach it. If you need a test case to triggers issue without vtdec, I can help with that. When you revert dd1529e3f3fac2a3a11e38f85ca577f114dae163, that means you endup with GLMemory with RECTANGLE type of textures (it only hides the sysmem path fro IOSurface being broken really). Clearly that mechanism do work somehow, I'm surprised that we disable it. Doesn't it also mean that vtdec zero-copy is gone ? So, isn't the bug the mapping IOSurface does not work as expected ? Or that IOSurface life-time is wrongly managed ? Maybe it isn't using the new parent buffer mechanism ?
So how about we get this patch in (it's apparently correct) and keep this bug open for the remaining issues? :)
Review of attachment 328277 [details] [review]: With the comment below, lgtm. ::: ext/gl/caopengllayersink.m @@ -250,3 @@ ca_sink->display = NULL; ca_sink->keep_aspect_ratio = TRUE; - ca_sink->pool = NULL; Should also remove the pool member variable from the struct in the header.
Created attachment 328519 [details] [review] caopengllayersink: Don't cache buffer pool Pools cannot be used by the two elements at the same time.
Comment on attachment 328519 [details] [review] caopengllayersink: Don't cache buffer pool Attachment 328519 [details] pushed as 203e893 - caopengllayersink: Don't cache buffer pool
Pretty sure the following commit (in master and 1.8) fixes the green frames issue. Can you please test again? commit 4a83686a57818e182672b25e5040ea5ba0141f03 Author: Alessandro Decina <alessandro.d@gmail.com> Date: Thu Jun 2 13:10:51 2016 +1000 vtdec: fix switching from GLMemory to Sysmem When renegotiating from GLMemory to Sysmem do teardown the texture_cache. Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=766190
Thanks, this is what I found out: - I still get one/two corrupt frames at the beginning of playback (see http://bit.ly/1XwimZk) - Then it plays back correctly without any problems I am also wondering why our pipeline shouldn't negotiate vtdec_hw to output GL buffers anymore (due to dd1529e3f3fac2a3a11e38f85ca577f114dae163). Doesn't that make the any regular playback pipeline on OSX less efficient (e.g. using gst-player)?
It should negotiate GL with playbin, also from the beginning. That would have to be fixed then
In your video it looks like the corrupted frame is the same as the preroll frame... but the preroll frame is shown correctly.
Also, using GL (by reverting dd1529e3 on top of all other patches here), doesn't show any corruptions.
The two new patches ... commit 37e41c9c3a289d0df1bd24617888e2158f3cc96c Author: Alessandro Decina <alessandro.d@gmail.com> Date: Tue Jun 7 17:22:01 2016 +1000 vtdec: always drain in ::negotiate commit 4514d42be08b4e426200b4a30f0ff5905842b2bc Author: Alessandro Decina <alessandro.d@gmail.com> Date: Tue Jun 7 16:00:01 2016 +1000 vtdec: try to preserve downstream caps order ... now fix all issues for me. By default, we are now getting a full GL pipeline, as we should and did previously. If I force use of sysmem, I also don't get corrupt frames anymore. I have noticed, though, that Nicolas' patch (caopengllayersink: Don't cache buffer pool) was only applied to master, but didn't make it to 1.8 yet. All my tests were conducted on 1.8 with Nicolas' patch applied manually on top of upstream 1.8. Thanks for making this all work again :)
Nicolas' patch is also in 1.8 now
Let's declare this closed for now, there's still some weird renegotiation going on though