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 703730 - osxvideosink starts to display video too early
osxvideosink starts to display video too early
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.31
Other Mac OS
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 704340
Blocks:
 
 
Reported: 2013-07-07 10:30 UTC by Alexey Chernov
Modified: 2014-11-27 09:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Window initialization moved to set_caps() handler (5.05 KB, patch)
2013-07-16 17:22 UTC, Alexey Chernov
needs-work Details | Review

Description Alexey Chernov 2013-07-07 10:30:13 UTC
Osxvideosink initializes a window (view) for displaying a video on very early stages (on changing state READY->PAUSED) when video caps aren't available yet. As a result the window is initialized with hardcoded values of 320x240 and has a green solid background for a half of a second until caps are actually received and it gets initialized properly.

I think it's better to move window initialization code to *_set_caps handler where all the information is already available and video isn't streamed yet (In xvimagesink it's implemented this way either).
Comment 1 Andoni Morales 2013-07-11 17:52:34 UTC
Is this a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=703998 ?
Comment 2 Alexey Chernov 2013-07-11 20:30:13 UTC
Not really, this bug just makes bug #703998 to reproduce in more stable way. I didn't manage to find all the causes why 'empty' frame data is being displayed to some time, but this bug is one of them. I hope to prepare a patch for it tomorrow.
Comment 3 Alexey Chernov 2013-07-16 17:22:09 UTC
I'm so sorry for delay, merging changes took some more than planned. Here's a patch on the problem. It is created against git with patches of bug #704340 applied.
Comment 4 Alexey Chernov 2013-07-16 17:22:48 UTC
Created attachment 249303 [details] [review]
Window initialization moved to set_caps() handler
Comment 5 Sebastian Dröge (slomo) 2013-07-17 08:39:30 UTC
This does not apply to latest GIT master, does it depend on the other patches in bug #704340? Otherwise please rebase it to latest GIT master


It's the correct way of solving this btw :)
Comment 6 Sebastian Dröge (slomo) 2013-07-17 08:41:29 UTC
Review of attachment 249303 [details] [review]:

::: sys/osxvideo/nssinkobject.m
@@ +41,3 @@
   NSThread *ns_app_thread;
 #else
+//  NSApplicatio

What's this? :)
Comment 7 Alexey Chernov 2013-07-17 09:04:34 UTC
Oh, sorry :) It's kind of sign of previous experiments leaked to final patch, sorry.

Didn't created a patch against current git master as it blocks an application in case of RUN_NS_APP_THREAD is not defined (was discussed in bug #689730) if applied without fixes from #704340. So I considered it dangerous without these fixes.

But I can prepare a version against current git master, if it's necessary.
Comment 8 Sebastian Dröge (slomo) 2013-07-17 10:19:43 UTC
No, let's just get it done all together :)
Comment 9 Matthieu Bouron 2013-10-31 17:10:10 UTC
Any update on this ?
Comment 10 Tim-Philipp Müller 2014-11-27 00:57:51 UTC
Is this still a problem with current 1.x ?

There were some commits which look possibly related:

commit d57ef52cadd51643dfc812779dac444bf3d9eaae
Author: Andoni Morales Alastruey <ylatuya@gmail.com>
Date:   Tue Jul 9 15:34:04 2013 +0200

    osxvideosink: defer the window handle setup to the main thread

commit 34a5b93637c40b782ab7a768c31e84ed1737981c
Author: Andoni Morales Alastruey <ylatuya@gmail.com>
Date:   Tue Jul 9 15:33:18 2013 +0200

    osxvideosink: default to the main in case we are not setup yet
Comment 11 Alexey Chernov 2014-11-27 07:23:40 UTC
Unfortunately, I can't check it with recent versions as I don't have access to OS X machine anymore, but IIRC it was apparently fixed after some of 1.2.x releases.
Comment 12 Tim-Philipp Müller 2014-11-27 09:22:28 UTC
Thanks for the follow-up. I'm guessing this also means you're not going to be able to update the patch any time soon :)  I'd say let's close this then, and if it's still an issue someone will surely file a new bug sooner or later :)
Comment 13 Alexey Chernov 2014-11-27 09:53:28 UTC
Yes, I think that's right. Especially given that there were some bigger problems in osxvideosink which AFAIK were going to be fixed in gl sink with 1.4 release. So, thanks for resolving it :)