Hello Justin,
Monday, June 18, 2001, 4:15:07 AM, you wrote:
>> 1. v4l1 core has a fall-through in setting capture colorspace switch()
>> which causes DIVXRec to encore streams with completely wrong picture.
JS> This should not be possible: There is a switch a little higher up which
JS> tests the same variable, and defaults to an error exit... Please let me know
JS> how this problem manifests itself (how to duplicate it too!) and I will have
JS> a look.
Here is the defective switch:
switch(pfmt) {
case NV_YUV420:
(vct->vbufs + vct->nbufs)->buf[1] =
(vct->vbufs + vct->nbufs)->buf[0] +
vct->width * vct->height;
(vct->vbufs + vct->nbufs)->buf[2] =
(vct->vbufs + vct->nbufs)->buf[1] +
(vct->width * vct->height) / 4;
break;
case NV_RGB24:
for(j = 1; j < vct->height; j++) {
(vct->vbufs + vct->nbufs)->buf[j] =
(vct->vbufs + vct->nbufs)->buf[j - 1]
+ vct->width * 3;
}
// break; <<< This line is missing!
case NV_YUV422:
for(j = 1; j < vct->height; j++) {
(vct->vbufs + vct->nbufs)->buf[j] =
(vct->vbufs + vct->nbufs)->buf[j - 1]
+ vct->width * 2;
}
break;
And here is how it looks without break:
http://divx.euro.ru/bug.htm
Web site is crawling, but I don't have any better place to put it at
the moment ...
>> 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.
JS> OK - poor documentation on my behalf. Right at the bottom of README it says,
JS> use "-N 32" if you are using bttv with 32 buffers (otherwise it falls back to
JS> copying).
JS> ...
JS> DOH! Looking through, I see a minor(major) typo: In v4l1_core.c, the line
JS> that reads:
memcpy((vct->>vbufs + vct->sync)->mem, vct->mmbuf + vct->vmb.offs
ets[i], vct->>framesize);
JS> should read:
memcpy((vct->>vbufs + vct->sync)->mem, vct->mmbuf + vct->vmb.offs
ets[frame], vct->>framesize);
JS> Otherwise you always get frame 0 data. Sorry - I haven't tested v4l1
JS> extensively...
Now it works as it should. I haven't tested it with long captures yet.
JS> PS: I don't suppose you know how to set the search vector range for DivX
JS> encoding? The Windoze utils allow you to do it, but I can't figure it out
JS> under Linux...
As far as I know, search vector range in DivX 3.11 is fixed to +/- 16
pixels and there's no way to change it. What Windoze utils you are
talking about?
--
Best regards,
Eugene
mailto:divx@xxxxxxx or sparky@xxxxxxxxxxxxxxx
[Team GADGET] [Team Two Divided By Zero]
