Hello Justin, Thursday, June 07, 2001, 12:12:04 AM, you wrote: JS> Eugene Kuznetsov wrote: >> >> 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> That is quite significant when you realise that the entire QTrec JS> (without buffer copying) would only use around 35% - 40% CPU time. For somebody who's aiming at maximum possible resolution/framerate CPU time will be close to 100%. >> 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> Yes, this is done, but the problem is that when the CSYNC thread catches JS> up, it will timestamp the backlogged frames with nearly identical JS> times. This is possible to fix, but it would require a lot of rules to JS> try to gues the right timestamp. I will say it again - this should be JS> done by the kernel driver - that is the only place the true timestamp is JS> known. Then don't do this in CSYNC thread. What's wrong with the following: 1) CSYNC thread ensures that all frames come in the correct order ( with increasing timestamps ), 2) when main thread sees that timestamp of next frame minus timestamp of last encoded frame is >2./framerate, it writes as many null frames as necessary to get back in sync. BTW I will try v4l-enabled version ASAP.. -- 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
