How Video CutterV2 works

This page explains what the Video CutterV2 is, what problem it solves, and how the pieces fit together. Read it first — the rest of the documentation assumes you know the concepts introduced here.

You do not need any technical background to read this page. Every term is explained the first time it appears, and the Glossary repeats all of them in one place.

What problem does it solve?

Take a single mat — mat 1. It usually has two cameras: one filming from the front, one from the rear. FR Recorder records both of them continuously, from the moment the mat opens in the morning until it closes at night.

So at the end of the day, mat 1 has produced two recordings: one long file from the front camera and one long file from the rear camera, each several hours long, each containing every fight of the day one after another.

Say forty contests were fought on that mat. Every one of them is somewhere inside both of those files. What is needed is one short video per fight, per angle:

   mat 1, front camera  ──►  one long recording  ──┐
                                                   ├──►  fight 1  front + rear
   mat 1, rear camera   ──►  one long recording  ──┘      fight 2  front + rear
                                                          fight 3  front + rear
                                                            …        …
                                                          fight 40 front + rear

Forty contests × two angles = eighty short clips — from one mat, on one day. Now multiply that by the number of mats.

That is the Video CutterV2's job. For every finished fight it cuts the matching piece out of every recording that covers that fight — front and rear, and any further angle the mat has — and saves each piece as its own file, named so that the rest of the system knows which fight and which angle it is.

It runs on a Windows PC at the venue and, without anyone watching it:

1. Asks JudoNet when each fight started and ended.
2. Asks the FR Recorders which recordings exist and where the files are.
3. Cuts the matching piece out of every recording that covers that fight.
4. Writes each clip, plus a small companion file, into an output folder.

JudoNet and FR Recorder are the two other programs at the venue — they are introduced in The three programs it works with.

From there the Video Ingester takes over: it uploads the clips, has them encoded, and attaches them to the right contest on the platform, where they can be watched online.

The word "cutting" is a little misleading, by the way. It does not mean editing. The CutterV2 never re-encodes or changes the picture — it copies a slice of the original recording, untouched, into a new file. That is why it can keep up.

The three programs it works with

The CutterV2 is one link in a chain. It cannot do anything on its own — it needs the programs on either side of it.

   ┌──────────────┐         "when did each fight happen?"
   │   JudoNet    │ ◄─────────────────────────────────┐
   │ (scoreboard) │                                   │
   └──────────────┘                                   │
                                              ┌───────┴────────┐
   ┌──────────────┐   "which recordings       │                │
   │ FR Recorder  │    exist, and where?"     │  Video         │
   │ (mat 1, 2…)  │ ◄─────────────────────────┤  CutterV2      │
   │              │                           │                │
   │  long .mp4   │ ──── reads the file ─────►│                │
   │  recordings  │      over the network     └───────┬────────┘
   └──────────────┘                                   │
                                                      │ writes one short clip
                                                      │ per contest per camera
                                                      ▼
                                              ┌────────────────┐
                                              │ output folder  │
                                              │  D:\exports\   │
                                              └───────┬────────┘
                                                      │
                                                      ▼
                                              ┌────────────────┐
                                              │ Video Ingester │ ──► the platform
                                              └────────────────┘

Key terms

Display modes: how the CutterV2 knows when a fight happened

This is the single most important idea in the whole program, so it is worth reading slowly.

The CutterV2 has no idea what is happening on the mat. It cannot see the video, it does not understand judo, and it never looks at the picture. All it has is a list of timestamps supplied by JudoNet.

Those timestamps come from the scoreboard. As the scoreboard operator runs the fight, the big screen changes what it displays. JudoNet writes down the exact moment of every change. Each kind of screen has a number, and those numbers are called display modes:

These names are shared across the scoreboard, JudoNet and the CutterV2, so a number always means the same thing wherever you meet it.

The usual run-up is white, then blue, then both — three cards in a row, ending with the one that names the round. So a normal fight leaves a trail of timestamps something like this:

10:14:02  mode 3   white competitor introduced
10:14:11  mode 4   blue competitor introduced
10:14:18  mode 5   both competitors + the round
10:14:22  mode 6   contest screen up (clock shown, hajime still to come)
10:17:48  mode 7   winner declared

