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@euro.ru or sparky@projectmayo.com
[Team GADGET]  [Team Two Divided By Zero]




_______________________________________________
Video4linux-list mailing list
Video4linux-list@redhat.com
https://listman.redhat.com/mailman/listinfo/video4linux-list