From owner-freebsd-multimedia@FreeBSD.ORG Thu Feb 10 09:56:01 2005 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01A7916A4CF for ; Thu, 10 Feb 2005 09:56:01 +0000 (GMT) Received: from sohara.org (sohara.org [192.220.64.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBA8F43D49 for ; Thu, 10 Feb 2005 09:56:00 +0000 (GMT) (envelope-from steve@sohara.org) Received: (qmail 79782 invoked by uid 16563); 10 Feb 2005 09:56:00 -0000 Received: from unknown (HELO SOHARA) ([217.12.14.195]) (envelope-sender ) by 192.220.64.179 (qmail-ldap-1.03) with SMTP for ; 10 Feb 2005 09:56:00 -0000 Date: Thu, 10 Feb 2005 09:57:13 +0000 From: Steve O'Hara-Smith To: Paul Chvostek Message-Id: <20050210095713.3b155ce6.steve@sohara.org> In-Reply-To: <20050209180336.GA28606@it.ca> References: <20050207032841.GA33816@it.ca> <20050207100521.544ed9bc.steve@sohara.org> <20050209180336.GA28606@it.ca> X-Mailer: Sylpheed version 1.9.2 (GTK+ 2.4.1; i586-pc-interix3) X-Face: %]+HVL}K`P8>+8ZcY-WGHP6j@&mxMo9JH6_WdgIgUGH)JX/usO0%jy7T~IVgqjumD^OBqX,Kv^-GM6mlw(fI^$"QRKyZ$?xx/ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-multimedia@freebsd.org Subject: Re: ffmpeg at half speed ... sort of. X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 09:56:01 -0000 On Wed, 9 Feb 2005 13:03:36 -0500 Paul Chvostek wrote: > Yeah, the -b 50 was just for testing. It's not too bad at 160x120. But > I get the same behaviour (slow framerate, crawling playback) that I see > at higher bitrates as well. OK that lets out bandwidth limitation problems ... > % grep CPU: /var/run/dmesg.boot > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz 686-class CPU) ... and CPU limitation problems - an AMD XP2000 can handle 720x675 50Hz PAL encoding without problems so you have plenty of CPU. That leaves grab rate problems I think - the grab code uses a usleep that should get interrupted by the sync signal from the bktr driver. If it doesn't it is set to sleep 1/8 of a frame too long and then grab the frame and complain (SLEPT NO signals - microseconds late). When the packet is grabbed it is given a timestamp using the ffmpeg library routine avgettime. If this is misbehaving it points to problems with low level timekeeping, which is not too uncommon (see endless threads about microuptime going backwards). So to check for that ... Do you get any of the SLEPT ... messages ? Does fiddling with sysctl kern.timecounter.method help ? Does turning off ACPI (if it's on) help ? -- C:>WIN | Directable Mirror Arrays The computer obeys and wins. | A better way to focus the sun You lose and Bill collects. | licences available see | http://www.sohara.org/