[gst-devel] controlling framerate for custom src plugin

[jz]

Hi,

would be nice to have your src. I'am still working on someting similar.
I try to use a Prosilica Gige Camera with gstreamer. 

thx, Johannes

On Mon, 2009-12-28 at 18:52 +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.
> 
> 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
> 
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel