[Bug 720104] videorate: Should be able to duplicate frames in a live stream

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=720104
  GStreamer | gst-plugins-base | unspecified

--- Comment #7 from Andreea Fulger <andreea.fulger at parrot.com> 2014-03-20 14:51:28 UTC ---
(In reply to comment #6)
> Review of attachment 271605 [details]:
> 
> ::: gst/videorate/gstvideorate.c
> @@ +256,3 @@
> +          "Maximum time in number of lost buffers"
> +          " - will be multiplied with the buffer's duration", 0, 10, 0,
> +          G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS | G_PARAM_CONSTRUCT));
> 
> Timeout shall match the expected framerate/frameduration, not a user driven
> input.
> 

By choosing a timeout that matches the expected framerate/ frameduration, if
the upstream buffers do not arrive at regular intervals (e.g. if a decoder
precedes the videorate element) and that the downstream element is able of
buffering some frames, we might insert duplicate frames and drop the real
buffers even though this is not actually necessary. The quality of the stream
will thus be highly degraded.

I was thinking of computing a timeout in such a way that a buffer generated
beyond this time would automatically be considered as too late by the
downstream element (by using the PTS, segment values, the running time of the
pipeline clock etc). Is such a calculus even possible?


> @@ +677,3 @@
> +  /* The waiting time is expressed in microseconds, so we have to divide
> +   * the timeout (expressed in nanoseconds) by 1000 */
> +  end_time = g_get_monotonic_time () + videorate->timeout / 1000;
> 
> You should use the pipeline clock. Also gst_clock_id_wait_async().

I am now using the pipeline clock and I trigger a periodic notification that I
reinit at each buffer reception.

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