GNOME Bugzilla – Bug 774370
Regression 1.8.3 -> 1.10.0 w/ GL & context sharing? (tex_id always 0)
Last modified: 2016-11-14 08:56:31 UTC
When trying to use Processing's GLVideo library with version 1.10.0, the same code and example file that worked with version 1.8.3 of GStreamer suddenly fails to display an image. It is unclear why exactly this is happen. The only visible difference to me is that the tex_id field in the GstBuffer that the library code is being passed by GStreamer is suddenly always zero, where previously the texture id was varying, but never zero. I have uploaded a binary build of the GLVideo library for Mac, which includes GStreamer 1.10.0, to this URL: https://sukzessiv.net/~gohai/gstreamer/processing-glvideo-1_10_0.zip To test: * Install Processing from http://processing.org/ * Unzip the library from above in Processing's sketch folder (e.g. ~/Documents/Processing/libraries) * Launch Processing * In Processing: File > Examples... > Contributed Libraries > GL Video > SingleVideo * Press the play button The source code for this build of the library: https://github.com/gohai/processing-glvideo/tree/2820e5f6e83801cb784b0f9385cd37c62743d6f7 When having compiled this library against GStreamer 1.8.3, I am witnessing the following output. Three GST_QUERY_CONTEXT queries, then you'll see the caps retrieved from GST_EVENT_CAPS, and the tex_id values we unpack from the GstBuffer in an callback invoked by the "handoff" signal: gst_gl_handle_context_query returned true gst_gl_handle_context_query returned true gst_gl_handle_context_query returned false Final caps: video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)560, height=(int)406, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30000/1001, texture-target=(string)2D handle_buffer: tex_id 7 handle_buffer: tex_id 7 handle_buffer: tex_id 14 handle_buffer: tex_id 34 handle_buffer: tex_id 7 ... Whereas in GStreamer 1.10.0 the output looks like this: gst_gl_handle_context_query returned true gst_gl_handle_context_query returned true gst_gl_handle_context_query returned false Final caps: video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)560, height=(int)406, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30000/1001, texture-target=(string)2D handle_buffer: tex_id 0 handle_buffer: tex_id 0 handle_buffer: tex_id 0 handle_buffer: tex_id 0 handle_buffer: tex_id 0 (This could of course be just as well a red haring, but something between 1.8.3 and 1.10.0 broke video playback for us.) I am attaching debug outputs at level 5 for both versions below. You'll find the gist of the library code (much modeled after gst-omx's testegl.c) here: https://github.com/gohai/processing-glvideo/blob/2820e5f6e83801cb784b0f9385cd37c62743d6f7/src/native/impl.c
Created attachment 339763 [details] 1.10.0 debug output at level 5 (does not work)
Created attachment 339764 [details] 1.8.3 debug output at level 5 (does not work)
Sorry, typo: the attachment for 1.8.3, just above, _does_ work
Ok, this is weird. Tried with the glvideo download as-is. It failed as described. rebuilt only the native library (modified the makefile to point to the correct java header location: http://stackoverflow.com/questions/20771803/where-can-i-find-the-jni-headers-for-mac-os) and everything worked splendidly. Are you attempting to run a 1.8 built library against a 1.10 installation because currently that won't work due to ABI incompatibilities that you explicitly opt-in to with the #define GST_USE_UNSTABLE_API.
Specifically, https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=c200e47ef85fc68e2acca31173dc2480498dc095 occurred between 1.8 and 1.10 that would cause something like this.
This was indeed the issue. I must have installed gstreamer-1.0-1.10.0-x86_64.pkg over an existing installation, which didn't include the headers. Thanks a lot for catching this. What did you change the Java headers include path to? I thought /System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers was sufficiently portable? Thanks, Matt!
(In reply to gohai from comment #6) > This was indeed the issue. I must have installed > gstreamer-1.0-1.10.0-x86_64.pkg over an existing installation, which didn't > include the headers. Thanks a lot for catching this. No problem! > What did you change the Java headers include path to? I thought > /System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers was > sufficiently portable? I had to change it to "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers" as indicated by the previoulsy linked stackoverflow post (changing macOS versions of course). This is using the Sun/Oracle JDK, not OpenJDK if that matters.