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...
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
