Manual

1xx2 SDI Codec

← All manuals

Overview

The 1xx2 is a dual-role SDI codec: one encoder (SDI → IP) and one decoder (IP → SDI) running simultaneously on a single duplex SDI card's input and output. The device page stacks both roles:

  • Header: device name, online status, system metrics (CPU, RAM, Disk, Network ↑/↓ with a live throughput sparkline, temperature, uptime) and the device-level buttons: Manual, TS Streams, Diagnostics, Settings. TS Streams runs a short (~3 s) scan and lists the streams the box sees on the network - direction (In = received, Out = sent by this box), protocol (UDP, RTP, SRT, RIST - SRT/RIST are detected even when encrypted; RIST simple profile is plain RTP on the wire and shows as RTP), source, destination and measured bitrate; use Rescan to measure again.
  • Encoder panel: the SDI capture → H.264/H.265 → IP stream.
  • Decoder panel: the IP stream → SDI playout.

Both roles are managed independently; each has its own Start/Stop, configuration and log.

Signing In

The device UI is served over HTTPS (a self-signed certificate - your browser shows a one-time "not private" warning you can accept) and requires a login. A new device signs in with admin / admin - change the password on first use.

  • Change the password in the UI: top bar → Change password (asks for the current password; any other signed-in browser is logged out). Forgotten password? Over SSH: sudo fc-auth passwd. Your password survives every redeploy.
  • Sessions last 24 hours; use Log out (top-right) to end one sooner.
  • Locked out? After 5 failed attempts the account locks for 15 minutes. Clear it immediately with sudo fc-auth reset-lockout.
  • Central dashboard access: the Hub reaches this device with a per-device API key. Print it with sudo fc-auth show-apikey and paste it into the Hub's device settings (rotate with sudo fc-auth rotate-apikey).

Naming an Instance

Every encoder and decoder card shows a name - by default Encoder 1 / Decoder 1. Click the name (a pencil appears on hover) and type your own, e.g. Reuters or Camera 3; press Enter (or the ✓) to save, Esc (or the ✕) to cancel. Clearing the field restores the default numbered name. Names are up to 40 characters.

The name is stored on the device, not in your browser - every operator on every browser sees the same name, and it survives a restart or a reinstall of the UI. Renaming is metadata only: it never touches the stream, so you can rename a live encoder/decoder without interrupting the picture. The name is also used in the log and link-statistics windows and on the central dashboard.

An encoder's name also travels in the stream. It is written into the outgoing MPEG-TS service table as the DVB service_name, so a receiving headend or monitoring system shows your label rather than a generic one - HRT 2 erroring is a far more useful alarm than Service01 erroring. Alongside it the stream carries service_provider - the brand this unit was released under, which the Service Provider field shows you - and a service_id equal to the channel number, so on a multi-channel box every channel is a distinct service rather than sixteen copies of the same one. An encoder with no custom name sends that brand followed by the channel, … CH01, … CH02 and so on.

The name in the stream is read when the encoder starts. Renaming a running encoder still does not interrupt it, so the outgoing service table keeps showing the previous name until that encoder is next restarted. If a receiving system must see the new name immediately, restart the encoder after renaming it.

Instance Controls

Each encoder/decoder card has an icon-only control row (hover any icon for its label):

  • Start: starts the stream. Enabled only when stopped.
  • Stop: stops the stream. Always visible, so you can stop a stream even while it is still starting (useful to interrupt one stuck in a start/retry loop).
  • Restart: stop + start in one action. Configuration changes are applied on restart.
  • Preview: opens a live thumbnail preview of the actual stream content. The decoder preview is captured from its live input, so it is available only for network inputs (UDP/RTP/SRT/RIST); a decoder playing a local file or a test pattern shows a short "no live preview" note instead. On boxes with the CPU headroom for it the picture is captured continuously and appears at once; on the smaller boxes it is captured on request, so the first image takes a moment to arrive. Both show the same live content - only the wait differs.
  • View log: opens the per-stream log modal (see View Log below).
  • Settings: opens the stream configuration dialog.

📺 Live preview - a moving picture, and what it is not. Beside the thumbnail button there is a Live preview: the actual picture, moving, with sound. Use it to answer the things a still frame cannot - is the picture moving, is there audio, is this now or is it stuck.

⚠️ It is a confidence monitor and never a timing reference. It is delivered over the same web connection as this page and runs several seconds behind the real output. Never judge latency, lip-sync or timing by it. For that, take the SDI output - which is the thing this device is fast at.

It starts when you open the panel and stops when you close it. On an H.264 channel it costs the encoder nothing at all - the device does not make a second picture for you, it sends you the one it has already encoded, so watching a channel cannot slow it down. On an HEVC channel a browser cannot play what we encode, so there the preview does convert the picture as it goes, and that does use the chip. Either way only a small number can be open at once and the device refuses politely rather than slowing your contribution feed. If it says a channel is already being previewed, somebody else has it open.

On an H.264 channel with no proxy running, what you are sent is the full contribution feed - the real picture at its real bitrate. It is the sharpest the preview ever looks, and it is also the heaviest: over a VPN or a slow link expect it to stutter where the smaller picture would not. Turning on a proxy gives the preview a 720p copy to use instead, and it will prefer that automatically.

