Input and output fields by transport¶
A reference for the fields of the “Input and output editor” window (Input and output editor): what each field sets, what values it accepts and how the input and the output of the same transport differ. The fields common to all transports and the techniques for working with the window are described on this page, the fields of individual transports on the pages below. The choice of the delivery protocol and the planning of a link are described in Planning and data transmission protocols, the processing of a stream on the node in Streamer: implementation details.
The captions of the transport’s own fields the interface does not translate: these are technical designations, and in any language they are printed in English. Here they are given exactly as in the window, together with the unit of measurement that the interface appends to the caption: “Latency (ms)”, “Client timeout (s)”. There is one exception — the login and the password of the PS1 and SRT inputs: they are drawn by a separate authorization block, and the captions “Login” and “Password” are translated there.
The set of fields depends first of all on the type of transport and on the direction: for one and the same transport the input and the output are different sets, so below they are described separately even where the captions coincide. Some fields, moreover, appear and disappear according to circumstances — according to whether the stream is SPTS or MPTS, to the listener or caller mode, to the decoder chosen and to whether automatic PID mapping is enabled.
The number of tabs in the window also varies. An input always has at least two — “Properties” and “MPEG-TS PID” — while the UDP, RTP, Pro-MPEG, PS1, SRT, RIST and TCP inputs and the file, pipe and std inputs gain a third one, “BISS”. An output has a single tab, “Properties”; the exception is the multiplexer output, which also has “MPEG-TS PID” (Multiplexer (muxer)). When there is only one tab, the tab bar is not shown at all.
The transport type is set by the “Type” field at the very top of the window: at creation it is a list of the available transports, at editing it is a read-only field, because the type cannot be changed (to change the transport, the point is re-created). Changing the type in the creation form clears all the filled transport fields — only the note, the pause flag and the domain catalog fields are kept.
Common fields¶
The Note field exists on an input and an output of any type; in the window it stands last, behind a separator.
Field |
Purpose |
Values |
|---|---|---|
Note |
An arbitrary note: the purpose of the point, the person responsible, the ticket number. Visible in the lists of inputs and outputs and in the expanded stream row. |
a string, empty by default |
Pausing is not configured in this window, although an input and an output do have a pause flag: it is controlled by the pause button in the row of the list of inputs and outputs. It is important to know this at creation: newly created inputs and outputs are created paused, and after saving they are enabled from the list. The order of the inputs, which sets the backup priority, is not edited here either — it is changed by dragging the rows (Source redundancy and distribution).
Two more fields are added only for the transports that go into the common domain resource catalog (UDP, RTP, Pro-MPEG, RIST, PS1 and SRT; Shared resource catalog) — in the window they stand as a separate group:
Field |
Purpose |
Values |
|---|---|---|
Peer note (meshwork library) |
A mark for this point in the domain catalog: by it a neighbouring node understands what resource it is seeing. |
a string, empty by default |
Peer private |
Do not announce the point in the domain catalog. The point keeps working, but neighbouring nodes do not see it and it does not appear in the “Library — this stream” window (Library — this feed). |
disabled by default |
The presence of these two fields does not yet mean that the point will get into the catalog. The rules are these: an output is always announced — both with multicast and with unicast; a UDP, RTP or RIST input only when its address is a multicast group; PS1 and SRT inputs are always announced, while a Pro-MPEG input is not announced at all, even though it has the fields (Shared resource catalog).
Common input fields¶
An input also has a group of synchronization settings — it relates not to the transport but to the processing of the stream on the node, and is therefore the same for all types. The composition of the group depends on the stream type: for the input of an SPTS stream it is all three fields, for the input of an MPTS stream only the last one.
Field |
Purpose |
Values |
|---|---|---|
Auto jitter buffer |
Automatic selection of the buffer size according to the input type (Synchronization). |
enabled by default; in the creation form it is shown disabled |
Jitter buffer (ms) |
The buffer size set by hand — it applies when automatic selection is off. |
from 10, default 500 |
PCR discontinuity window (ms) |
The window within which a PCR jump is considered acceptable; a larger jump causes a hard resynchronization. For an MPTS stream the same window is applied to every program of the multiplex (Per-program analysis). |
from 100, default 1000 |
PID selection and remapping, as well as the BISS keys, are set on separate tabs of the same window and are described in Input and output editor.
Required fields and value checking¶
Some fields are required — without them the node will not be able to establish a connection. While such a field is empty, the save button is unavailable and the message “The <caption> field is required” appears under the field itself. The message is shown only after the first change of the form, so a form that has just been opened looks clean even though saving is already blocked. Which fields are required is stated on the transport pages.
The remaining checks are performed as you type and block saving in exactly the same way:
Message |
When it appears |
|---|---|
“Minimum N”, “Maximum N” |
A number outside the field’s allowed range. |
“Must be 0 or 32–8190” |
A PID outside the allowed set: the values 1–31 are reserved, 8191 is the null PID. Zero means “as in the input stream”. |
“Must be N–M bytes” |
A passphrase of an inadmissible length. The length is counted in bytes, not in characters: a Cyrillic letter takes two bytes. |
“Must start with <scheme>” |
The address of an HLS input was entered without the |
An empty passphrase is not considered an error — it is the absence of encryption. A fractional value cannot be entered into an integer field at all: the field does not accept it.
The window’s checks repeat the node’s restrictions but do not replace them. The length of text fields and the uniqueness of numbers — for example, of a program number in a multiplex — are checked only by the node. The range check, moreover, is not performed for every numeric field: a field that has no default value rests at zero, and the window does not highlight it — too small a value in such a field will be noticed only by the node.
The paired lists in the window cannot be made inconsistent: PID remapping, track languages and RIST peers are all edited by rows, and a row is added as a whole.
The window does not hide a refusal by the node: it stays open with the filled-in form, and a bar with the node’s message appears at the top — as is, in English, since this is the text of the node itself and not of the interface. The entered values are not lost in the process.
One more difference between creating and editing is worth bearing in mind when reading the “Values” column. In the creation form some of the values are already set — those named below as a form value or as a default value — and they are saved along with the rest. The other fields the form leaves empty or at zero, and the node applies its own values to them itself. When an existing point is edited, a field that has never been set looks the same: empty, even though the node applies a default value to it.
Working with the fields¶
Paste URL. The button parses a link from the clipboard and lays it out into the address and port fields. The scheme is optional — address:port is enough; but if it is given, it must match the transport: udp:// for UDP, rtp:// or udp:// for RTP, prompeg://, rtp:// or udp:// for Pro-MPEG, tcp:// for TCP, ps1:// for PS1 and srt:// for SRT. When there is nothing suitable in the clipboard, the button is unavailable and explains: “There is no suitable address in the clipboard to paste”.
The button exists only where a point has an address-and-port pair: on the UDP, RTP, Pro-MPEG, TCP, PS1 and SRT inputs and on the UDP, RTP, Pro-MPEG and SRT outputs. The PS1 output does not have it — it only listens on a port — nor do the transports where the address is specified differently (RIST, HLS, RTSP, RTMP, file).
If the browser does not allow reading the clipboard, the button simply puts the cursor into the address field: a link pasted by hand will be laid out into the two fields just the same. This works without the button too — it is enough to paste address:port straight into the address field.
Choose from the library… The button opens the domain resource catalog right in the window and fills in the address of the chosen source instead of entering it by hand (Library sources). It exists only on the UDP, RTP, Pro-MPEG, PS1 and SRT inputs. For PS1 and SRT the peer address by which the peer is reachable is filled in, and for a neighbour from one’s own domain the Meshwork auto sign-in is enabled at the same time and the login and password are cleared.
Find a free port. Automatic selection is provided on the PS1 output and on SRT in listener mode: the port field can be left at zero — the hint says “0 = auto” — and the node will pick a free port when saving, while the button next to it picks one right away. If no free ports were found or the request failed, the window reports this and saving is not performed. On the other points the port is entered by hand, even where the node occupies it itself — for example on UDP inputs.
A field with automatic selection also has a soft check: if, while editing an already created point, you enter a port different from the saved one and it turns out to be busy, the warning “This port may already be in use on this node” appears under the field. It does not block saving.
Passwords and logins. The passphrase and password fields are shown masked; the “Show password” button reveals the entered value. Logins, on the contrary, are remembered by the browser after a successful save and offered at the next entry — in a single list for all transports, so a login entered once for RTSP will be offered on an SRT input as well. Passwords are never remembered.
Closing the window. If anything was changed in the form, “Cancel”, Esc and “✕” ask you to confirm discarding the changes; an untouched window closes at once.
