[gstreamer-bugs] [Bug 627229] fpsdisplaysink should not measure fps relative to pipeline clock

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=627229
  GStreamer | gst-plugins-bad | git

--- Comment #6 from Rob Clark <rob at ti.com> 2010-08-18 13:23:31 UTC ---
(In reply to comment #2)
> Review of attachment 168169 [details]:
> 
> ::: gst/debugutils/fpsdisplaysink.c
> @@ +225,3 @@
> +        self->last_ts = self->start_ts = gst_util_get_timestamp();
> +        self->timeout_id =
> +            g_timeout_add (self->fps_update_interval, display_current_fps,
> 
> Hmm, actually the g_timeout_add() is a problem. It adds a g_main_loop()
> dependency :/. But it was there before.
> 
> @@ +331,3 @@
> +
> +  frames_rendered = g_atomic_int_get (&self->frames_rendered);
> +  frames_dropped = g_atomic_int_get (&self->frames_dropped);
> 
> If we want ultimate consistency we would need a lock instead of the atomics.
> Theoretically we can read the first var and then it changes before we read the
> 2nd. Would that be bad?


fwiw, I don't think it would be bad if there was a context switch between
reading those two values.  I guess for either value, only one or the other
would be incremented at each QOS event.  So essentially it would be as if the
timer ran either before or after the QOS event.  It isn't even so much about
race conditions.. the main thing is to assure that a sufficient memory barrier
instruction happens so that if other thread is running on different processor,
it has a chance to see the updated value at all.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.