On Monday 18 June 2001 12:32, Eugene Kuznetsov wrote: > Hello Justin, > > Monday, June 18, 2001, 1:40:38 AM, you wrote: > > I'm sorry for bugging you with problems in areas which you probably > even didn't test yourself, but anyway. No problem - bug reports just make better programs! > 1. v4l1 core has a fall-through in setting capture colorspace switch() > which causes DIVXRec to encore streams with completely wrong picture. This should not be possible: There is a switch a little higher up which tests the same variable, and defaults to an error exit... Please let me know how this problem manifests itself (how to duplicate it too!) and I will have a look. > 2. Something is broken on deeper level. When capturing with > bttv 0.8.16 and default module settings, resulting clip looks > jerky because each two consecutive frames are pixel-by-pixel the same. > If I insert module with 'gbuffers=32' option, I receive a slide show - > a picture changes with frequency of ~1 second. OK - poor documentation on my behalf. Right at the bottom of README it says, use "-N 32" if you are using bttv with 32 buffers (otherwise it falls back to copying). ... DOH! Looking through, I see a minor(major) typo: In v4l1_core.c, the line that reads: memcpy((vct->vbufs + vct->sync)->mem, vct->mmbuf + vct->vmb.offs ets[i], vct->framesize); should read: memcpy((vct->vbufs + vct->sync)->mem, vct->mmbuf + vct->vmb.offs ets[frame], vct->framesize); Otherwise you always get frame 0 data. Sorry - I haven't tested v4l1 extensively... Thanks for all the bug detection work (and sorry for the stoopid mistakes!) -justin PS: I don't suppose you know how to set the search vector range for DivX encoding? The Windoze utils allow you to do it, but I can't figure it out under Linux...
