Hello Justin,
Wednesday, June 06, 2001, 7:12:18 AM, you wrote:
JS> CSYNCing frames as soon as possible, and timestamping them,
JS> then copying them into a userspace buffer - which is a hideous waste of
JS> processing power.
According to my measurements, 3-5% of CPU with Celeron 700, 640x480,
16-bit, 25 fps. I wouldn't call it _hideous_...
JS> Yes, but this won't cope with transient latencies. If the capture
JS> thread doesn't get run for a couple of hundred milliseconds, you can
JS> develop quite a skew in the timestamp
You can detect a hole in timestamps and copy the same frame several
times to compensate it.
JS> - that is why I though of using
JS> "shallow" kernel buffers, and a deep userspace buffer. But all of this
JS> is pointless (and there just is not 1 completely functional solution).
JS> The current bttv 0.7.x implementation is timestamping the buffer - why
JS> don't we just add enhanced CSYNC capabilities to get this timestamp back
JS> to the user?
JS> Something like:
JS> struct video_timedbuffer {
JS> int index;
JS> unsigned long long timestamp;
JS> // possibly sequence numbers/buffer size/ other usefull information
JS> int reserved[8]; // for everything we forgot the first time round...
JS> }
JS> And an ioctl VIDIOCSYNC_TIMED which takes a struct video_timedbuffer as
JS> an argument, and will sync the buffer with index "index", and then fill
JS> in the rest of the information.
JS> Or, maybe piggyback it on VIDIOCSYNC, using a negative index to trigger
JS> the extra capabilities (which is nice, as drivers that do not support it
JS> will simply return -EINVAL at this point, and we can fall back to the
JS> traditional interface.
JS> -justin
--
Best regards,
Eugene
mailto:divx@xxxxxxx or sparky@xxxxxxxxxxxxxxx
[Team GADGET] [Team Two Divided By Zero]
NetZero Platinum
No Banner Ads and Unlimited Access
Sign Up Today - Only $9.95 per month!
http://www.netzero.net
