[gst-devel] video playback fast (record with v4l2src)
sebastien at moutte.net
Wed Sep 20 10:28:14 CEST 2006
I'm really happy to see that i'm not alone to have this kind of problem
with webcams frame rate :)
I'm currently working on Windows source elements, the audio one is
working fine but there were two weeks that I'm trying to get the real
frame rate from the webcam device.
The directshow API was returning 20 fps while I was really receiving 6
to 15 fps.
I was using a pipeline like gst-launch-0.10 dshowvideosrc !
ffmpegcolorspace ! theoraenc ! oggmux ! filesink
location=c:/capture.ogg, and of course the resulting video was playing
to fast !!
So theora and oggmux seem to take care of the frame rate instead of
using only timestamps.
I've also done some tests with a full directshow graph (pipeline) saving
the raw video in a AVI file and it works well although the frame rate is
variable I'll try to find what is the way used to do it keeping the
Ronald S. Bultje a écrit :
> Hi Edgar,
> On Tue, 19 Sep 2006, Edgard Lima wrote:
>> For v4l2 drivers we can know the framerate using VIDIOC_G_PARM
>> See how it works looking the function gst_v4l2src_get_fps (also copied
>> bellow) at
>> btw: I have two webcams here, just one those drivers implements
> For some purposes, indeed, VIDIOC_G_PARM works fine. However, as you said
> here, and as I know from practice, most webcams don't actually implement
> this. This is because there is no decent way to _set_ the framerate using
> this API. You have to understand that the get-methods are fine for TV
> cards, where the FPS depends on the norm, but not for webcams, where the
> FPS is a separate property and such a thing as norms don't exist.
> Implementing it is thus practically worthless. The pwc driver implements
> the same flag-field-hack that they use in v4l1 also (through a private
>> Do you think those methods aren't enough? I mean, the v4l2 standard
>> should be improved or v4l2 drivers shoould?
> API, I'm afraid, as explained above.
>> ....I'm afraid, does it mean we can't record A/V coming from rtp,
>> v4l, (live)? I think we should think about more robust way to do
>> that (would it be videoscale?).
> Not into AVI, but fortunately, you won't do that anyway. For RTP and live
> recording from v4l, you really want to think this whole system through.
> If you don't understand the responsibilities of each gst element, the
> drivers (API/implementations + issues/bugs) and such, I don't think you'll
> be able to write a solution that works very well. If it just works for pwc
> webcams when transcoding in ogg/rtp using some obscure gst-launch
> commandline, that's really good already, but you're really not there yet,
> you're just at the beginning.
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel