Setting a frame rate doesn't always work like you expect. It depends on two things:

1. What your camera is capable of outputting.
2. Whether the current capture backend you're using supports changing frame rates.

So point (1). Your camera will have a list of formats which it is capable of delivering to a capture device (e.g. your computer). This might be 1920x1080 @ 30 fps or 1920x1080 @ 60 fps and it also specifies a pixel format. The vast majority of consumer cameras do not let you change their frame rates with any more granularity than that. And most capture libraries will refuse to change to a capture format that the camera isn't advertising.

Even machine vision cameras, which allow you much more control, typically only offer a selection of frame rates (e.g. 1, 2, 5, 10, 15, 25, 30, etc). If you want a non-supported frame rate at a hardware level, usually the only way to do it is to use hardware triggering.

And point (2). When you use cv.VideoCapture you're really calling a platform-specific library like DirectShow or V4L2. We call this a backend. You can specify exactly which backend is in use by using something like:

cv2.VideoCapture(0 + cv2.CAP_DSHOW)

There are lots of CAP_X's defined, but only some will apply to your platform (e.g CAP_V4L2 is for Linux only). On Windows, forcing the system to use DirectShow is a pretty good bet. However as above, if your camera only reports it can output 30fps and 60fps, requesting 10fps will be meaningless. Worse, a lot of settings simply report True in OpenCV when they're not actually implemented. You've seen that most of the time reading parameters will give you sensible results though, however if the parameter isn't implemented (e.g exposure is a common one that isn't) then you might get nonsense.

You're better off waiting for a period of time and then reading the last image.

Be careful with this strategy. Don't do this:

while capturing:
    res, image = cap.read()
    time.sleep(1)

you need to make sure you're continually purging the camera's frame buffer otherwise you will start to see lag in your videos. Something like the following should work:

frame_rate = 10
prev = 0

while capturing:

    time_elapsed = time.time() - prev
    res, image = cap.read()

    if time_elapsed > 1./frame_rate:
        prev = time.time()

        # Do something with your image here.
        process_image()

For an application like a hand detector, what works well is to have a thread capturing images and the detector running in another thread (which also controls the GUI). Your detector pulls the last image captured, runs and display the results (you may need to lock access to the image buffer while you're reading/writing it). That way your bottleneck is the detector, not the performance of the camera.

You set the FPS for the output via the VideoWriter,
but you didn't attempt to set the FPS for the input via the VideoCapture.

In order to do that you can try to call cv2.VideoCapture, with the cv2.CAP_PROP_FPS property after you create cap.
For example:

cap.set(cv2.CAP_PROP_FPS, 3)

However - note that the actual behavior is dependant on the specific capture device you are using. Some support only certain FPSs. See also this post regarding it: change frame rate in opencv 3.4.2.

If it does work you will be able to simplify your code a lot - just capture frames, process them and save (without any manual fps management).

Okay, there is several ways you can do this but I would suggest first checking the capabilities of the webcam. You can do this by installing:

sudo apt-get install v4l-utils

And run:

v4l2-ctl --list-formats-ext

If the desired frame rate is not listed you can increase the value in cv2.waitKey() and time it with time.time() to get the frame rate you want.

OpenCV automatically selects the first available capture backend (see here). It can be that it is not using V4L2 automatically.

Also set both -D WITH_V4L=ON and -D WITH_LIBV4L=ON if building from source.

Possibly, the pixel format that is selected by OpenCV does not support the frame rate that you want, in the resolution that you want. On Linux you can use v4l2-ctl --list-formats-ext and v4l2-ctl --all to see the settings.

In order to set the pixel format to be used set the CAP_PROP_FOURCC property of the capture:

capture = cv2.VideoCapture(cam_id, cv2.CAP_V4L2)
capture.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc('M', 'J', 'P', 'G'))

One potential way is to set a timestamp within the loop and keep track of the time the last frame was shown. For instance, only once a certain amount of time has elapsed then you show the frame. At the same time, you constantly read frames to keep the buffer empty to ensure that you have the most recent frame. You don't want to use time.sleep() because it will freeze the program and not keep the buffer empty. Once the timestamp hits, you show the frame and reset the timestamp.

import cv2
import time

cap = cv2.VideoCapture(0)

# Timeout to display frames in seconds
# FPS = 1/TIMEOUT 
# So 1/.025 = 40 FPS
TIMEOUT = .025
old_timestamp = time.time()

while(True):
    # Capture frame-by-frame
    ret, frame = cap.read()

    if (time.time() - old_timestamp) > TIMEOUT:
        # Display the resulting frame
        cv2.imshow('frame',frame)
        if cv2.waitKey(1) & 0xFF == ord('q'):
            break
        old_timestamp = time.time()

# When everything done, release the capture
cap.release()
cv2.destroyAllWindows()

Admittedly the CPU on the RPI B+ isnt the greatest (single core, 700MHz w/o overclocking), but there is a chance there might be other issues slowing down your processing pipeline

Have you done any profiling to identify the bottlenecks in your script(s) ?

In my experience, One of the slowest operations is I/O to disk (microsd card or USB storage). If your pipeline involves one or more disk IO there is a good chance that is pulling down your overall fps throughput.

The simplest way (without resorting to external tools) to identify such problems is to simply comment out or bypass some sections of your scripts and looking at the fps. If no improvement in fps, then restore it and move on to another section.

if you are open to using additional or external tools, here are some links I think you might find useful

• https://docs.python.org/2/library/profile.html
• https://www.huyng.com/posts/python-performance-analysis
• https://stackoverflow.com/a/582337/1635109

While multithreading can improve responsiveness it doesnt really improve throughput for CPU intensive applications on single core devices if you find the CPU is indeed your bottleneck your options are somewhat limited

• Overclocking
• use a RPi2/RPI3 (quad core @ 900/1200 MHz)

Here are some interesting writeups on the pros/cons of multithreading targeting different types of applications and scenarios (I/O bound, CPU bound, UI interaction etc)

• https://msdn.microsoft.com/en-us/library/ms810437.aspx
• https://msdn.microsoft.com/en-us/library/ms810439.aspx