ffmpeg at half speed ... sort of.

[Paul Chvostek]

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, 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 symptom (see below) seems to be that the actual framerate is always
about 60fps, despite lower framerates being encoded into ffmpeg's
output.  Whatever framerate I specify, it uses 60fps, and calls it
whatever I specified.  :-/

> 	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, 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
fewer of them if I specify "-r 20", and *almost* none at "-r 15".  And
when I specify these lower framerates, the seconds still tick by far
faster than they should....  After 15 seconds of encoding at "-r 15",
ffmpeg says:

 % time ffmpeg -y -an -vd /dev/bktr0 -s 640x480 -tvstd ntsc \
  -vcodec mpeg4 -b 300 -t 60 -r 15 test6.mpg
 ...
 frame=  900 q=7.5 Lsize=    2430kB time=60.0 bitrate= 331.8kbits/s    
 video:134kB audio:0kB global headers:0kB muxing overhead 1707.964775%
 ffmpeg in free(): warning: page is already free
 6.338u 0.171s 0:15.08 43.1%     67+7506k 0+19io 150pf+0w
 %

and

 % time ffmpeg -y -an -vd /dev/bktr0 -s 640x480 -tvstd ntsc \
  -vcodec mpeg4 -b 300 -t 60 -r 29.97 test7.mpg
 ...
 SLEPT NO signals - 5213 microseconds late
 frame= 1797 q=31.0 size=    2742kB time=60.0 bitrate= 374.6kbits/s    
 SLEPT NO signals - 4837 microseconds late
 frame= 1799 q=31.0 Lsize=    2744kB time=60.0 bitrate= 374.5kbits/s    
 video:1023kB audio:0kB global headers:0kB muxing overhead 168.277304%
 ffmpeg in free(): warning: page is already free
 11.990u 0.273s 0:20.43 60.0%    66+7460k 0+21io 150pf+0w

> 	Does fiddling with sysctl kern.timecounter.method help ?

Er...  I don't have one of those.  5.3-RELEASE.  I do have:

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?  I can't seem to find an
equivalent to kern.timecounter.method ... and a quick look at 4.x man
pages tells me nothing about that particular sysctl knob.

> 	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.  ACPI is loaded as a module, and I'm
not aware of any dependencies on it.  I've also tried various "options
HZ" values (from 10 to 1000), and saw no change.

-- 
  Paul Chvostek                                             <paul at it.ca>
  Operations / Abuse / Whatever
  it.canada, hosting and development                   http://www.it.ca/