On Wednesday 11 May 2005 23:05, Chris Kennedy wrote:
> It actually makes the multiple buffers work, and seems to be something to
> that at least for the API command.  I can tell that the windows driver uses
> the value 1456 for the API command setting up VBI, which is +12 and that is
> used in calculations I see for the vbi size.  Is this possibly something
> which we need to add 12 to the firmware API setup, and then leave those
> values at the old ones (or maybe even 13, since seems the value is 51 but
> counting from 0 possibly?).  It seems to make the multiple buffers work
> when 64, but not when 51, maybe that's the API allowing that but we just
> need to add 13 to 51 or 1443 for that call.

Well, it might be needed for the API call, but it is also used to tell the 
user the size of an VBI line and that is certainly 1443 for raw (1444 on the 
pvr150). After looking at the code the sliced value might be OK as it isn't 
used in any other calculations.

> > Anyway, I've done some more tests and 0.3.4k crashes for PAL with ivtvctl
> > -w teletext and then trying to read /dev/vbi4. I'm looking into this.

Just might be related to AMD64 issues.

                Hans


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
ivtv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel

Reply via email to