It works wherever this page works - on the local network, over the VPN, and over the internet link.

Status Meanings

  • 🟢 Running / Active: stream is up and processing normally.
  • 🟡 Unstable: running, but it has crashed and auto-restarted recently. The restart counter counts crashes since the last manual Start (pressing Start/Restart resets it). After 5 minutes of clean running the badge clears on its own.
  • 🔵 Starting (pulsing): the processing engine is initializing, typically 5–10 s (SDI card + GPU setup).
  • 🔴 Error / Failed: the stream could not start or has exited fatally. Open View log for the reason.
  • ⚪ Stopped / Inactive: not running.
  • 📡 No input (encoder): running, but no SDI signal is locked on the input. Check the camera/playout feeding the SDI port.
  • 🟡 No Output (decoder): the process is up, but no decoded frames are reaching the SDI output right now - a frozen output. It reads this instead of a green Running so a stalled output is never shown as healthy. It appears briefly at start-up (before the first frame) and if the input stops being decodable; a persistent No Output means the decoder is not producing a picture. Check the input is arriving and decodable (View log); the device restarts a stalled decode automatically within a few seconds.

Encoder Configuration (Settings)

Output Stream tab

  • Protocol: UDP (MPEG-TS), RTP, SRT or RIST.
  • SRT: caller/listener mode, latency (ms), optional passphrase + key length, stream ID.
  • RIST: main/simple profile, caller/listener, recovery buffer (ms), optional secret + cipher.
  • Destination IP / Port / Interface: where the stream is sent; the interface select controls which NIC sources multicast (it is greyed out for a unicast destination, which does not use it). A new box ships with the interface set to internal - 198.19.19.19. That is a virtual adapter inside the box, not a network port: it makes the out-of-the-box demo (encoder → its own decoder) work without putting anything on your network, so two new boxes on one network cannot interfere with each other. When you point this channel at a real multicast address on your network, change the interface to the port the stream should leave by - left on internal, a multicast stream stays inside the box and no one receives it. A unicast destination is unaffected either way.
  • ST 2022-7 dual path (second leg) (RTP only, and only on a box that has two connected network ports): see below.
  • Ancillary data (SMPTE 2038) (shown only on a build whose encoder carries 2038 support; off by default): carries the ancillary packets the SDI source sends - timecode, captions, teletext - through to the output as a SMPTE 2038 stream on its own PID (default 288, editable). Turning it on adds a PID and changes the PMT, so a headend receiving the feed must expect it; that is why a box never switches it on by itself. If the control is not shown, this box's software cannot do it and the device is telling you so rather than offering a switch that would do nothing.
  • Destinations: one encode can be sent to several places at once - the master control room, a monitoring wall and a CDN, from the same channel, with no splitter in front of the device. Each destination has its own protocol, its own address and its own QoS class, so a leg going out over the public internet and a leg on a managed link do not have to be treated the same. Add and Remove manage the list; the small toggle on each row takes one destination off the air without deleting it.

ℹ️ Each destination stands on its own. A destination that refuses packets, disappears, or is too slow to keep up is dropped on its own branch - every other destination keeps running and the encode is not disturbed - and it is picked up again automatically when it comes back. This is why one bad CDN cannot take your MCR feed off air.

ℹ️ Editing the list restarts the encode. Adding, removing or changing a destination is applied on the next start/restart like every other setting, and that restart interrupts every destination on the channel for roughly five seconds, not only the one you edited. Make list changes in one go rather than one at a time.

⚠️ Two destinations are not redundancy. Sending the same feed twice does not give you a protected path: hitless SMPTE ST 2022-7 protection needs the two copies to be byte-identical and merged on sequence number, which is a different feature. Two destinations are two independent deliveries - if one of them breaks, that one breaks.

↺ A removed destination is gone, including its history. Removing a destination deletes its link-statistics record, because the next destination you add takes the freed slot and would otherwise inherit the old one's graph. If you only want to stop sending for a while, disable it instead of removing it - a disabled destination keeps its place and its history. - Video Codec: H.264 or H.265 (HEVC). - Chroma / Bit Depth: 4:2:0 or 4:2:2, 8-bit or 10-bit. H.264 is limited to 4:2:0 8-bit; all four combinations are available with HEVC. 10-bit modes capture true 10-bit from the SDI input.

💡 For 4:2:2, use 10-bit. H.265 4:2:2 10-bit (Main 4:2:2 10) is the broadcast-standard profile, and this device encodes and decodes it at full rate. 4:2:2 8-bit also works at full rate here, but it is a non-standard profile that many third-party receivers cannot play back - use it only toward a receiver verified to support it.

⚠️ Interlaced sources are carried, but not flagged. An interlaced SDI input (1080i50, 1080i59.94, 1080i60) is captured with both fields intact, but the encoded stream is coded as progressive frames with no field-order signalling - neither H.264 nor H.265 signals interlace on this hardware. Our own decoder compensates: select the matching interlaced SDI mode on it and the picture is correct. A third-party decoder does not - it treats the frames as progressive and shows combing on movement. Measured 2026-08-31.

  • Video Bitrate: true CBR, 500–50 000 kbps.
  • Latency mode → Low latency (default): short GOP, no B-frames. The mode that keeps end-to-end delay lowest - measured 12 to 14 frames glass-to-glass (about 0.25 s at 1080p50), and under 1 s in every format and codec measured, SDI in to SDI out over a LAN. The delay is a whole number of frames of pipeline, and the frame count is fixed when the decoder joins the stream: expect it to land within a frame or two of the same value each time, and to change slightly if the stream is restarted.
  • Latency mode → Normal quality: quality first. B-frames, long GOP (1.6 s), lookahead rate control. Gains roughly +1–1.5 dB PSNR at the same bitrate, at the cost of several seconds of end-to-end latency. The GOP is a fixed duration, so it is the same at 24 fps as at 60 - there is no frame rate at which this mode behaves differently.

