[Bug 747352] applemedia: texture cache negotiation doesn't work

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=747352

--- Comment #13 from Ilya Konstantinov <ilya.konstantinov at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #12)
> > I couldn't test the NV12 patch since glimagesink doesn't accept NV12 over
> > GLMemory. Any idea how I can test it?
> 
> glupload or glcolorconvert handle NV12 (unless broken)

static GstCaps *
gst_glimage_sink_get_caps (GstBaseSink * bsink, GstCaps * filter)
{
  GstCaps *tmp = NULL;
...
  tmp = gst_caps_from_string ("video/x-raw(memory:GLMemory),format=RGBA");

Hmm. Could this be related?

> (In reply to Ilya Konstantinov from comment #7)
> > Created attachment 300967 [details] [review] [review]
> > glimagesink: Don't keep next_buffer after drawing
> > 
> > SMALL PATCH for simplifying our already-confusing buffer refcount:
> > 
> > next_buffer should be alive between prepare and show_frame.
> > For keeping a stationary frame, we have aptly named named stored_buffer.
> 
> The reason for this is that we want to keep around the buffer until we draw
> the next one. IIRC it's not guaranteed that after glTexImage2D() or similar
> everything is done, and we can't safely unref/destroy/reuse the memory yet.

Yes, we still keep it -- it's called "stored_buffer". It's what we draw, and
what we'll keep drawing until we get another buffer.

I thought "next_buffer" is supposed to be only alive between prepare and
show_frame.

Before this patch, we ref the same buffer twice -- in 1) stored_buffer, and 2)
next_buffer, and this is just confusing.

> (In reply to Ilya Konstantinov from comment #6)
> > NOTE: Xcode's OpenGL ES Analysis instrument shows further issues:
> > 
... 
> Does it also tell you where?

It pinpoints the exact GL calls, so you could grep and figure it out. I don't
think it pinpoints lines of code, but I'll snoop some more.

> >   if (glimage_sink->context->gl_vtable->FenceSync)
> >     gst_query_add_allocation_meta (query, GST_GL_SYNC_META_API_TYPE, 0);
> 
> I think so. Someone should really review all that negotiation code, it seems
> a bit half-refactored :)

I think Matthew Waters can answer best.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.