[Bug 796640] Fix for a synchronization bug in 1.14.1 ext/qt/gstqsgtexture.cc

[GStreamer (GNOME Bugzilla)]

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

--- Comment #9 from jimmy <jipe4153 at gmail.com> ---
(In reply to Jan Schmidt from comment #8)
> (In reply to jimmy from comment #7)
> > (In reply to Jan Schmidt from comment #6)
> > > I've uploaded the patches as 2 separate plain files so they can be more
> > > easily reviewed.
> > > 
> > > 2 comments:
> > > * The git commit summary should be a single line less than 76 characters,
> > > then leave 1 blank line and write any commit log description that needs more
> > > than 76 chars.
> > > * 0001 contains some extra unnecessary white-space changes
> > 
> > Do you need me to submit a new patch with modified git commit summaries?
> 
> That would be great. FYI, many of us use the git-bz tool to help with
> uploading patches to Bugzilla (https://wiki.gnome.org/Git/WorkingWithPatches)

Thanks!
> 
> > > 
> > > Does the mutex actually have any effect, or is the
> > > gst_gl_sync_meta_wait_cpu() call sufficient?
> > 
> > In my testing the gst_gl_sync_meta_wait_cpu call was sufficient (appears to
> > be the same as glFinish()) BUT
> > 
> > From reading the comments it seemed as if the gstreamer thread calls
> > GstQSGTexture::setBuffer while Qt:s render thread calls on
> > GstQSGTexture::bind, this prompted me to add this lock.
> 
> Which comment are you thinking of? If I remember correctly, the setBuffer
> call is made while blocking the Qt render thread, preventing ::bind from
> running simultaneously.

Yes I seem to have misinterpreted the comment, it says that it is indeed
blocking the rendering thread.

Is my understanding correct that this is the call that eventually invokes the
bind() function? : 

// from qtitem.cc:
  gst_buffer_replace (&qt_item->priv->buffer, buffer);
  QMetaObject::invokeMethod(qt_item, "update", Qt::QueuedConnection);
  g_mutex_unlock (&qt_item->priv->lock);

If so, is there really a guarantee that rendering has been invoked by the time
the mutex is unlocked? (note there is also Qt::BlockingQueuedConnection).


> 
> > > 
> > > I gather the bug you're seeing is flashing and out-of-order frames, but how
> > > are you reproducing it? I haven't seen such behaviour with qmlglsink myself.
> > 
> > Yes flashing and out-of-order frames.
> > 
> > The issue is clearly visible on the Tegra X2 platform (most of the time)
> > when running the modified qmlglsink example (moving ball pattern), it is
> > even more obvious when live streaming from a camera. 
> 
> OK. It would be good to mention that it happens on that platform.
You mean in the git commit message or generally when submitting bugs? :)
> 
> > Since this is timing related, it might not be visible or rarely visible on
> > other platforms.
> 
> You're quite right. I tend to test on platforms with shared GPU/CPU system
> memory or simpler GPUs that might not parallelise so much.
> 
> > I could snap a video of the issue with my cell-phone and send to you if you
> > really want to see it.

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