Video Export Scheduler ("bin packing")

  • I was given the unenviable task on the UKs largest strategic CCTV project to design and code the video export scheduler to gather recorded video evidence for multiple incidents, from multiple devices that may be situated in different locations as timely as possible.

    For a system that has almost 70,000 cameras in over 2,500 locations connected via differing level of connectivity this required a complex scheduling system to meet the requirements of:

    • Video export can be prioritised per export
    • There may be time restrictions in locations where for example the same connectivity is used for live as recorded video
    • The recording device may only support a limited number of active live and/or export sessions
    • The rate at which streamed recordings can be transferred may vary per device type
    • The bandwidth of the connectivity between location may vary the rate at which export can be performed
    • It should be possible to pause locations and devices to prevent bandwidth exhaustion during a crisis
    • All exports should be made available in as a timely fashion as possible

    The solution turned out to be actually quite simple, although a more complex variant on the "knapsack" or "bin packing" problem typically used for finding the optimal way of packing different sized objects in a given space, for example the logistics of loading a lorry. The core differences however were:

    1. The number and sizes of knapsacks/bins to be packed varied - depending on the current time, the locations of the devices, as well as the type of recording device.
    2. The size of each object (export) varied - depending on the device, and the length of required recording, as well as the location of the device (because of the available bandwidth)
    3. Each object had a value (priority) - such that the aim was to maximize the value of the rate of export, not the most number of items .

    As the list of exports changed either through completion, addition, being paused, or failed for some reason, the scheduler would update the running averages to improve the estimations, and then perform the scheduling again to ensure that key requirement of "timely fashion" was adhered to.

    With such a complex algorithm, unit tests were vital to ensure that changes did not break it. Although the code allowed it to report why a certain job had been scheduled in such a position the UI for this feature was not exposed on a calendar control as I had foreseen.

    The failure of the product group to prioritise the implementation of this visualisation did cause a number of support requests for it "not working" when it fact the scheduler was working perfectly and had scheduled export tasks in an optimal, if not immediately obvious, way.