Tesseract Technology : XVideo experiences and analysis

A bit of code to tickle the Xv API

A bit of research yielded this set of links and this bit of code from same source. Here is a local copy of same. (Many thanks to original author AW).

A minimal Makefile for this looks like this: You can either cut-and-paste (remember to put hard tabs in command line for all dependencies) or you can save/save as with Makefile filename as default or you can force (GNU) make to use your Makefile thusly:

  make -f ThisIsMyMakeFile\-ThereAreManyLikeItButThisOneIsMine

Anyway....

CC = gcc
  
CPP = g++ 
  
CC_FLAGS = -Wall
CPP_FLAGS = -Wall

# you may want to adjust path to X libs bfor your system  
X11_LIBS_PATH = -L/usr/X11R6/lib
  
X11_LIBS = -lX11 -lXext
    
X11_XV_LIBS = -lXv

testxv: testxv.o
  $(CC) -o $@ $^ $(X11_LIBS) $(X11_XV_LIBS)

testxv.o : testxv.c
  $(CC) $(CC_FLAGS) -c $<

This yields a nice build:

$ make testxv
gcc -Wall -c testxv.c
g++ -Wall -o testxv testxv.o \
 -L/usr/X11R6/lib -lX11 -lXext -lXv

Running this yields three interesting results:

a) This informative output

starting up video testapp...

 found 24bit TrueColor
beginning to parse the Xvideo extension...

========================================
XvQueryExtension returned the following:
p_version      : 2
p_release      : 2
p_request_base : 143
p_event_base   : 92
p_error_base   : 164
========================================
=======================================
XvQueryAdaptors returned the following:
1 adaptors available.
 name:        3dfx Video Overlay
 type:        input | image | 
 ports:       1
 first port:  55
adaptor 0 ; format list:
 depth=24, visual=35
 depth=24, visual=36
 depth=24, visual=37
 depth=24, visual=38
 encoding list for port 55
  id=0, name=XV_IMAGE, size=2048x2048, numerator=1, denominator=1
 attribute list for port 55
  name:       XV_COLORKEY
  flags:      get set
  min_color:  0
  max_color:  16777215
  name:       XV_FILTER_QUALITY
  flags:      get set
  min_color:  0
  max_color:  1
 image format list for port 55
  0x32595559 (YUY2) packed
  0x59565955 (UYVY) packed
  0x32315659 (YV12) planar
  0x30323449 (I420) planar

96000

b) This frame rate data:
(Incidentally, this is running in machine with following output from 3dfx Voodoo 3 on PIII 500Mhz box running RedHat 7.3 [I think] with /proc/cpuinfo output:

# more /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping  : 3
cpu MHz   : 548.749
cache size  : 512 KB
fdiv_bug  : no
hlt_bug   : no
f00f_bug  : no
coma_bug  : no
fpu   : yes
fpu_exception : yes
cpuid level : 2
wp    : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips  : 1094.45

200 frames in 0 seconds; inf fps
200 frames in 1 seconds; 200.0000 fps
200 frames in 1 seconds; 200.0000 fps
200 frames in 0 seconds; inf fps
200 frames in 0 seconds; inf fps
200 frames in 1 seconds; 200.0000 fps
200 frames in 0 seconds; inf fps
200 frames in 0 seconds; inf fps
200 frames in 1 seconds; 200.0000 fps
200 frames in 0 seconds; inf fps
200 frames in 1 seconds; 200.0000 fps
200 frames in 0 seconds; inf fps
200 frames in 0 seconds; inf fps
200 frames in 1 seconds; 200.0000 fps
200 frames in 1 seconds; 200.0000 fps
200 frames in 0 seconds; inf fps
200 frames in 0 seconds; inf fps
200 frames in 1 seconds; 200.0000 fps
200 frames in 0 seconds; inf fps
200 frames in 1 seconds; 200.0000 fps

c) an interesting window that can't be caught by TheGimp as a window capture. It looks like a neat sinusoid of some kind generated by code, but as it updates on screen and Gimp window sample from it, a move of Gimp window 'loses' the data so that result is dark blue background. Fascinating....the only thing that seems reasonable is related to various bits of Google-ing that resulted in many links talking about 'syncing' Xv display with other issues in X window. This is proof of that, or some other bug in voodoo3 Xv or normal X driver.....food for thought.

The first thing about this test program to fix is that it is specialized at resolution 320x200. So here is revised version using command line:

  testxv2 [-XiWidth] [-YiHeight]

Here is revised Makefile (transformation rules would be handy now...)

CC = gcc
  
CPP = g++ 
  
CC_FLAGS = -Wall
CPP_FLAGS = -Wall

# you may want to adjust path to X libs bfor your system  
X11_LIBS_PATH = -L/usr/X11R6/lib
  
X11_LIBS = -lX11 -lXext
    
X11_XV_LIBS = -lXv

testxv: testxv.o
  $(CC) -o $@ $^ $(X11_LIBS) $(X11_XV_LIBS)

testxv.o : testxv.c
  $(CC) $(CC_FLAGS) -c $<

testxv2 : testxv2.o
  $(CC) -o $@ $^ $(X11_LIBS) $(X11_XV_LIBS)

testxv2.o : testxv2.c
  $(CC) $(CC_FLAGS) -c $<

This builds nicely, and now we can do:

  ./testxv2 -X640 -Y480

Which yields data that looks like this:

460800
200 frames in 2 seconds; 100.0000 fps
200 frames in 1 seconds; 200.0000 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 1 seconds; 200.0000 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 1 seconds; 200.0000 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 1 seconds; 200.0000 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 2 seconds; 100.0000 fps

..or more load-ish..

  ./testxv2 -X800 -Y600

Which performs like this:

720000
200 frames in 2 seconds; 100.0000 fps
200 frames in 3 seconds; 66.6667 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 3 seconds; 66.6667 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 3 seconds; 66.6667 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 3 seconds; 66.6667 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 3 seconds; 66.6667 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 3 seconds; 66.6667 fps
200 frames in 2 seconds; 100.0000 fps
200 frames in 2 seconds; 100.0000 fps

Note that number prior to list of frame rate scales as product of width x height.

320 x 200 (default) was 9600
640 x 480 was 460800
800 x 600 was 720000

Check the code to see where this happens....

Running at higher frame sizes makes this machine pokier pretty quickly. Top shows that X is pretty busy, with about 80% user and about 2.7% peak for testxv2 process. X is pretty chill at 1.5-4.5% on this machine when testxv2 is not running under same general conditions. This is not a precise benchmark in general because there are lots of Mozilla processes in the background with busy browser processes (lots of Flash-iness) running when these benchmarks were run. Your Mileage May Vary...

Back to Tesseract links