ffmpeg at half speed ... sort of.

[Steve O'Hara-Smith]

On Sun, 13 Feb 2005 13:21:20 -0500
Paul Chvostek <paul+fbsd at 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/