GNOME Bugzilla – Bug 703730
osxvideosink starts to display video too early
Last modified: 2014-11-27 09:53:28 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).
Is this a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=703998 ?
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.
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.
Created attachment 249303 [details] [review] Window initialization moved to set_caps() handler
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 :)
Review of attachment 249303 [details] [review]: ::: sys/osxvideo/nssinkobject.m @@ +41,3 @@ NSThread *ns_app_thread; #else +// NSApplicatio What's this? :)
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.
No, let's just get it done all together :)
Any update on this ?
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
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.
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 :)
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 :)