Karhu Player · in development · not released
Karhu Player.
A media player for people who have to trust the timecode. It plays a file or a stream and tells you what is in it: the frame you are on and its SMPTE timecode, the loudness of what you hear by EBU R128, the decoded value of any pixel, and what the file says about itself against what it actually does. It is made by the people who make Rytmi, it runs on Linux and Windows, and it will be free of charge.
It is not released: there is no download and no date. This page says what it does today, what it plays, what we have measured, and what we do not claim, so that when it is released it can be checked against what was said here. Everything on this page is as of 25 Oct 2026 unless it carries another date.
What it does
As of 25 Oct 2026, in the build we test.
- Frame-accurate transport. Step one frame back or forward, seek to a frame, a timecode or a time, and land on exactly that frame, B-frames and long GOPs included. SMPTE timecode is read from the file, drop-frame included; play, pause, an A–B loop, and J-K-L shuttle, forward only, from a quarter speed to eight times, with sound kept at its own pitch from half speed to double.
- Loudness by EBU R128. Momentary, short-term and integrated loudness and true peak of what is heard, each channel weighted from the stream’s own layout, and a separate measurement of the whole file from start to end.
- The picture as decoded. The Y′CbCr and RGB values of the pixel under the cursor, and any frame saved as a PNG. Each frame is drawn with the colour matrix its file declares; BT.2020 and P3 standard-dynamic-range pictures are converted to BT.709’s gamut, and the stream panel says when they were.
- What the file says against what it does. Codec, size, pixel format, colour tags and frame rate, with the frame rate the file declares checked against the one it actually runs at. For MXF, what the wrapper says (its operational pattern, field order and audio track map) is read and shown, and its field order is checked against the picture inside it.
- Sound held to its picture, with a trim to move it earlier or later, and a readout of how closely it is following. The readout measures the player’s own tracking; it cannot see the delay a display or a headset adds, which is why we measure that on the screen (below).
- Output to a chosen screen. The picture can be sent full screen to a named display. The main display is left out of that list, so the player cannot cover the screen you are working on unless you ask it to.
- Hardware decoding where the graphics hardware offers it (VA-API on Linux, D3D11VA on Windows), with software decoding where it does not; on Linux with Intel graphics, hardware-decoded frames are drawn without copying them back to the processor and up again.
What it plays
As of 25 Oct 2026. Every codec below is compiled into our build and checked to be there; H.264, AV1, MPEG-2, ProRes, DNxHD and DNxHR, v210, MPEG-4 Part 2, VP8, AAC, Opus and PCM are also played by tests of ours.
| Containers | MP4 and MOV, Matroska and WebM, MXF, MPEG-TS; HLS streams, on demand and live |
|---|---|
| Video | H.264, VP9 and AV1; MPEG-2 (its 4:2:2 profile included), ProRes 422, DNxHD and DNxHR, and v210; MPEG-4 Part 2, H.263 and VP8 |
| Pictures shown | Planar 4:2:0 and 4:2:2, at 8 and 10 bits, limited or full range. 4:2:2 since 25 Oct 2026, drawn as it is coded, each line with its own colour |
| Audio | AAC, MP3, FLAC, Opus, Vorbis and PCM, in a file that also has a picture |
Its media libraries are FFmpeg’s, built by us from FFmpeg’s own source under the GNU Lesser General Public License (LGPL) version 2.1, with nothing licensed under the GPL inside them. Their source and the script that built them will be published beside each download. Why we build them ourselves is in the archive: why we build our own FFmpeg.
What we have measured
Each figure with when and how it was taken. These are measurements on the machines named below, not guarantees for any other.
| Measurement | Value | When and how |
|---|---|---|
| Sound against its picture, seen and heard positive: the sound arrives after its picture | +9.9 ms Ubuntu +21.5 ms Windows |
24 Oct 2026, the mini PC below on one monitor and one USB headset: a camera and a microphone recording the screen and the earpiece together, and a clip that flashes and beeps once a second. The tolerance EBU R37 sets for a broadcast chain allows the sound up to 60 ms late. How it was measured, and what it found on the way, is in the archive. |
| Seeks and go-tos that land on the frame asked for by time, frame number, timestamp and timecode | 156 of 156 | Our frame-accuracy test, which reads a barcode burnt into every frame of three test files, B-frames included: on the mini PC under Windows, 25 Oct 2026; first on Linux in July 2026. |
Integrated loudness against FFmpeg’s ebur128 filter |
0.03 LU apart | A steady 1 kHz tone, 12 s; true peak 0.01 dB apart. The mini PC under Windows, 25 Oct 2026. One test signal: it exercises neither the gating nor the channel weighting, and is not the EBU Tech 3341 test set. |
| 4:2:2 pictures as drawn against our own processor conversion | 1.5–1.7 levels | The mean difference, in 8-bit levels, between the picture drawn on the graphics card and the same frame converted on the processor by the player’s pixel probe, for ProRes 422 HQ, DNxHR HQ and HQX, MPEG-2 4:2:2 in MXF, v210 and H.264 4:2:2 test files. The two differ where colour changes, because the graphics card blends between colour samples and the probe takes the nearest one; the same picture in 4:2:0 differs more (2.4), as it should, since 4:2:2 carries colour for every line and 4:2:0 for every other line. The laptop below, 25 Oct 2026; the mini PC under Windows gave the same figures, on a graphics adapter the test does not name. |
Where it is tested
As of 25 Oct 2026, on two machines, both with Intel graphics. Until 7 Oct 2026 it was developed on a laptop with AMD Radeon Vega graphics under Linux; nothing since, the path that draws hardware-decoded frames in place included, has run on AMD graphics.
- A laptop, a Lenovo ThinkPad E16 Gen 3 with an Intel Core Ultra 7 255H, under Ubuntu 24.04 LTS: where it is developed, and where every change is tested.
- A mini PC, a GMKtec NucBox G3 with an Intel N100, under Windows 11 and under Ubuntu 24.04 LTS, on an ordinary monitor and USB headsets: where the Windows build is tested, and where the sound and picture above were measured.
What we don’t claim
- Tested on Intel graphics only. As of 25 Oct 2026 the player is tested on Intel graphics. It ran on AMD Radeon Vega graphics under Linux until 7 Oct 2026, and not since; it has never run on NVIDIA graphics, and on Linux it has no NVIDIA decoding path.
- The sound sits 10 to 22 ms after its picture on the set-up we measured, by latency that no device reported to us. We have not corrected for it, and we have measured one display and one headset.
- Not every picture is shown. 4:4:4 (ProRes 4444, DNxHR 444), 12-bit, RGB, and packed or semi-planar 4:2:2 pictures (UYVY, NV16, P210) are not drawn: the file plays, with its sound, timecode and loudness, and the picture area names the format it could not show. HDR (PQ and HLG) is not tone mapped, and the stream panel says so. Interlaced video is shown as it is coded, both fields in one frame, not deinterlaced.
- The Windows program is not code-signed. Windows’ Smart App Control judges an unsigned program file by file, and on our mini PC it refused one of our test programs and allowed it four minutes later.
- A graphics driver reset ends the player. It does not recover from one.
- No macOS, and on Linux the native Wayland window is not measured: every measurement on Linux has been taken through X11 on Xwayland.
- Computer displays only. The picture goes to the computer’s own displays: there is no SDI or IP output, and captions and AFD are not shown.