Camera Support in Traccar: How the Media System Actually Works

One of the most common questions on the Traccar forum and in the groups is whether the platform "supports cameras." The short answer is yes, but not the way you'd imagine: Traccar isn't an MDVR or a video server, it's a tracking server that also happens to know how to receive and store the multimedia files certain devices send it.

In this article I explain the actual mechanism, exactly as it's implemented in the server code, so you know precisely what to expect before you buy hardware.

The media system, in three pieces

Traccar has a generic multimedia subsystem, independent of the protocol. It's basically three pieces:

1. The decoder buffer

When a tracker sends a photo, it almost never does it in a single packet: it splits it into fragments. That's why the base class for every decoder (BaseProtocolDecoder) exposes common methods:

• newMediaBuffer(...) — creates a buffer for the current connection
• getMediaBuffer() — retrieves the buffer in progress to keep accumulating fragments
• writeMediaFile(...) — flushes the completed buffer to disk

Important: only one media buffer is kept per connection. If the device tries two simultaneous transfers on the same connection, it isn't going to end well.

2. The file manager

MediaManager is the one that actually writes to disk. The structure it generates is predictable:

{media.path}/{uniqueId}/{timestamp}.{extension}

In other words, a subfolder per device, named with its unique identifier (the same IMEI or ID you registered in Traccar), and inside it files named by timestamp. The path is validated to prevent a malicious identifier from escaping the base folder.

3. The position attribute

When the file is saved, the decoder writes the file name as a position attribute. There are three attributes that exist:

Watch out for this detail, because it trips up a lot of people: the attribute stores the file name, not the full URL. The client rebuilds the path by combining the device's uniqueId with that file name.

How the files are served

Traccar registers a static servlet at /api/media/* pointing at the folder configured in media.path. The final URL takes this form:

/api/media/{uniqueId}/{fileName}

It isn't a public folder: in front of it there's a filter (MediaFilter) that requires a valid session and also checks that the user has permission over that specific device. A user can't view the photos of a device that isn't theirs just by guessing the IMEI.

A configuration nuance almost nobody mentions: there's no media.enable key. I've seen reports of users setting media.enable=true in traccar.xml and wondering why nothing happens. The servlet gets registered if media.path has a value, period.

Which protocols actually implement it

This is where it pays to be honest, because Traccar's catalog has more than 270 protocols and the vast majority don't touch multimedia at all.

Going through which decoders really use the media system, the list is short:

• Teltonika — photo via camera command (Codec12)
• GT06 / Concox — photo request
• Jimi IoT (dedicated HTTP decoder) — image and video, distinguished by MIME type
• Dualcam — JPG image and H.265 video
• Watch (smartwatches) — image and audio (AMR)
• Atrack, Fifotrack, Galileo, GPS103, Meiligao, Meitrack, PT502, Ruptela — image

The special case: JT808 / JT1078

The JT/T808 protocol (what many vendors call "Huabao," the one most Chinese MDVRs speak) works through a completely different path, and it's worth understanding because it's the one that causes the most confusion:

• The JT808 decoder does not save files through the media system just described. It has the photo (0x8888) and video (0x9101 request, 0x9102 control) constants defined, but it doesn't write anything to media.path.
• Instead, it does do live video: when streaming is requested, Traccar sends the 0x9101 message telling the camera which host and port to connect to, with which channel, dataType, and streamType. The camera then opens a JT1078 session against the server, and Traccar acts as a transparent live relay.

The practical consequence is significant: with a JT808 MDVR you'll be able to watch live video, but no file is ever left on the server. The recorded history keeps living on the unit's SD card inside the vehicle. If you open media.path on a server with a JT808 MDVR, you'll find only static device images, not a single .mp4 or .h264.

An important nuance: that's a gap in the decoder, not in the design. The media system is generic and any protocol can use it; JT808 simply doesn't invoke it. It's perfectly implementable with a scoped modification to the decoder.

I go into this in detail, with real production logs, in live JT1078 video in Traccar.

For MDVR brands like Howen or Streamax I couldn't find dedicated decoders in Traccar: if someone is selling you a camera "compatible with Traccar," ask exactly which protocol it speaks and request a real demo before signing anything. If you're shopping around, see which cameras actually work with Traccar before you commit to hardware.

Recent changes

Camera support is one of the most active areas of the project right now:

• The Jimi IoT photo decoder is new — it was added in June 2026, with a follow-up fix to attribute decoding.
• In June 2026 the media buffers in the Teltonika decoder were hardened: there was an unbounded memory allocation in the Codec12 photo path that a malformed packet could exploit. Good enough reason to keep the server updated.
• The Dualcam fix landed in May 2026.

The bottom line: two worlds that don't mix

This is the idea worth taking away:

Traccar does both, but through separate paths and with different devices. Deciding what hardware to buy starts with deciding which of the two columns you actually need.

If you want the practical side, continue with the media.path configuration guide, with how to request a remote photo with requestPhoto, and with live JT1078 video.