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>