JPEG Requests - async?

photonclock
photonclock
in SecuritySpy

Hi Ben - question: is SecSpy's delivery of JPEG requests async or serialized?

Example:

Camera FPS = 8

If I send 8 JPEG requests in 1 second (1 request every 125ms), and the average SecSpy response time (JPEG received) per request is 250ms, does SecSpy drop 4 out of 8 of my requests, or does it manage a pool of JPEG encoder threads that will consume whatever memory & CPU cycles is needed (up to the limits of the machine or whatever limits you've specified) to fulfill every request?

I'd envision either scenario as roughly:

Serialized JPEG encoder:

Frame 1 <> request 000ms <> SecSpy encoder 1 ready <> deliver JPEG 1 <> done 250ms

Frame 2 <> request 125ms <> SecSpy encoder 1 busy <> drop JPEG 2 request

Frame 3 <> request 250ms <> SecSpy encoder 1 ready <> deliver JPEG 3 <> done 250ms

Frame 4 <> request 375ms <> SecSpy encoder 1 busy <> drop JPEG 4 request

etc...

Async JPEG encoder:

Frame 1 <> request 000ms <> SecSpy encoder 1 ready <> deliver JPEG 1 <> done 250ms

Frame 2 <> request 125ms <> SecSpy encoder 2 ready <> deliver JPEG 2 <> done 250ms

Frame 3 <> request 250ms <> SecSpy encoder 1 ready <> deliver JPEG 3 <> done 250ms

Frame 4 <> request 250ms <> SecSpy encoder 2 ready <> deliver JPEG 4 <> done 250ms

etc...

I'm using simplified hypothetical numbers here for the sake of conveying the question (not entirely hypothetical though - I'm seeing JPEG response times of around 180ms to 415ms when I have multiple threads hammering SecSpy with requests).

Thanks!

Comments

  • Ben
    Ben

    Image/video encoding tasks happen async on a pool of background threads. When a web request comes in, the next frame that comes in from the camera is then sent to be encoded (unless the camera happens to be supplying JPEG data, in which case SecuritySpy may be able to pass that through depending on what has been requested).

    Since these are separate connections, each will get its own independent encoding task - no frame will be dropped due to another task being busy. However, the time it takes for one frame to be encoded is affected by other tasks, as they are all competing for the same resources.

    But you will get dropped frames due to timing issues. Frames don't come into SecuritySpy at exactly every 125ms, and even though you may try your best to issue web requests at a precise interval, the time in which they are actually processed could be many ms later, depending on how busy SecuritySpy's web server is.

    If you need all the frames, it's must better to use a stream rather than single-image requests.

  • photonclock
    photonclock

    >you will get dropped frames due to timing issues. 

    Yes, I completely understand all of that. The numbers in the example were just for the purpose of illuminating the question of serial/blocking vs async. So...if SecSpy is async, then I guess the variances I see are just the jitter/timing variances. Do you have any metrics on how long SecSpy takes to respond to a JPEG request, ie, on your M1 test rig?

    I've tried a few approaches in all of this. I do have multipart streams working, in addition to my original JPEG requests method. There's pros and cons to both.

    For the JPEG request approach, I issue the requests via a pool of separate threads. It's tricky stuff. I built a diagnostic dashboard to measure the request/response times and display the values in real time to help me hone in on where I can optimize vs where the server response times may be the bottleneck...still muddling my way through this... 🤓

Categories