From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m3DKOGoF010189 for ; Sun, 13 Apr 2008 16:24:16 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id m3DKNxh8010861 for ; Sun, 13 Apr 2008 16:23:59 -0400 Date: Sun, 13 Apr 2008 17:22:07 -0300 From: Mauro Carvalho Chehab To: Markus Rechberger Message-ID: <20080413172207.4276a17f@areia> In-Reply-To: <93606.67558.qm@web902.biz.mail.mud.yahoo.com> References: <454886.97234.qm@web901.biz.mail.mud.yahoo.com> <93606.67558.qm@web902.biz.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Video Subject: Re: [ANNOUNCE] Videobuf improvements to allow its usage with USB drivers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: video4linux-list-bounces@redhat.com Errors-To: video4linux-list-bounces@redhat.com List-ID: On Sun, 13 Apr 2008 18:17:54 +0200 (CEST) Markus Rechberger wrote: > > Conclusion: > > > The time consumption to receive the stream where reduced from about 33.38 seconds to 0.05 seconds > > the question is moreover what made capture_example go > up to 100% CPU in the first try and to 0% in the > second one. > I'm not sure about the old implementation in the > original driver, although I'm just curious about the > details here. xawtv usually uses very little cputime > at all. > If I use > "$ time mplayer tv:// -tv driver=v4l2" it shows up > > real 0m40.972s > user 0m0.230s > sys 0m0.050s > > your benchmark is a bit unclear. The advantage of using capture_example for benchmark tests is that it is a very simple mmap loop, without multi-thread, and just discarding the return. With this, you're timing just the minimal requirements for receiving frames. A TV application will also need to use the video adapter to present images, and may do some other tasks, like running DSP algorithms for de-interlacing. It may also discard frames, if there's not enough CPU to work will all of them. So, you will never know how much of those times are due to V4L kernelspace part. On the tests I did here with TV applications, the amount of performance, reported by "top" also indicated that the previous approach were worse. For example, on the same centino machine @1.5 GHZ, mplayer with "-tv driver=v4l2" were ranging from 30% to 75% of CPU. With videobuf, the CPU consumption were close to 23%, without much variation. Cheers, Mauro -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list