videorate doesn't drop or duplicate frames in live stream?

[gotsring]

Thanks for the suggestion. I messed around with compositor a bit, but I ended
up just adding a probe to the sink pad of the videorate element that
manually added a timestamp to the incoming buffers. Videorate could then
perform as expected because the time information was added (callback code
below).

// Adds a timestamp as frames come in so videorate behaves normally.
GstPadProbeReturn do_timestamp_cb(GstPad * pad, GstPadProbeInfo * info,
gpointer data) {
    GstBuffer* buffer = GST_PAD_PROBE_INFO_BUFFER(info);
    buffer = gst_buffer_make_writeable(buffer);
    buffer->pts = gst_clock_get_time(pipeline_clock); // pipeline_clock from
gst_pipeline_get_pipeline_clock
    GST_PAD_PROBE_INFO_DATA(info) = buffer;
    return GST_PAD_PROBE_OK;
}



Nicolas Dufresne-5 wrote
> videorate does not have a live mode implemented atm. In fact, it does
> not have the needed thread to allow this. So even if you where usinging
> a proper container with timestamp, it would bursts frames on the next
> buffer after the gap.

My main concern with my method is that it assumes the frames come in
synchronously, by which I mean the frames are received and decoded, then
passed to videorate (and thus my timestamp function) with a near-constant
latency. I'm not sure if is necessarily true for most or all GStreamer
pipelines. Is this the thread issue you are describing, or am I missing
something else? 



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/