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 768658 - glcolorconvert: Failed to convert video buffer (osx ).
glcolorconvert: Failed to convert video buffer (osx ).
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.8.2
Other Mac OS
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-07-11 09:52 UTC by Petros
Modified: 2017-05-20 13:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Log output configured with GST_DEBUG=5,*gl*:7 (742.07 KB, application/x-gzip)
2016-07-11 09:52 UTC, Petros
Details
Log output configured with GST_DEBUG=*:7 (1.85 MB, application/x-gzip)
2016-07-11 15:35 UTC, Petros
Details

Description Petros 2016-07-11 09:52:16 UTC
Created attachment 331197 [details]
Log output configured with GST_DEBUG=5,*gl*:7

glcolorconvert fails to convert video buffer on OS X El Capitan 10.11.2.

My pipeline's video branch can be described by the following :

uridecodebin ! queue ! glupload ! glcolorconvert ! appsink

The uridecodebin linking with the rest of the elements happens inside the pad-added callback of uridecodebin.

The pipeline will preroll and go to PLAYING state and I can even render the first textures that arrive but then it throws complaining the the input memory must be GstGLMemory.

Caps are set as video/x-raw(memory:GLMemory) on the appsink and glupload seems to also transfer GLMemory to glvideoconvert so I am not sure where the issue lies..

The same code works on GLX and EGL ( with 1.8.1 -- haven't tried 1.8.2 yet on these platforms. )
Comment 1 Matthew Waters (ystreet00) 2016-07-11 11:11:27 UTC
The buffer that causes that issue is directly from vtdec as glupload is in passthrough and I can track back to gst_video_decoder_clip_and_push_buf(GstVideoDecoder *, GstBuffer
 *):<vtdechw0> pushing buffer 0x7f8f92000280 of size 3110400, PTS 0:00:00.200000000, dur 0:00:00.040000000

1. What's the memory type that is actually passed to glcolorconvert? You can check by breaking on _do_convert_one_view and printing gst_buffer_peek_memory (convert->inbuf, i)->allocator in the debugger for i = {0, 1}.  It is called more than once before the error occurs (4 times before in the log) so you may have to keeping printing until it fails.
2. What are the exact caps you are setting on appsink?
Comment 2 Matthew Waters (ystreet00) 2016-07-11 11:12:21 UTC
Oh and:

3. Can you get a *:7 log as there's some stuff missing to track what exactly happens to the problematic buffer.
Comment 3 Petros 2016-07-11 15:35:00 UTC
Created attachment 331233 [details]
Log output configured with GST_DEBUG=*:7
Comment 4 Petros 2016-07-11 15:35:30 UTC
I m linking against the binary packages. Do these contain debug symbols for the parts under question? lldb was not able to find _do_convert_one_view so I m wondering if I would have to build them manually..??

In the meantime here are the exact caps for the appsink :

"video/x-raw(memory:GLMemory), format=RGBA"

and attached a *:7 log output.
Comment 5 Matthew Waters (ystreet00) 2016-09-27 08:27:19 UTC
You may have to start the application before lldb will find _do_convert_one_view.  I believe the packages contain debug symbols.

You probably want to add the texture-target paramenter to your caps:

i.e. "video/x-raw(memory:GLMemory), format=RGBA, texture-target={2D,rectangle}"

There have also been some commits to master that may have solved this issue.  Could you please test against that?
Comment 6 Matthew Waters (ystreet00) 2017-05-20 13:24:58 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!