[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-video
Subject: Re[2]: [V4L] Re: New capture core - testers/developers wanted!
From: Eugene Kuznetsov <divx () euro ! ru>
Date: 2001-06-07 8:37:40
[Download RAW message or body]
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@euro.ru or sparky@projectmayo.com
[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
_______________________________________________
Video4linux-list mailing list
Video4linux-list@redhat.com
https://listman.redhat.com/mailman/listinfo/video4linux-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic