Date: Mon, 14 Feb 2005 10:23:31 +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: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 13 Feb 2005 13:21:20 -0500
Paul Chvostek <paul+fbsd@it.ca> 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 - <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 ...
>
> 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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050214102331.0380d1b8.steve>