10:14:02  mode 4   blue competitor introduced      ← first
10:14:11  mode 3   white competitor introduced
10:14:18  mode 5   both competitors + the round
10:14:22  mode 6   contest screen up (clock shown, hajime still to come)

The CutterV2 turns that trail into a start point and an end point:

• The end of the clip is the moment JudoNet marks the contest as finished. JudoNet sets that itself, a short while after the winner (mode 7) or no-winner (mode 13) screen appears, so the clip includes the final score and the bows.
• The start of the clip is chosen by you, using the Cutting Start Mode setting. You are effectively answering the question "how much of the build-up do you want in the clip?"

Choosing where the clip starts

Why Automatic and not one of the others

Automatic takes the earliest timestamp the contest actually has, out of modes 3, 4, 5 and 6. It adapts to each contest individually. The four named modes commit the entire event to one specific screen, and that turns out badly for three independent reasons — any one of which is enough on its own:

1. The mode names say which competitor, not who goes first. Which judoka is introduced first is a scoreboard setting. Mode3 (White) selects the screen showing the white judoka, whenever that appeared — it does not mean white goes first. Pick Mode3 at an event that introduces blue first, and every clip is missing the blue judoka's introduction.
2. The ceiling frequently overrides your choice anyway. A full introduction runs 30–40 seconds, and Maximum mode time defaults to 30 — so naming Mode3 usually produces exactly the same clip as naming Mode6, and contests whose introductions differed by a few seconds come out cut differently. See the worked example.
3. The setting is not saved. It reverts to Automatic every time the CutterV2 starts. So a named mode silently applies to some sessions and not others — the second day of an event will not match the first unless somebody remembers to set it again.

None of these produces an error, a warning, or a log line. The clips are simply cut differently from what you intended, and it is normally discovered days later.

What the five choices actually do

The safety net: Maximum mode time

This exists because scoreboard operators are human. If the operator leaves an introduction screen up for four minutes while waiting for a judoka to appear, a clip that started there would carry four minutes of dead air. The Maximum mode time setting (default 30 seconds) puts a ceiling on that: when you have named a specific mode, the clip never starts more than that many seconds before the contest screen (mode 6).

With the default of 30 seconds, and Mode3 selected:

• White was introduced 12 seconds before mode 6 → the clip starts 12 seconds early. ✅
• White was introduced 4 minutes before mode 6 → the clip starts 30 seconds early, not 4 minutes. ✅

Reference: exactly how the start point is calculated

The rules

The ceiling does not apply in every case. Every value below is a timestamp; max is the Maximum mode time.

Three things follow from that table, and all three surprise people:

• Mode6 does not start the clip at the contest screen. It starts Maximum mode time before it — 30 seconds of run-up by default. For the latest possible start you need Mode6 and Maximum mode time set to 0, and even that begins when the contest screen appeared, which is still before hajime.
• Automatic is not capped. It starts at the earliest mark the contest has, however early that was. A contest that sat on its introduction screen for four minutes gets a four-minute run-up. This is rare and harmless, but it explains why one clip is occasionally much longer than the rest.
• Naming a mode that did not happen is not an error. Select Mode5, and a contest that went straight to the fight without ever showing the "both competitors" card is still cut — it simply falls back to mode 6 − max, exactly as if you had selected Mode6. Nothing is skipped and nothing is logged.

A worked example of all five choices

Take a contest where the scoreboard behaved perfectly. Each card is displayed for about ten seconds, and JudoNet reports the first timestamp of each group:

10:00:00 – 10:00:10   mode 3   white          → mode_3 = 10:00:00
10:00:10 – 10:00:20   mode 4   blue           → mode_4 = 10:00:10
10:00:20 – 10:00:30   mode 5   both + round   → mode_5 = 10:00:20
10:00:35 – 10:04:00   mode 6   contest screen → mode_6 = 10:00:35
10:04:05 – …          mode 7   winner         → mode_7 = 10:04:05

With Maximum mode time left at its default of 30 seconds:

Two things are worth staring at:

