[gst-devel] controlling framerate for custom src plugin

[Tim-Philipp Müller]

On Mon, 2009-12-28 at 09:41 +0100, Roland Hermans wrote:

> Sorry if I wasn't clear. It's not the camera that's sending images too
> frequent but it's gstreamer that keeps calling the _create() on my
> ipcamsrc element. The camera will only send an image after receiving and
> image request. I send this image request from within the _create() call,
> receive the JPEG image data and put it in a buffer.

> If I debug the same pipeline with e.g. videotestsrc, I see that
> videotestsrc generates new frames at the requested frame rate (as it
> should). I would like to have the same behavior for my ipcamsrc, i.e.
> _create() is called only when a frame is needed.

videotestsrc will create buffers as fast as possible (see e.g.
videotestsrc ! fakesink), it will however put timestamps on it so that
when the sink syncs against the clock it will display 25 frames per
second  or whatever the framerate is. This will then throttle the source
so that it ends up creating 25 frames per second in the end. (cp.
videotestsrc ! ximagesink  and videotestsrc ! queue ! ximagesink for
example).


> (...) But to check my understanding of how gstreamer works: the src pad
>  of videorate should be emitting frames at exactly the specified
>  framerate, but does it also try to negotiate this framerate on the
>  sink pad of the videorate element?

Sort of. First of all, the framerate field in the caps really does not
matter that much. It's used for negotiation, but what matters in the end
is the timestamps on buffers (and the initial newsegment event).
videorate will re-timestamp/duplicate/drop buffers to match the desired
downstream framerate. It *should* advertise the framerate configured
downstream via caps for upstream negotiation, but that will only be used
by the source if the source looks for it. And in any case it won't
affect/throttle the source *directly* in any way unless the source
configures hardware with the framerate or so. Usually upstream produces
buffers as fast as possible and only the sink(s) sync against the clock,
and this indirectly throttles upstream (once the internal/external
queues are full and block, so that upstream only gets scheduled again
when a buffer is processed downstream and taken out of the queue etc.).
Alternatively, you could try and make your source a live source that
syncs against the clock (and then not make the sinks sync against the
clock with sync=false, or implement latency queries properly), and
schedule buffer production yourself based on the clock, but I'm not sure
that's easier or even more desirable (depends a bit on how it currently
works in practice I guess).

> I also noticed that gst_buffer_set_caps() is called. Is it
> necessary/important that the correct caps are set on the buffer?

Yes, you need to set caps on at least the first buffer. Ideally on all
buffers.

Cheers
 -Tim