Every autonomous-vehicle team working with camera and synthetic video data, accumulating to tens and sometimes hundreds of petabytes, reaches the same question: is it safe to compress this footage, or will compression change what the models see, and degrade the footage for the tasks that rely on it?
The instinct to never touch the data, and to train and store everything raw – is understandable. In narrow cases that might even be the right call.
But keeping everything raw has a cost. Raw images or videos carry a great deal of information which contains little value to a vision task. Trying to store everything might even lead to deleting data that we are going to need later.
Let’s look at some numbers: One second of 2MP camera video at 12-bit 4:2:2 is about 2,200 Mb/s. Lossless compression roughly halves that, to around 1,100 Mb/s. Content-adaptive compression can reduce it to about 5 Mb/s.
Closing that gap turns petabytes into gigabytes, days of data transfer into hours. This makes the difference between streaming from the vehicle in real time and waiting for an end-of-day offload.
We want to make sure that the video data itself, probably the largest and heaviest data type in the process – fits our needs and KPIs, while staying optimized for storage, networking, development cycles, and budget.
What “ML-Safe” actually means
We need a way to compress across these datasets without losing model accuracy. Compression is ML-Safe when the change it causes in model behavior is statistically indistinguishable from the variance the model already tolerates due to camera noise or other real-world permutations. Compression is ML-unsafe when it removes important information, causing unacceptable degradation in model behavior.
ML-Safe is defined across the pipeline, end-to-end: from the camera in the vehicle, through the training cluster in the cloud, and to the model inference. At each point it may have different KPIs and metrics.
But the industry lacks a shared framework for that. The simple reason is that each team and each model has separate needs. A detector, a segmentation network, a depth estimator, and a 3D object-detection model each carry their own architecture, task, and training data, so each responds to compression differently. A compression choice made anywhere along that path can change a model’s behavior somewhere, which is why “safe” can’t be certified at a single stage in isolation.
The proof that counts is on your own data
Beamr has benchmarked ML-Safe compression on public datasets and off the shelf models. Content-adaptive compression cuts file size by orders of magnitude for un-compressed footage and by about half compared to industry standard compression with no measurable impact on model accuracy. For example, results held mean Average Precision (mAP) within about 2% of the baseline (Part 2; the series extends this to captioning and other tasks in Part 3 and Part 4).
Results on our data aren’t results on yours. Your models, sensors, scenes, and accuracy thresholds are what determine where “safe” actually sits – and the only way to know is to test compression against them directly.
Once that’s settled on your own data, compression stops being a risk you’re quietly carrying and becomes a decision you control.