⚠️ Important. A decoder receiving a Normal-quality stream must have its Input Profile set to Normal quality too (see Decoder Configuration below).

ST 2022-7 dual path (second leg)

Sends a byte-identical copy of the same stream - same SSRC, same sequence numbers - out of a second network port, so a receiver that merges the two paths can lose one of them without a glitch in the picture.

Where the control is. In the Output Stream tab, under the destination, when Protocol = RTP. Tick it and fill in leg B's destination IP, port and interface.

If you cannot see the control at all, this box cannot do it, and that is the box telling you so rather than offering something that will not work. It needs two network ports with a cable in each. One port, or two ports with only one cable, and the option is not shown. Plug the second cable in and reload the page.

Choose the interface - do not leave leg B on "Auto". If both legs point at the same subnet, the box's routing table will happily send them both down the same wire. Everything reports success and you have no redundancy at all. The interface list marks any port with no cable as no link.

RTP only. Merging works on the RTP sequence number, and a plain UDP output does not carry one. Switch the protocol to UDP and the option greys out; the device also refuses the setting rather than quietly ignoring it.

Four things to know before you sell or rely on it:

  • This device does not merge on receive. The far end has to be an IRD or gateway that does 2022-7 merge. Two of these boxes cannot protect each other this way - use SRT or RIST for box-to-box.
  • It doubles the bandwidth. Two full copies of the stream, by definition.
  • It only helps against loss that differs between the two paths. If both legs share a congested link or the same last mile, the loss hits both copies identically and 2022-7 does nothing.
  • It does not protect against this box failing. One box, one encode. If the replicator process restarts, both legs stop for a couple of seconds.

Checking it is working. The encoder shows each leg separately with its own packet count, its last send error and the interface the traffic actually leaves by - read back from the system, not repeated from what you typed. If leg B shows the same interface as leg A, or shows errors climbing, it is not delivering a second path.

Proxy (monitoring copy)

  • Proxy: a second, low-bitrate 720p copy of the same channel, for monitoring and confidence viewing - so the 50 Mbps contribution feed is not what somebody watches on a laptop over a hotel link. It has its own bitrate and its own destination list, entirely separate from the main feed's.
  • The proxy is always H.264 4:2:0 8-bit with AAC audio, whatever the main channel is set to, and that is not a limitation to work around - it is the point. The proxy exists so that anything can play it, and a monitoring copy in the contribution format would defeat its own purpose.
  • Audio is the first SDI pair (channels 1+2), as stereo.

⚠️ The proxy is a second encode and it is not free. It is off by default for that reason. On this hardware the proxy and the main channel can share the same encoder engine, so switching it on takes capacity from the channel it is copying - how much depends on the box and on what the main channel is doing. Turn it on while watching the channel's frame rate, not afterwards, and do not assume a channel that was comfortable stays comfortable. On both shipping platforms the default 720p proxy beside a 1080p50 HEVC 4:2:2 10-bit 50 Mbps channel was measured to hold the full frame rate for 30 minutes: on the Core 3 304 with the video engine at about a third of its capacity, and on the N150 with the video engine under a third and the render engine, which carries the main encode there, at about a third. Other main-channel settings are not measured.

ℹ️ It is a separate service on the wire. The proxy carries its own service identity and its own PIDs, so a headend receiving both sees two services rather than one confused one. Its name is the channel's with PROXY appended.

MPEG-TS tab

How the stream identifies itself to a headend. This is the sheet a carrier hands you when it takes delivery of a feed, so the service identity and the PIDs live together.

  • Service Name and Service Provider: the two DVB SDT strings a monitoring wall shows for this channel - a fault report then reads "HOROR TV 1 is erroring" instead of "Service01 is erroring". Set them to whatever the receiving headend expects. Leave Service Name blank to use the encoder's own name, and Service Provider blank for this unit's own brand, the name it was released under. Max 31 characters each (DVB strings are short by spec); : and = are replaced with a space because they are separators in the underlying option syntax.
  • PIDs (Video / Audio / PMT): set explicit output PIDs for headends that expect fixed values. Leave a field blank for the default - video 256, audio counting up from the video PID + 1, PMT 4096. The video PID stays fixed however many audio tracks you map, so changing the audio mapping never moves it. The PCR rides the video PID and the PAT is fixed at PID 0, so neither is shown. The three PIDs must differ and fall in 32–8190; extra audio tracks count up from the audio PID (audio, audio+1, …).

ℹ️ The Service Name is not the encoder name. The encoder name is the label you read in this UI; the Service Name is what goes out on the wire. They are separate on purpose, because a headend often dictates the on-air name. Set only the encoder name and the wire follows it; set both and they can differ.

