Does Frigate’s Coral still help if the cameras are already H.264 and you only record?

No. If Frigate is only copying H.264 from the cameras to disk, a Coral does nothing for that job. The Coral is an object detector. It does not encode, decode, or compress the recording. H.264 already being the camera’s format is why the CPU is idle: ffmpeg copies the stream. Unplug the Coral, or never buy it, and the recordings stay the same size, the same quality, and the same reliability.

The confusion is the word accelerator. People hear that a Coral accelerates Frigate and picture a video chip. The video chip, if you need one at all, is the Intel iGPU doing decode for detection. Record-only with a copy does not need that either. It needs a disk and a path that does not re-encode.

What record-only actually spends

A camera that outputs H.264, a main stream at a few megabits, and Frigate’s record role set to copy, writes those packets to a file. The CPU touches the container, not the pixels. Four cameras are a few megabytes a second of disk and a steady network read. You can watch the process list and see ffmpeg not burning a core. A Coral sitting on USB does not appear in that picture. Its inference speed in the Frigate metrics, if detect is disabled, is a device you are not asking questions.

HEVC is the same story if you copy it. The codec is the camera’s problem, already solved before the packet reached the mini PC. Re-encoding to “help” the disk is a different project, and it is a Quick Sync project, not a Coral project. The Coral cannot turn HEVC into a smaller H.264 file. It cannot make a 4K stream into a 1080p archive. If the disk is filling up, change the camera bitrate, the retention, or the resolution at the camera. Those are the knobs that change a copy. A detector does not.

Motion that only marks timeline regions can be done from frame differences without an object detector. That still wants decoded frames, which is a CPU or iGPU cost, and it is still not a Coral cost. If you turned detection off and left motion on, you may be decoding for a timeline and still not using the TPU. Look at the detector process. If it is not running, the Coral is a souvenir. If it is running because a default config left detect enabled, you are not in the “only record” world this question describes. You are detecting, and the Coral might matter for that, which is a different decision from whether the file on disk required it. It did not.

The purchase that does not show up in the file

A Coral USB draws a little power, takes a port, and can electrically annoy a Zigbee stick on the same machine. In exchange, a record-only config gets an inference number you never read. The recordings do not get sharper. They do not survive a dead disk better. They do not start faster. I would rather spend that money on the disk, because the disk is the thing that ends a record-only system. A full volume stops the recording. A missing Coral does not.

Retention is the real sizing. Continuous H.264 from four cameras for two weeks is a known number of terabytes, and it does not change when a TPU is plugged in. Event-only recording without a detector is a contradiction: events of what. If you want person and car clips, you are detecting, and then a Coral or OpenVINO is in play. If you want everything the camera saw, you are recording continuously or on the camera’s own motion, and the Coral is idle while the disk is not. Be honest about which of those you configured. The Frigate config has a detect role and a record role. Record without detect is allowed. It is the mode in which the Coral is decorative.

go2rtc and the restream do not recruit the Coral either. They move the same H.264 to Home Assistant or to a browser. A browser that cannot play the codec may transcode, and that transcode is ffmpeg on the CPU or iGPU. Still not the Edge TPU. If the live view is slow, the fix is a substream, a client that can play H.264, or hardware decode. Adding a Coral and refreshing the live view will disappoint you in a very specific way: nothing about the picture changes, because nothing about the picture was being detected.

When you would turn it back on

Turn detection on when you want a notification that a person is in the frame, not a folder of video you will never watch. Then the Coral, or the iGPU via OpenVINO, earns a look. The cameras can stay H.264. The codec never was the reason to own a detector. The reason is the label. Until you want the label, do not keep the detector process running “in case.” It decodes frames you will not use, it writes events you will not read, and it makes the CPU graph look like you needed an accelerator when the recording path was fine.

If the Coral is already plugged in and detect is off, you can leave it. It is not hurting the files. It is also not helping them, and the USB port might be more useful for the Zigbee coordinator or a disk. I would unplug it and confirm a night of recording still completes. That test is the whole article. If the files land and play, the Coral was not in the path. If something breaks, you had detect or a decode path you had forgotten, and the break is the thing to read, not a reason to assume the TPU was compressing video. It never was.

The metrics that should stay boring

After you disable detect, the system page should get quieter, not louder. Detector inference disappears or sits unused. The CPU falls if it had been decoding for detection. The GPU, if you had VAAPI on for that decode, goes idle. Camera ffmpeg processes remain, and their CPU time should be a sliver. If CPU stays high, you are not copying. A preset that decodes and re-encodes, a birdseye view that composites every camera into a new stream, or a detect width still pointed at the main stream will keep the machine busy with pixels. None of that business is a Coral shortage. Birdseye is ffmpeg. Fix or disable the thing that is building a new video. Then look again.

Storage errors are the failures that remain, and they look nothing like a missing TPU. A recording that ends early, a gap in the timeline, a database that locked because the disk was full: those are retention and filesystem problems. The Coral cannot reopen a sqlite file on a full volume. Lower the continuous retain days, move the recordings to a disk with room, and keep the database off a dying SD card if the mini PC is a Pi. Record-only on a Pi is reasonable precisely because copy is cheap. People bolt a Coral onto a Pi that was only recording and then wonder why the SD card still dies. The card dies because of writes. The detector was never the writer that mattered. The segments were.

A useful night test is dull. Note the free space. Let the cameras record overnight with the Coral unplugged and detect off. In the morning, play an hour from each camera and confirm the timestamps cover the night. If they do, you have your answer in the files, which is the only place it counted. If an hour is missing, read the log for ffmpeg and disk errors, not for the Edge TPU. Reintroducing the Coral to “stabilize” a copy will not fill a gap caused by a camera that rebooted or a share that unmounted. The camera’s H.264 either arrived or it did not. The TPU does not retransmit it.

Who should stop at the disk

Stop at the disk if the config records, detect is off, and the cameras are already H.264 or HEVC you are willing to copy. Spend the next hour on retention, on a disk that is not the SD card, and on whether the share survives the mini PC rebooting. A Coral does not belong in that hour. It belongs in the hour you decide you want objects, not footage. Footage was solved by the camera’s encoder before Frigate started. If a future you turns detection on, that is the day to decide between the Coral and the iGPU, with the recordings already proven. Until that day the TPU is not on the critical path, and unplugging it is the cleanest way to see that the files do not care. Keep the receipt in a drawer if you might want labels later. Do not keep the device in the USB port as a superstition about video quality. The quality left the camera as H.264, and Frigate’s job was to catch those packets and put them on a disk that still has space in the morning.