Not setting desired_fps results in lower jpeg capture fps than expected

[aggieNick02]

I noticed that when I was watching a served mjpeg stream or reading a jpeg sink, the maximum fps I would see was around 62-63 fps, despite the source being 120 or 144fps. If I switched to a raw sink, I would read at the expected fps.

I traced this to this line that sets the interval for run->refresher: https://github.com/pikvm/ustreamer/blob/472673ea9067c377f3e6dfde75cd2c58282d0b59/src/ustreamer/http/server.c#L206

It seems like instead we should be doing something like the following, but wasn't 100% sure about it:

		uint fps_to_use=0
		if (stream->cap->desired_fps > 0) {
			fps_to_use=stream->cap->desired_fps;
		} else {
			fps_to_use=stream->cap->run->hw_fps;
		}
		if (fps_to_use>0) {
			interval.tv_usec = 1000000 / (fps_to_use * 2);
		} else {
			interval.tv_usec = 16000; // ~60fps
		}

[mdevaev]

Hello. The real reason is that the algorithm makes poor constraints when using multithreaded encoding in stream.c. I didn't figure out how to make it better, so I didn't change anything here.

[aggieNick02]

Ah ok thanks for taking a look. When I don't set --desired_fps, I will get 62-63 fps when there is a client or sink reader present. By setting --desired_fps to 120, I can get that higher. Not a big deal, it just bothered me enough to dig into where the 62-63 limit was coming from.