Audio tab

  • Codec: AAC (LC), MP2 (MPEG-1 Layer II), Opus or PCM (SMPTE 302M).
  • AAC (LC) - Low Complexity, the profile in every broadcast AAC spec. This is not HE-AAC; we do not emit SBR.
  • MP2 (MPEG-1 Layer II) - the long-standing DVB audio codec. Choose it when the receiving side is older set-top boxes, which list it on their datasheets as MPEG-1 Layer II rather than MP2. Mono or stereo only - it cannot carry more than two channels per track. MP2 also has a fixed bitrate table, so selecting it turns the Bitrate field into a list of the rates that are actually legal (64–384 stereo, 32–192 mono); a value that was legal for AAC is snapped to the nearest legal MP2 rate rather than saved and then refused at start.
  • Opus - modern and efficient, but its MPEG-TS carriage is not part of classic DVB, so verify the receiver supports it before choosing it toward a headend.
  • PCM (SMPTE 302M) - uncompressed, fixed rate, so no bitrate field.
  • Bitrate: 32–1024 kbps for the lossy codecs.
  • Channel → track mapping: choose which SDI embedded-audio channels go into which output audio track (e.g. tracks 1+2 and 3+4).
  • Lang (per track): the ISO 639-2 language code carried in the stream, written into the MPEG-TS programme table as the standard language descriptor. A receiving headend uses it to build its own audio component list, and a monitoring wall shows hrv, eng, deu instead of eight tracks all called "audio". Type a three-letter code (hrv, eng, deu, …) or pick one from the list; use und when the language is genuinely unknown. Leave it blank to send no language at all - that is the default and matches how the device behaved before.

ℹ️ One unreachable destination no longer stops the stream. Each output is delivered independently: a destination that refuses packets, disappears, or is too slow to keep up is dropped on its own while every other destination keeps running, and it is picked up again automatically when it comes back. This includes the internal copy the device uses for thumbnails, which is why it matters even with a single configured output.

⚠️ A destination that is dropped is silent, not loud. That independence is bought by letting a failing leg fail quietly. The channel stays green and its thumbnail keeps updating - the thumbnail comes from the device's own internal copy, not from your destination - so a destination that is configured but receiving nothing does not raise an alarm here. Check the Link statistics for that destination, or the receiving end, before concluding a delivery is healthy.

QoS

  • DSCP: 0–63 marking on the output packets (e.g. 46 = Expedited Forwarding) so network equipment can prioritize the stream. Leave it Unmarked to send no marking at all.
  • Per destination: a destination can carry its own DSCP value, which overrides the channel's for that leg only. Left on Inherit it uses the channel setting - that is not the same as 0, which is an explicit "best effort" marking and would override the channel.

