Hello Justin, Thursday, June 07, 2001, 1:18:29 AM, you wrote: JS> Eugene Kuznetsov wrote: >> >> 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> Well, on my Athlon 600, 768x576@25fps averages around 70-80%. But JS> still, why waste time copying blocks of data around memory when the JS> hardware is nicely designed to do all of that for you... >> >> 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. JS> This is what I have done at the moment. The problem comes when the JS> CSYNC thread is catching up from a latency. For example, the timestamps JS> (assuming 1 sec/frame for simplicity) will look as follows: JS> 0 JS> 1 JS> 2 JS> Latency here... next frame is SYNCed and timestamped after latency. JS> 5 (due at 3) JS> 5.1 (due at 4) JS> 5.2 (due at 5) JS> 6 (due at 6 - correct) JS> 7 JS> My current algorithm will duplicate frame 2 until the frame timestamped JS> as 5 (but actually 3) arrives, then send this frame through. The next JS> two will be dropped, because they register as out of sequence (their JS> timestamps are effectively the same as the last frame transmitted). JS> So, even although all the frames were captured, two are dropped and one JS> is sent three times... JS> You will need some fairly complex heuristics to work around this - I JS> don't think I am going to go through the effort, but if anybody else JS> wants to, feel free! What if you decrease the sensitivity of dropper? For example, if it starts dropping frames not after 2./framerate, but after, say, 5./framerate. It can potentially introduce sync problems, but they'll be very small - up to 200 ms for framerate=25 ms. -- 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