• Mode3 and Mode6 produce exactly the same clip here. Because the full introduction is longer than the ceiling, naming mode 3 achieves nothing — the ceiling overrides it. This is not a fault; it is the ceiling doing its job. But it does mean Mode3 is frequently not what people think they are asking for.
• Automatic is the only choice that captured the whole introduction, precisely because it is not subject to the ceiling.

Now imagine the operator on the next mat is half a second quicker on each card, so the gap from mode 3 to mode 6 is 29 seconds instead of 35. That contest, cut with Mode3, starts at mode 3 — a 29-second run-up — while the one above started at the ceiling. Same setting, same event, two different results. This is the inconsistency the ceiling introduces when it is set close to the natural length of an introduction.

Which "mode 6" is that?

A contest produces many mode-6 packets, not one. The scoreboard returns to the contest screen after every osaekomi display, every score, every trip into golden score.

JudoNet sends the CutterV2 the earliest of them. So mode 6 means the moment the contest screen first appeared — the start of the fight — and returning to that screen later in the fight does not move it. The CutterV2 only ever receives this one resolved number per mode; it never sees the individual packets.

That is the whole answer for a contest that was fought once, which is nearly all of them.

The other end of the clip is resolved by JudoNet in the same pass. finished_at is the winner (mode 7) or no-winner (mode 13) timestamp plus a threshold configured in JudoNet (20 seconds by default), capped at the last packet recorded for the contest — and it is not published at all until at least 30 seconds have passed since that screen appeared. That delay is why clips appear about half a minute after a fight ends.

Matching a fight to a recording

Knowing when a fight happened is only half the problem. The CutterV2 also has to work out which file to cut it out of. It asks every selected FR Recorder for its list of recordings, and then keeps only the recordings that satisfy all of these:

1. Right mat. The recording's scene key is exactly mat followed by the contest's mat number — mat1 for a contest on mat 1.
2. The recording started before the clip should start. A recording that began after the fight was already under way cannot contain the beginning of it.
3. The recording was still running after the fight ended. A recording that stopped mid-fight cannot contain the end of it.
4. The camera angle is one you asked for, if you filled in the Camera Angles field. If you left it empty, every angle is cut.

Everything that survives becomes a cut job: one contest × one camera = one job.

The queue and the cutting processors

Jobs do not get cut the instant they are created. They go into a queue, and a small pool of workers — the cutting processors — take them one at a time.

There are two queues:

• a high-priority queue, for cameras whose key contains the word Front;
• a normal queue, for everything else.

A processor always empties the high-priority queue first. The reason is simple: the front camera is the angle almost everybody watches, so it should be ready first. The rear angle of a fight from an hour ago can wait behind the front angle of the fight that just finished.

By default there are three cutting processors, so three clips are produced at the same time. You can set anything from 1 to 4 in the Settings tab.

Whatever number you choose, the CutterV2 creates one more on top of it, reserved for manual cutting and for the test cutting button. So 3 gives you three automatic processors plus a fourth for manual work; 4 gives you four plus a fifth. The extra one never appears in the progress list and does not compete with automatic cutting — it only does something when you cut something by hand.

Each processor checks the queue on its own slightly random schedule — roughly once a second — so that all of them do not wake up at the same instant and fight over the disk.

The two cutting engines

The CutterV2 can cut a clip in two different ways, and it chooses automatically.

MediaLooks — the careful one

The default engine. It reads the source recording frame by frame and writes the frames it wants into the new file. It works even while the recording is still being written — which is the normal situation during a live event, when the camera is still rolling.

Because video is not stored as a series of independent pictures, it cannot start at any arbitrary frame. It has to start at a keyframe (an I-frame), which is a frame that can be decoded on its own. MediaLooks therefore searches backwards for the nearest keyframe before the requested start. In practice this means a clip can begin a fraction of a second earlier than you asked. This is normal and not a fault.

When it has finished, the CutterV2 measures the resulting file and compares it with the length it expected. If the two differ by more than 2 seconds, the clip is treated as an error rather than being quietly published. The idea is that a truncated clip is worse than a missing one, because a missing one is visible on the statistics panel and a truncated one is not.

FFmpeg — the fast one

