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 752442 - gtksink: Display once black frame when caps changes
gtksink: Display once black frame when caps changes
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.5.90
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 752441
Blocks:
 
 
Reported: 2015-07-15 21:10 UTC by Nicolas Dufresne (ndufresne)
Modified: 2015-08-16 13:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicolas Dufresne (ndufresne) 2015-07-15 21:10:23 UTC
Both gtksink and gtkglsink displays a black frame when caps changes. The problem is that set_caps() is not asynchonous as it should. It drops the pending frame, without cancelling the redraw. That leads to a black frame being shown. This drop of frame is systematic since set caps is called immediately after the last show frame. I suggest to fix bug 752441 first, as this would lead to yet more copy paste.
Comment 1 Matthew Waters (ystreet00) 2015-07-16 04:42:05 UTC
We could make the widget_set_buffer() be widget_set_sample() instead and provide the caps in band with the buffer instead as a GstSample.
Comment 2 Matthew Waters (ystreet00) 2015-07-16 04:50:54 UTC
But that would require parsing caps every frame.  Probably better just to track it in the sink and only widget_set_caps() on different caps in sink_show_frame().

The _queue_resize() should also disappear from sink_get_caps() as that will also perform a redraw.
Comment 3 Tim-Philipp Müller 2015-07-16 07:56:20 UTC
> But that would require parsing caps every frame.

Would it? Should just be a pointer comparison in the nothing-has-changed case, no?
Comment 4 Nicolas Dufresne (ndufresne) 2015-07-16 12:37:01 UTC
It does not have to be that complex. I'll pass the format information through the resize idle (not sure if we should give that a better name) and only do the reset() and v_info update there. This way it will be done after any pending draw message. This should prevent systematically loosing a frame. Remains to handle the case where resize we have draw, resize already queued while the next frame arrive (the case where the resize took too long). We'll need a condition to detect that, in that case, I'm remove the the draw idle and queue it again, so it is places after in the queue.
Comment 5 Nicolas Dufresne (ndufresne) 2015-07-16 12:40:12 UTC
Actually that is still racy, but I'll work on that. I already have a pseudo base class for the widget, so I won't have to do it twice.
Comment 6 Nicolas Dufresne (ndufresne) 2015-07-17 20:19:24 UTC
I've attached the patches to the wrong bug, sorry.

Attachment 307638 [details] pushed as d0fd6a0 - gtkgstbasewidget: Pass already parsed VideoInfo
Attachment 307639 [details] pushed as 410ffd5 - gtkgstbasewidget: Fix black frame on resize
Attachment 307640 [details] pushed as 5e87b9f - gtkglsink: Don't leak vertex array and buffers