GNOME Bugzilla – Bug 708668
context: Potential regression
Last modified: 2013-09-24 14:58:06 UTC
Created attachment 255615 [details] [review] Patch to fakesink to show the issue Since the refactoring of GstContext I am no longer able to get a shared context for an element that is used twice in a pipeline. I used the documentation and eglglessink as my reference for implementing the GstContext logic. As the code was tied to a hardware decoder, I have ported the GstContext code to fakesink to show the problem. Using the old API a single ExampleMgr instance was created, but using the new API each element is creating its own instance. There is some gst-indent spam in the patch, but as the patch is only to explain the issue, hopefully that won't count against me :)
Thanks, unfortunately I can confirm this here with your patch :)
I'll put something like your test into the testsuite. Thanks commit ccfca8f66f33bc2d571348ad8cbbe15aba7f6130 Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Tue Sep 24 12:46:52 2013 +0200 bin: Make sure to cache context types that we did not store yet https://bugzilla.gnome.org/show_bug.cgi?id=708668 commit cac572ec5de99dde5f60927840097ac94452e0e6 Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Tue Sep 24 12:47:26 2013 +0200 playbin: Make sure to cache context types we did not store yet https://bugzilla.gnome.org/show_bug.cgi?id=708668
Thanks Sebastian I can confirm that this fixes the problem for me. With minutes to spare before the 1.2 release! Should I be worrying about the message from gst-launch? Got context from element 'fakesink1': gst.example.ExampleMgr=context, ExampleMgr=(GstExampleMgr)NULL; I know the value is not null.
That's just because there is nothing to serialize it to a real value :) Nothing to worry about