Date: Mon, 7 Nov 2005 01:47:40 -0800 From: Jacob Meuser <jakemsr@jakemsr.com> To: freebsd-multimedia@freebsd.org Subject: Re: Sending DV to camcorder over firewire gives dropouts Message-ID: <20051107094739.GC3893@puff.jakemsr.gom> In-Reply-To: <200511070309.DAA15739@sopwith.solgatos.com> References: <20051106220859.52887.qmail@web30304.mail.mud.yahoo.com> <200511070309.DAA15739@sopwith.solgatos.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 06, 2005 at 07:09:23PM +0000, Dieter wrote: > > > Wild Guess Theory #1: > > > > > > fwcontrol -S reports: > > > > > > 3948 frames, 131.50 secs, 30.02 frames/sec > > > 784 frames, 25.92 secs, 30.24 frames/sec > > > 3597 frames, 119.78 secs, 30.03 frames/sec > > > > > > Shouldn't this be 29.97 fps ? > > > > > I like that theory: > > > > I found in ffmpeg's man page the following option: > > -r fps > > set frame rate (default = 25) > > > > Dude! Did you use the "-r" option? > > No, didn't need to, ffmpeg figured out to use 29.97 fps > all by itself, for both input and output. yes, otherwise it would not be a valid DV file. > Even if there is something wrong with the output of ffmpeg, > it would not explain why I get the exact same problem with: > > [ push "play" button on camcorder ] > fwcontrol -R filename.dv > [ push "stop" button on camcorder ] > fwcontrol -S filename.dv > > since ffmpeg is not involved in this case. > > It might be that the incorrect fps numbers reported are just > an artifact of clock resolution and the relatively short times > involved and packetization/buffering? seems likely, since the reports with more frames are closer to the right rate. -- <jakemsr@jakemsr.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051107094739.GC3893>