FFmpeg is a separate, well-known tool that ships with the CutterV2 and is used for a straight stream copy: it finds the requested section and copies the bytes across without decoding anything. It is dramatically faster — seconds instead of minutes — but it can only be used on a recording that is finished, because it needs the file to be complete and consistent.

The CutterV2 therefore uses FFmpeg only when it is sure the recording is no longer live:

• for automatic cutting, when FR Recorder reports the recording as not live;
• for manual cutting, when the source file has no half-written working file beside it, or when the recorder has not written a new frame to it for more than 30 seconds.

This is what makes cutting after the event so much faster than cutting during it. It is also why the setting is called Use FFmpeg for non-live recordings and not simply Use FFmpeg.

What comes out: the clip and its companion file

Every successful cut produces two files in the output directory:

cont_cup_jun_mac2026_0007_m_p100_0009__mat1__Front.mp4
cont_cup_jun_mac2026_0007_m_p100_0009__mat1__Front.mp4.json

The video file name is built from three parts joined by double underscores:

`<contest code>__<scene key>__<camera key>.mp4`

The .json file is the companion file. It holds everything the Video Ingester needs — the contest code, the camera, the timings — so that the clip can be uploaded and attached to the right fight with nobody typing anything. This is the whole reason the two programs work well together.

What happens minute by minute during an event

Once you press Start cutting, this loop runs on its own until you press Stop:

every 20 seconds
        │
        ▼
 ┌────────────────────────────────────────────┐
 │ 1. Is there still room on the output disk? │ ── less than 5% free ──► STOP, warn
 └────────────────┬───────────────────────────┘
                  ▼
 ┌────────────────────────────────────────────┐
 │ 2. Ask JudoNet for the contests of this     │ ── unreachable ───────► STOP, warn
 │    competition                              │
 └────────────────┬───────────────────────────┘
                  ▼
 ┌────────────────────────────────────────────┐
 │ 3. Keep only contests that are FINISHED     │
 │    and pass your include/exclude filters    │
 └────────────────┬───────────────────────────┘
                  ▼
 ┌────────────────────────────────────────────┐
 │ 4. Ask every FR Recorder for its recordings │ ── unreachable ───────► STOP, warn
 └────────────────┬───────────────────────────┘
                  ▼
 ┌────────────────────────────────────────────┐
 │ 5. Match contests to recordings, create     │
 │    one job per contest per camera           │
 └────────────────┬───────────────────────────┘
                  ▼
 ┌────────────────────────────────────────────┐
 │ 6. Skip anything already cut, already       │
 │    queued or already being processed        │
 └────────────────┬───────────────────────────┘
                  ▼
 ┌────────────────────────────────────────────┐
 │ 7. Put the rest in the queue                │
 │    (Front cameras first)                    │
 └────────────────────────────────────────────┘

meanwhile, continuously
 ┌────────────────────────────────────────────┐
 │ 1–4 cutting processors take jobs from the   │
 │ queue and write clips + companion files     │
 └────────────────────────────────────────────┘

Because a contest only enters the queue once JudoNet has marked it finished, clips appear roughly half a minute to a minute after each fight ends. That lag is expected.

Why it stops itself

The CutterV2 would rather stop and tell you than carry on producing rubbish. It shuts automatic cutting down, with a message on screen, when:

Error pop-ups are deliberately rate-limited — at most one every two minutes for JudoNet problems — so a network outage cannot bury the screen under identical dialogs.

What the CutterV2 does not do

Being clear about the boundaries saves a lot of time when something goes wrong:

• It does not upload anything. That is the Video Ingester.
• It does not record anything. That is FR Recorder.
• It does not know the result of a fight, who won, or the score. It only knows when the scoreboard changed.
• It does not re-encode video. The clip is a copy of the original, at the original quality.
• It does not survive a restart with its queue intact. The queue lives in memory. If you close and reopen the program, the queue is empty — but nothing is lost, because on the next Start cutting it re-reads the output folder, sees what is missing, and simply cuts it again.

Where to go next

• Installation and setup — getting the program onto a PC.
• Using the Video CutterV2 — the day-to-day walkthrough for an event.
• Settings reference — every setting explained.
• Troubleshooting — when it does not do what you expect.