↺ Getting back to a default. Optional boxes - the DSCP value, the service name and provider, and the three MPEG-TS PIDs - carry a small × while they hold a value. Clicking it returns that one setting to the device default (unmarked for DSCP; the encoder name and the unit's brand for the service strings; video 256 / audio video+1 / PMT 4096 for the PIDs) and the change is applied on the next start/restart like any other. Hovering the × says which default it will restore.

Expert mode

Everything on the tabs above is a setting we expect an operator to change. There is a second group - the encoder preset, the GOP size, how deep the encode pipeline runs, the transport stream ID and the PCR interval - that this device normally decides for you, from values measured on this hardware for the codec, latency mode, chroma and bit depth you picked. Expert mode opens those five.

Turn it on with the Expert mode switch at the top right of the settings window. The window gains an amber outline while it is on, so it is obvious you are in it, and an Expert tab appears. The switch is remembered in your browser; it does not change anything on the device, and turning it off does not undo an override you saved.

  • Blank means not set, and that is the safe state. A blank box hands the knob back to the tuned profile, and the value the profile is using is printed under the box (profile: veryfast). When you do set a value, the line shows both - what is applied and what the profile would have used.
  • Reset to default clears every override in one click. It is the same thing as blanking all five boxes, because reset and not set are one mechanism here, not two.
  • Every value is checked before it is accepted, and the reason is shown next to the field. A value that is legal but unusual is accepted with an amber warning rather than refused - a PCR interval above 40 ms, for example, works but is outside what ETSI TR 101 290 expects, so a broadcaster's analyser will flag your stream.

The five:

Setting What the profile does Why you might override it
Encoder preset veryfast where the measured cell needs the speed, medium otherwise A receiving end asks for a specific trade of quality against encode speed. Note that on the 4:2:2 path anything slower than medium produces the same output as medium.
GOP size (frames) 30 frames in low latency; in normal quality the device keys on a duration (1.6 s) instead A headend requires a fixed key-frame spacing. Setting this makes the spacing a frame count in both modes, so it means one thing wherever you read it.
Async depth 1 or 2 in low latency, 4 in normal quality Trading pipeline depth against latency. Deeper is not free: the same preset holds 50 fps at depth 4 and drops to 46.9 at depth 1 on the 4:2:2 path.
Transport stream ID not sent at all, so a receiver sees the standard default of 1 A headend addresses your multiplex by its TS ID. Set it and it appears in the PAT; leave it blank and nothing is emitted.
PCR interval (ms) 20 ms A receiver or analyser asks for a different clock-reference rate. Above 40 ms it is still sent, with a warning.

⚠️ These are the values the box was measured with. The defaults are not conservative guesses - they are what this hardware was tested at, for this exact combination of codec, latency mode, chroma and bit depth. Changing one can take a channel below real time without any error appearing: the encoder simply falls behind. After changing anything here, restart the channel and watch the live frame rate on the card before you rely on it.

ℹ️ Mux bitrate, B-frames, network ID and start PID are not here. Our transport is variable bitrate, so there is no mux rate to set and no null packets to pad with; the other three are part of a measured profile rather than a free knob. If you need one of them, ask - it gets a measurement and a proper control, not a text box.

Templates

A template is a complete, named set of those five settings, stored on this device. It is what you use when you have tuned a channel and want the same thing everywhere else.

  • Load into this form copies a template into the Expert tab you are looking at. Nothing has reached the encoder yet - press Save and close as usual.
  • Save as template stores the five values currently in the form under a name you choose, together with the codec, latency mode, chroma and bit depth you were working in, so the picker can show you what a template was tuned for.
  • Apply to other encoders is the one control here that does not wait for Save and close: it writes the template to the channels you tick, straight away. Each takes effect on that channel's next restart, and each reports on its own - if two of sixteen refuse a value, you get those two by name and the reason.
  • Export downloads a template as a file; Import a file loads one that came from another device. The file carries the name, the five values, the context it was saved in and its timestamps - and nothing else: no addresses, no stream IDs, no passwords, nothing about this device. It is safe to send to another site.
  • Profile defaults is a template we ship. It is empty on purpose - applying it is the same as pressing Reset to default - and it cannot be edited or deleted.

ℹ️ A template replaces, it never merges. Applying one sets all five fields, including the ones it leaves unset. That is deliberate: it means "enable this template" has exactly one meaning, and that applying two templates in a row can never leave you with a half-and-half configuration nobody wrote down.

ℹ️ When changes apply. Configuration is saved immediately but applied on the next start/restart. The event log records exactly which values changed, e.g. "Config updated: Video bitrate: 20001k → 20002k (applies on next start/restart)".

Decoder Configuration (Settings)

Input tab

  • Input Type: MPEG-TS (UDP), RTP, SRT, RIST, File playback, or a built-in Test Pattern (bars + tone) for SDI output checks.
  • MPEG-TS fields: multicast/unicast IP, UDP port, optional local interface IP for the multicast join. On a new box this is 198.19.19.19 to match the encoder's own output - the two are the ends of one on-box loopback, so they are changed together. Receiving from a remote encoder means clearing it or setting it to the network port the stream arrives on; left pointing at the internal adapter, the decoder waits on a wire nothing is sent to, which looks exactly like a dead source.
  • Source format is detected automatically - H.264, H.265 4:2:0 and H.265 4:2:2 (both 8- and 10-bit) each select the right decode pipeline on their own. The decoder reads the stream's format before its first start - a short probe of one to two seconds - and begins directly in the right pipeline, remembering the choice for that input; only if the source later changes format does it re-detect and adapt within ~40 seconds. If the stream is not arriving yet, the decoder reports the missing input and keeps retrying until it is.
  • Input Profile → Low latency (default): minimal receive buffering, ~150 ms standing latency. For short-GOP, no-B-frame sources (the 1xx2 encoder's Low latency mode).
  • Input Profile → Normal quality: deep receive buffer (~4 s capacity). For quality-first sources with B-frames and long GOPs (the 1xx2 encoder's Normal quality mode). Guarantees a clean start at any moment, adds up to ~2–3 s of standing latency.
  • SRT / RIST fields: same connection options as the encoder side (mode, latency/buffer, passphrase/secret).

⚠️ Match the Input Profile to the source encoder's latency mode. A decoder in Low-latency profile joining a long-GOP stream can land mid-GOP, overflow the receive buffer and produce a permanently corrupted picture (blockiness, smearing) with continuous "Circular buffer overrun" messages in the Process output log. Switching to Normal quality and restarting the decoder fixes it deterministically.

Output

  • SDI output mode: the video mode you expect on the SDI output (e.g. 1080p50). Set it to match the incoming stream.
  • Deinterlace: enable when feeding interlaced sources to a progressive SDI mode. Off + an interlaced mode = interlaced passthrough; on + a progressive mode = deinterlace to progressive at field rate.

⚠️ There is no scaling and no frame-rate conversion - the SDI output follows the stream. The raster and frame rate leaving the SDI connector are the ones that arrived: a 1080p25 stream goes out as 1080p25 even if this field says 1080p60. The setting does not convert anything. What it does control is the field flag for interlaced modes (1080i50/1080i59.94), which the card needs in order to emit a correctly flagged interlaced signal rather than progressive-segmented frames - so an interlaced source still needs an interlaced mode selected here. If the picture on your monitor is not the mode you expect, look at the source, not at this field.

ℹ️ The SDI output is 8-bit 4:2:2. Whatever the input stream is, the picture leaving the SDI connector is 8-bit 4:2:2 (uyvy422). A 10-bit source - including H.265 4:2:2 10-bit - is decoded at full 10-bit precision and then converted to 8-bit for playout. This matters only where the SDI output feeds something that itself grades or re-encodes; for monitoring and normal distribution it is not visible. The encoder side is unaffected - SDI capture is true 10-bit, so a 10-bit encode is genuinely 10-bit end to end over IP.

The decoder auto-detects the incoming stream (codec, resolution, frame rate) and shows it on the card and in the event log ("Input stream detected: h264 1920x1080 @ 50 fps").

ℹ️ A source with no audio plays out as video only. If the incoming stream carries no audio track, the decoder starts anyway and the SDI output simply has no embedded audio - it no longer refuses to start.

Audio: which channels reach SDI

The decoder embeds up to 16 audio channels on the SDI output. By default it embeds everything the incoming stream carries, in the order the tracks arrive, up to 16.

⚠️ This changed. Older software embedded only the first audio track, two channels, and discarded the rest without saying so. After an update a box that has not been reconfigured starts delivering the audio it was always being sent - which is the intended behaviour, but if a downstream device was relying on channels 3-16 being silent, it will now hear them.

The Audio tab lets you say exactly which incoming channel lands on which SDI channel. Each SDI channel names its source as track : channel, both counted from 0 - so 0:0 is the first channel of the first track, 1:1 is the second channel of the second track. Leave a row blank for a deliberately silent channel.

Why track:channel and not one flat list. The same 16 channels can arrive as eight stereo tracks, two four-channel tracks, or one track of sixteen. If the mapping were a single flat list of numbers, the moment the far end sent one track fewer every channel above the gap would shift onto the wrong SDI pair - silently, mid-event. Naming the track means a mapping keeps meaning the same thing when the source is reconfigured.

A channel whose source is not in the stream is silent, and the tab says so - with the reason ("input carries 2 audio tracks"). The decoder does not refuse to start and does not quietly fall back to the first track. If you see unexpected silence, that is the field to read.

The card shows how many channels are actually going out, and the widths are 2, 8 or 16 - those are the only widths the SDI embedder accepts, so a map of three channels goes out as eight with five silent.

Two behaviours worth knowing before you rely on it:

  • The decoder reads the stream before its first start - a probe of one to two seconds - and builds the audio mapping and the decode pipeline from what it finds, so a normal start involves no restart. It restarts only when the stream was not there yet at start (it retries until it is) or when the source changes its format or track layout later.
  • If a mapped audio track disappears while the decoder is running, the decoder restarts to rebuild the mapping - a brief interruption to the picture, not just the audio. A track that was never there in the first place is simply silence, with no restart.

A source with no audio at all plays out as video with no embedded audio, and the decoder keeps running.

✅ Supported decode formats. H.264 4:2:0 8-bit, and H.265 in 4:2:0 (8- and 10-bit) and 4:2:2 (8- and 10-bit) - every format this box can encode, it can also decode. After joining a quality-first (long-GOP) H.265 stream, expect a few seconds of picture settle before playout is stable; H.264 streams settle almost immediately.

ℹ️ H.265 4:2:2 - both 8- and 10-bit get the dedicated fast decode pipeline and play at full rate. Because that pipeline uses a deep receive buffer, a 4:2:2 source (either bit depth) carries a few seconds of standing latency, the same as the Normal quality input profile. 4:2:2 10-bit remains the recommended choice: it is the broadcast-standard profile and the one most third-party receivers accept.

View Log

The View log modal is the primary diagnostic tool. It polls the device every 3 seconds and has two tabs:

  • Events: timestamped lifecycle events such as registered on boot, auto-start, Start/Stop/Restart requested (and by whom: operator actions are logged), "Processing engine running", input locked/detected, SDI signal lost and recovered, configuration diffs, transport bridge activity, engine exits with return code, failures. Filter buttons switch between All and Warnings & errors.
  • Process output: the raw processing-engine output, a rolling window of the last 5 minutes, kept across restarts so a crash loop reads as one continuous log (each attempt starts with its own engine banner).

The Copy button copies the visible content (respecting the active filter) to the clipboard. The status badge in the title shows the live stream state.

Link Statistics (SRT/RIST)

When a stream uses an SRT or RIST transport, the device records the transport's own link-health reports and keeps them on-device: 10-second detail for 7 days and 1-minute summaries for 30 days. Two surfaces show them:

  • Live badge on the instance card (next to the encoder's output URL / the decoder's input): protocol, current round-trip time and link quality, e.g. SRT 12 ms · 100%. Green means clean; amber/red mean the last 10 s saw quality drop below 99.5 % / 95 %. Grey means no recent reports (e.g. a listener with no connected peer). Hover for the last-10-seconds detail.
  • Link statistics button (chart icon, shown only for SRT/RIST streams) opens the graphs dialog with range tabs 15 min / 24 h / 7 days / 30 days. The 15 min view refreshes live every 10 s; the others are historical.
  • One set of graphs per destination. A channel sending to several places shows each reliable destination separately, named as you named it. They are deliberately never combined into one line: averaging the round-trip times of two different links, or adding up their retransmissions, describes a connection that does not exist. A destination you have removed still appears while its history is inside the retention window, marked as no longer configured - the measurements were real and hiding them would make the graph disagree with what happened.

What the graphs mean:

  • Retransmissions per interval - how hard the error correction is working. Occasional small spikes are normal on a lossy path; sustained high values mean the network is struggling (raise SRT latency / RIST buffer, or fix the link). Retransmissions that succeed are not damage - a link can show thousands of retransmissions with a perfectly clean output.
  • Lost & dropped packets - actual damage: packets the transport could not recover in time (these reach the output as picture/audio errors). For SRT this damage is reported as Dropped (its TLPKTDROP counter); for RIST, Lost is what stayed unrecovered and Dropped is what arrived too late or overflowed.
  • Round-trip time - network latency between the two ends (average and worst per interval). SRT latency / RIST buffer should comfortably exceed several × RTT.
  • Bitrate - the transport's delivery rate; for RIST outputs a second series shows the extra retry bitrate spent on retransmissions.

The headline tiles above the graphs summarise the selected range: worst quality, average RTT, total retransmissions and total lost+dropped. Data collection needs no configuration - it is always on for SRT/RIST streams, and switching a stream back to UDP keeps the recorded history viewable for its retention window.

System Alerts and Alarm History

The central dashboard shows a strip of alert cards for this device. Eight are generic to every device in this range; the codec adds two of its own, so it can say something about the media path and not only about the computer running it.

Card What it measures Yellow Red
Ping reachability of the default gateway - no reply
CPU processor load ≥ 70 % ≥ 85 %
RAM memory in use ≥ 70 % ≥ 85 %
Network link utilisation of the busiest interface, plus link errors ≥ 70 % of link speed, or any link error ≥ 85 %, or ≥ 100 new link errors in one 30 s sample
Logs system errors in this boot - one or more
License perpetual, all-in - no expiry to report - -
Connection how many network interfaces are up - none up
Time Sync NTP synchronisation state unknown not synced
Pipeline (new) the encoder and decoder themselves: how many are running, whether one is in a restart loop, whether the SDI input has signal restarting, or no input signal a pipeline failed, or 3+ restarts in 5 minutes
SDI Card (new) the SDI card: is it there at all, and its FPGA die temperature ≥ 140 °C no card detected, driver unavailable, or ≥ 150 °C

ℹ️ A card can also say "Not measured", and that is a fourth state. Green means it looked and everything is fine; yellow and red mean it looked and found something. Grey "Not measured" means the check could not run at all, so the card is telling you nothing about the thing it names - and it is deliberately not counted as an issue and does not colour the device's health. A check that can never run on a particular box would otherwise leave that box permanently yellow, and an alarm that is never clear is an alarm nobody reads. If a card sits at "Not measured", the fix is to make the check possible, not to interpret the card.

ℹ️ The Logs card reads "Not measured" on this device. The codec service deliberately runs under its own restricted account, and that account is not allowed to read the system journal - so rather than reporting a clean journal it has not been able to look at, the card says so. Use Diagnostics or journalctl over SSH for the actual log. This is being addressed separately: switching it on also needs a filter for the routine firmware/BIOS lines every Linux boot produces, or every device in the fleet would show red on its first boot.

ℹ️ "No input signal" is yellow, never red. A box with nothing plugged into its SDI input is not broken, and an encoder that keeps retrying a missing signal must not look like a fault - otherwise operators learn to ignore red. Red on the Pipeline card means restarts that are not explained by the input: a genuine restart loop.

⚠️ The device health indicator now includes these two cards. The dashboard's per-device health (healthy / warning / critical) is derived from the alert cards, so from this release an SDI card at 141 °C colours the whole device yellow, and an encoder in a restart loop - or a card that has vanished from the driver - colours it red. That is the intent: those were exactly the faults that used to be invisible.

ℹ️ The two Ping figures are different measurements, and both are right. The central dashboard replaces the Ping card with its own round trip to this device, because that is the path it cares about. The device meanwhile records its own ping to its default gateway - which is the one it can keep recording when no dashboard is watching. A device whose gateway stops answering will show that in its own history while the dashboard still shows a green Ping.

Alarm history

The device now records its own health continuously, in the background, whether or not anyone has a browser open. That is the point: a fault that starts at 02:00 and clears at 06:00 leaves a record instead of a mystery.

Two things are kept:

  • Transitions - one entry each time a card changes state, with the previous state, the new state and the value that triggered it. Kept for 90 days. A new state has to survive two consecutive samples (60 s) before it counts, so a single busy moment is not an event.
  • Trends - for the cards that carry a number (CPU, RAM, link utilisation, ping round trip, SDI card temperature): one-minute minimum/average/maximum for 7 days, and hourly for 90 days. The SDI temperature series is the first continuous thermal record this product has had.

Sampling is every 30 seconds. The history lives on the device itself (/var/lib/1xx2/alerts.db) and is read back over the API:

GET /api/alerts/history?range=24h        # 1h | 24h | 7d | 30d | 90d
GET /api/alerts/history?range=7d&card=decklink

It is authenticated like every other route. Nothing is sent anywhere: the device does not phone home, the dashboard pulls. If the storage location is not writable the history switches itself off with one line in the log - it never stops the codec.

ℹ️ Other devices in this range inherit the two changed cards. The Ping and Network cards described above are shared code, so the encoders and decoders in the range report them the same way from their next software update onwards. The Pipeline and SDI Card cards are specific to this product for now.

Device Settings

The Settings button in the page header opens device-level settings:

  • General → Auto-start: when enabled, both streams start automatically when the device boots.
  • Network: per-NIC IP configuration written to the device's netplan. Each physical interface can be set to DHCP (automatic) or Static IP (address in CIDR form, e.g. 10.0.0.5/24, optional gateway, up to 4 DNS servers).
  • WireGuard: dial-home VPN tunnel for remote support. Device keypair (generate/rotate; the private key never leaves the device), hub peer configuration (public key, endpoint, allowed IPs, keepalive) and a live status strip (tunnel up/down, last handshake, transfer).
  • The tunnel is yours to open and close. The device dials out (UDP, to the support hub's public address); nothing on your side listens, nothing inbound is opened, and the hub sees only this device. With the peer configured, the Enabled switch on this tab is the whole control: switch it on for the hours you want remote support, Save, and the status strip shows the handshake within a few seconds; switch it off and Save to close the tunnel. Your firewall only needs to allow the device's outbound UDP to the hub's address and port shown in Server endpoint.

⚠️ Network changes auto-revert. In the Network tab, Save & Apply writes the netplan and applies it immediately, then arms a 120-second timer: if you don't confirm within that window the box rolls back to the previous network config, so a change that cuts your own connection to the device undoes itself. Confirm to keep it.

Software Updates

Application updates apply without a reboot and interrupt each channel for a few seconds. Platform updates - kernel, graphics driver, capture driver - need your consent and a reboot window, and never happen on their own.

Updates are uploaded to the device, not fetched from the internet: the box needs no internet access, no cloud account and no connection to anything outside your network. Open Settings → Software update, choose the package file you were sent, and confirm.

What the device checks before it unpacks anything. A package is refused, with the reason named, if it was not signed by us, if it arrived damaged, if it was built for a different hardware model, or if it carries kernel or driver content that does not belong in an application update. A refused package changes nothing on the device.

Channels that are on air. If any channel is running, the update is refused by default and the refusal names the channels, because applying one restarts the streaming engine. You can override it - you are then confirming that those channels may be interrupted.

If the update does not come up cleanly, the device puts itself back. After applying, the box checks that the daemon answers, that the capture card is present, that the video engine still reports the contribution format, and that every channel which was running before the update is running and producing frames afterwards. If any of those fails, it returns to the previous version by itself and the result is recorded as rolled back, with the reasons. A rollback is a normal, successful outcome of a bad package - not an error you need to clear.

ℹ️ Two versions are kept on the device, the current one and the previous one. The older one is removed only at the moment a new version has been confirmed healthy, never before - so there is always something to go back to.

Settings → Software update also shows what this box is running: the application version, and the kernel, graphics-driver and capture-driver versions. If one of those cannot be read, it says so rather than showing a blank - "could not read" and "not installed" are different answers, and the panel keeps them apart.

Troubleshooting

  • Encoder shows "no input": no SDI signal locked. Check the source device and cable; the event log shows "lost input lock" / "input lock recovered" with timestamps. The encoder recovers on its own once the signal returns.
  • Encoder won't start in Normal quality: open View log → Events for the failure reason; the last error is also shown on hover over the status badge.
  • Decoder picture is corrupted/blocky right after starting: Input Profile mismatch. The source has long GOP/B-frames but the decoder is in Low latency. Set Input Profile → Normal quality and restart the decoder.
  • Decoder restarts repeatedly / shows nothing on an H.265 4:2:2 stream: 4:2:2 sources (8- and 10-bit) are recognised by a short probe of the input before the first start, so the decoder begins in the dedicated pipeline without a restart - allow a few seconds to the first picture. If the source changes format while the decoder is running, expect one restart while it re-probes. Repeated restarts mean the input is not arriving, or is not what the source encoder says it sends: check the encoder's output address and port against the decoder's input.
  • One restart right after changing the encoder to Normal quality: expected. The decoder can land mid-GOP on the new long-GOP stream, exit once, and recover on the retry within a few seconds. A single restart at a format change is normal; repeated restarts are not.
  • A few seconds of disturbance right after the decoder joins an H.265 stream: normal settle on long-GOP H.265 sources (the decoder waits for the next clean recovery point); it clears on its own. If it persists beyond ~15 s, check the Input Profile.
  • Stream is "Unstable": it crashed and auto-restarted recently. Open View log for the crash reason (engine exit code, last output lines). The badge clears after 5 minutes of clean running, or immediately on a manual Start.
  • Stream stuck in "Starting": the engine may be waiting for input (encoder: SDI lock; decoder: UDP/SRT/RIST data). Stop is always available to interrupt it.
  • Configuration change has no effect: changes apply on the next start/restart. Check the event log for the "Config updated: … (applies on next start/restart)" entry, then press Restart.
  • No thumbnail in Preview: thumbnails are generated from the running stream; a stopped or just-started stream has no image yet. On a box that captures on request, allow a couple of seconds after opening Preview before treating a blank image as a fault. The decoder preview is captured from its live input - a decoder playing a local file or a test pattern has no live network stream to tap, so it shows a "no live preview" note by design (this is not a fault).

🔌 Integrations. The device exposes a REST API over HTTPS for automation: /api/encoders, /api/decoders, per-stream /start, /stop, /restart and /logs. Every route requires authentication - not only /api/*, but also the machine-readable API description at /openapi.json and the interactive browser at /docs. Send the device API key in the X-API-Key header (sudo fc-auth show-apikey), or use a login session. Only /api/health and /api/device-info are public.