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%. Well, on my Athlon 600, 768x576@25fps averages around 70-80%. But still, why waste time copying blocks of data around memory when the 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. This is what I have done at the moment. The problem comes when the CSYNC thread is catching up from a latency. For example, the timestamps (assuming 1 sec/frame for simplicity) will look as follows: 0 1 2 Latency here... next frame is SYNCed and timestamped after latency. 5 (due at 3) 5.1 (due at 4) 5.2 (due at 5) 6 (due at 6 - correct) 7 My current algorithm will duplicate frame 2 until the frame timestamped as 5 (but actually 3) arrives, then send this frame through. The next two will be dropped, because they register as out of sequence (their timestamps are effectively the same as the last frame transmitted). So, even although all the frames were captured, two are dropped and one is sent three times... You will need some fairly complex heuristics to work around this - I don't think I am going to go through the effort, but if anybody else wants to, feel free! Justin
