On Mon, 14 Nov 2005 12:51, Danny Pansters wrote: > I myself am not really doing anything with capturing, but some ideas that > may be helpful: > > FWIW, from what I know in ring capture mode the video gets synch'd by the > audio by having enough frames per audio sample. So if audio sample size or > expected speed or expected kHz is somehow wrong...
Hmm.. Certainly worth instrumenting.. Although wading through the mplayer source is always an 'interesting' experience :) > Also the code for ring capture mode (as opposed to immediate which does not > do audio but does give a video one could capture at 25 fps) has its own > timing (perhaps it uses rtc down the line, I dunno, is rtc.ko alright?). > You may get into a worst-worst-worst-even worst scenario where the software > timer degrades on and on possibly. FreeBSD doesn't have rtc.ko.. Mine doesn't anyway :) I'm not sure how mplayer in FreeBSD stamps frames either. > Maybe capturing only works well if you use immediate (case 2 in bktr(4) > IIRC) and you should capture audio seperately and later merge them to > frames. Hmm, well in any capture you're going to have to worry about clock drift (between the sound card and the bktr card) and dropped frames. > > > > I don't use either of those, but a small program I wrote which > > > > captures YUV frames and uses the Xv extension doesn't show the > > > > problem. > > Capturing only pictures at 25 fps (with mplayer vo) can be handled easily. Hmm OK. So much to learn! :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
pgpTEXoU6aqIV.pgp
Description: PGP signature
