[gst-devel] controlling framerate for custom src plugin

[Roland Hermans]

>> 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.

Thanks for your clarifications.

I decided to just reimplemented the element - this time based on
multifilesrc - and now the framerate issue is solved :-). However the code
still does need some cleanup as it was a quick hack to get things working.

Once the code is cleaned up it might be useful for other gstreamer users
as well, even though the target audience is probably pretty limited as it
depends on specific hardware (Intellinet IP camera). Would you suggest
filing a bug report containing a patch, or is the plugin most likely too
specific to be of general use?

Best regards,
Roland