From owner-freebsd-multimedia@FreeBSD.ORG Mon Feb 14 10:22:15 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 1C6E516A4CE for ; Mon, 14 Feb 2005 10:22:15 +0000 (GMT) Received: from sohara.org (sohara.org [192.220.64.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id D68DB43D1D for ; Mon, 14 Feb 2005 10:22:14 +0000 (GMT) (envelope-from steve@sohara.org) Received: (qmail 64011 invoked by uid 16563); 14 Feb 2005 10:22:14 -0000 Received: from unknown (HELO SOHARA) ([217.12.14.195]) (envelope-sender ) by 192.220.64.179 (qmail-ldap-1.03) with SMTP for ; 14 Feb 2005 10:22:14 -0000 Date: Mon, 14 Feb 2005 10:23:31 +0000 From: Steve O'Hara-Smith To: Paul Chvostek Message-Id: <20050214102331.0380d1b8.steve@sohara.org> In-Reply-To: <20050213182120.GT40151@it.ca> References: <20050207032841.GA33816@it.ca> <20050207100521.544ed9bc.steve@sohara.org> <20050209180336.GA28606@it.ca> <20050210095713.3b155ce6.steve@sohara.org> <20050213182120.GT40151@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: Mon, 14 Feb 2005 10:22:15 -0000 On Sun, 13 Feb 2005 13:21:20 -0500 Paul Chvostek wrote: > Thanks for your response, Steve. > > On Thu, Feb 10, 2005 at 09:57:13AM +0000, Steve O'Hara-Smith wrote: > > > > 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 ... > > I do not fully grok this, but I'd be happy to assist with whatever > diagnostics I can. > > So ... usleep is interrupted when a new frame is available from the bktr > driver, Exactly. > or is the sync signal merely a timer? Could this be a problem > with the frequency of the sync signal coming from the driver? Does the > driver time its sync signals based on the hardware, or something else? The driver gets it's sync signals from the incoming video field sync. > > Do you get any of the SLEPT ... messages ? > > Plenty of them. From five to ten for every notice as to what frame I've > reached, That's not good - probable causes for that many are lousy signal or bad timekeeping - given the other symptoms I strongly suspect bad timekeeping. > all in the range of 4000 to 6000 ms. (Which is odd, since they > start immediately after I run ffmpeg, without a 4 second delay.) I get They're in microseconds - I doubt you'd notice a four millisecond delay :) > > Does fiddling with sysctl kern.timecounter.method help ? > > Er... I don't have one of those. 5.3-RELEASE. I do have: Erk - I haven't played with 5.3. > kern.timecounter.hardware: ACPI-fast > kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-1000000) > > Is either of those what we're looking for? kern.timecounter.hardware should be the one - from the looks of it. Try setting it to TSC or i8254 (probably TSC will do a better job). > > Does turning off ACPI (if it's on) help ? > > Funny you should ask. When I try to boot without ACPI, I get a kernel > panic as soon as the system tries to go into multi-user mode, even if I > turn off Hyperthreading in BIOS. It might be worth checking on Hyperthreading having an effect. -- 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/