JT1078 Live Video in Traccar: How It Works and Why It Keeps Cutting Out

This article isn't pulled from documentation — it comes from auditing tracker-server.log on a production Traccar server with a JT808 MDVR connected. If you're fighting with live video from a fleet camera, this will save you several nights.

Three things we found that almost nobody explains well:

1. Traccar does do live video, but through a path separate from the photo system.
2. The dropouts are almost never Traccar's fault.
3. The server keeps no video file at all, and that's by design.

What actually happens when you request video

When you fire videoStart from the interface, Traccar doesn't open a stream. What it does is send instructions to the camera via a JT808 protocol message with ID 0x9101 (MSG_VIDEO_REQUEST), which travels over the already-established control TCP connection. The parameters it carries are:

In other words: Traccar tells the camera where to connect, and it's the camera that opens a new session against the JT1078 port. From there the server acts as a relay for the RTP/H.264 flow toward your browser.

In the logs that second session looks like this:

[T149ced73: jt1078 < 189.xxx.xxx.xxx]

That jt1078 < line is confirmation that the camera obeyed the command. It's the first checkpoint when something fails: if it doesn't show up, the problem is in the command or in the camera's network; if it shows up and you still don't see the image, the problem is further downstream.

The companion command is 0x9102 (MSG_VIDEO_CONTROL), which in the interface corresponds to videoStop.

How the video reaches your browser: HLS

This is the part almost nobody explains, and it's the one that decides whether you see video at all.

The RTP flow the camera uploads is not consumed by the browser directly. Traccar remuxes it into MPEG-TS (org.traccar.media.VideoStreamWriter builds the PAT and PMT tables, packs the PES payloads and computes the PTS) and publishes it as HLS through org.traccar.api.resource.VideoStreamResource, mounted at @Path("stream"). Two endpoints:

Note the {channel}: the path carries the channel, exactly like 0x9101 does. A five-channel MDVR exposes five separate playlists, one per channel, and a videoStart on channel 3 is consumed at /api/stream/{deviceId}/3/live.m3u8. That's the answer to "how do I see the side camera?".

And this is where two very common deployment failures come from:

• The reverse proxy blocks the .ts segments. If you put Nginx in front and don't let /api/stream/ through, the playlist loads and the video never starts. Same care with /api/media/.
• HLS buffering. HLS is segmented by design: 2 to 6 seconds of latency is normal. If you expected IP-camera latency, that's not a fault, it's the format.

Why the stream cuts out

In the case we audited, video would start and then drop within a few seconds, intermittently. The two causes turned out to be these, and neither was a server bug:

1. The vehicle's mobile network

The camera was reporting in motion, at speeds between 3.9 and 19.8 km/h. Every handoff between 3G/4G cells produced an instant drop in the packet flow. Live video over LTE on a moving vehicle is, plainly, a hostile scenario: there's no server-side retry that can fix a cell handover.

2. Retry saturation — the self-inflicted cause

This is the good one. Not seeing an image right away, the operator would press the button again. The logs showed successive videoStart / videoStop commands 2 to 5 seconds apart.

The problem is that every new videoStart forces the camera to cancel the ongoing transmission and renegotiate the TCP socket from scratch. Result: a restart loop where the session never gets a chance to stabilize. The more you insist, the less video you see.

How to fix it

Wait 10 to 15 seconds after sending videoStart before touching anything else. The JT1078 TCP handshake plus the stream startup need that margin. It's the one-line fix that resolves most cases.

Use the sub-stream in unstable coverage. Setting streamType to the secondary stream (lower resolution) drastically reduces H.264 frame loss. You don't need full HD to check what's happening in the cab.

Test with the vehicle parked first. If it's stable when parked but not while moving, you already have your diagnosis: it's coverage, not configuration.

There are no video files on the server (and that's fine)

The third part of the audit was looking for the files. With media.path set to ./media, we checked the /opt/traccar/media tree:

find /opt/traccar/media -type f \( -name "*.mp4" -o -name "*.h264" -o -name "*.ts" \)

Zero results. The only thing in those folders were static device.jpg images — which are the device's profile picture, a separate mechanism that has nothing to do with the cameras.

This isn't a configuration failure. With the JT808 decoder as it ships out of the box, Traccar operates purely as a transparent live proxy/relay. Historical video stays on the MDVR's memory or physical SD card inside the vehicle.

That said, it's worth being precise about it: this isn't an architecture limitation, it's a decoder gap. Traccar's media system (the one Teltonika, Jimi, or Dualcam use to save files) is generic and available to any protocol; the JT808 decoder simply doesn't invoke it. It recognizes the multimedia message types but doesn't write the file.

Put differently: it's implementable, and not especially hard — it comes down to hooking JT808's media path into the media buffer that already exists. We have this solved on our own server with that modification. If you depend on it, keep it on your radar as pending development, not as an impossibility.

With an unmodified server, and heading into a hardware purchase: if your requirement is "I want video saved on my server even if the truck catches fire," out of the box you don't have that. That's a conversation to have before signing, not after.

The log commands you should have on hand

To audit a specific device in production:

# Device events (replace with your IMEI)
grep -E "Event id: YOUR_IMEI" /opt/traccar/logs/tracker-server.log

# Video control commands sent
grep "videoStart\|videoStop" /opt/traccar/logs/tracker-server.log

# Incoming JT1078 sessions: is the camera obeying?
grep -i "jt1078" /opt/traccar/logs/tracker-server.log

Bonus: notifications: 0 doesn't mean something's broken

During the same audit, this kept showing up:

INFO: Event id: ..., time: ..., type: queuedCommandSent, notifications: 0
INFO: Event id: ..., type: deviceStopped, notifications: 0

The initial suspicion was that the device was "eating" alerts. It wasn't that: notifications: 0 means Traccar processed the event correctly but that no notification rule (email, SMS, webhook, or push) is configured and attached to that device for that event type.

The event exists, gets logged, and doesn't trigger anything because nobody told it to. The fix is in the notification configuration, not the camera — I cover that in Traccar notifications.

Quick checklist

If live video isn't working, in this order:

1. Does jt1078 show up in the log after videoStart? If not → the camera isn't obeying: check the host/port you're sending it and that port 1078 is actually open.
2. Are you clicking more than once within 15 seconds? Stop doing that.
3. Is the vehicle moving? Test it parked to rule out coverage.
4. Are you requesting the main stream? Drop to the sub-stream.
5. Looking for files under media.path? Don't bother — with JT808 they don't exist.

For a broader look at how camera support works in Traccar, see Traccar-compatible cameras.