[gst-devel] video playback fast (record with v4l2src)

[Sébastien Moutte]

Hi !
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 
audio synchronized.

Sebastien

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
>> http://webcvs.freedesktop.org/gstreamer/gst-plugins-bad/sys/v4l2/v4l2src_calls.c?view=markup
>>
>> btw: I have two webcams here, just one those drivers implements
>> VIDIOC_G_PARM
>>     
>
> 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
> ioctl).
>
>   
>> 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[12], (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.
>
> Ronald
>
> -------------------------------------------------------------------------
> 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
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>