Date: Thu, 10 Feb 2005 09:57:13 +0000 From: Steve O'Hara-Smith <steve@sohara.org> To: Paul Chvostek <paul+fbsd@it.ca> Cc: freebsd-multimedia@freebsd.org Subject: Re: ffmpeg at half speed ... sort of. 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 9 Feb 2005 13:03:36 -0500 Paul Chvostek <paul+fbsd@it.ca> 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 - <number> 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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050210095713.3b155ce6.steve>