Restream Connections vs Customer Accounts

The units that must stay separate

Start an IPTV connections vs customers comparison by naming each unit. A database total describes the customer population. An active-session total describes activity during a particular period. Neither label, by itself, explains the supplier’s connection limit.

The following matrix separates the records an operator needs from the rule a supplier must confirm.

Architecture determines source pulls

Shared relay and independent receivers

A relay sits between a source and viewers. In a shared-input design, the relay can receive a feed once and distribute it to several playback sessions. Flussonic documents inter-server restreaming with local repackaging, illustrating this capability.

Two independent receivers pulling the same feed create two input paths under that design. The channel name may match, but the source activity occurs twice. Count the receiving paths rather than assuming each channel name represents one input across the entire operation.

Direct playback has a different boundary: each player obtains media from the supplier without the operator’s shared relay. Identify that path before using relay-based arithmetic. A reseller panel login alone does not reveal the media path.

Persistent inputs and on-demand inputs

An input can remain active without a current viewer. Flussonic describes static streams that run continuously and on-demand streams that start upon request and can stop during inactivity. This is documented product behavior, not a universal setting for every panel.

For planning, check the actual input mode and shutdown behavior. A zero-viewer screen does not prove zero upstream activity. Recording, monitoring, or another receiver may also need review if those functions operate in the intended setup.

Examples with explicit counting assumptions

All figures below are hypothetical counts at one fictional instant, not measurements, package recommendations, or billing promises.

Assume 80 registered customer accounts, 24 active playback sessions, and four selected feeds. Each feed has one rendition. Exclude extra recording jobs, previews, retries, backup pulls, and idle persistent inputs. Each receiver in the first two scenarios pulls each of the four feeds once and reuses that input for its viewers.

Measure the actual busy period

Keep evidence aligned in time

Record source activity and playback activity over the same intervals. Comparing yesterday’s customer total with a source counter from a quiet morning cannot explain a busy evening.

Use this worksheet to prepare a capacity discussion. It lists evidence to collect, rather than prescribing untested panel menus or a fixed sampling duration.

Investigate counter differences

Check a mismatch before buying more capacity. Compare receivers, feeds, active jobs, and session-closing behavior. Flussonic’s HLS session example closes a session after a timeout following the last request. Do not assume every supplier releases a connection the moment a player closes.

HLS also uses playlists and media segments, as RFC 8216 describes. A request total therefore needs interpretation; it is not automatically a count of people or billable connections.

Keep credentials and private stream addresses out of shared worksheets. Use redacted receiver labels and session references that support investigation without exposing customer access.

Match the result to the supplier rule

Obtain a written explanation of the purchased unit before comparing a measured peak with an advertised allowance. A useful confirmation covers:

• 1
  Counting boundary: source pulls, playback sessions, or another stated measure.
• 2
  Aggregation: usage combined across credentials, receivers, panels, and locations.
• 3
  Session lifecycle: activity that opens a count and the condition that releases it.
• 4
  Extra activity: treatment of duplicate feeds, recordings, previews, and backup receivers.
• 5
  Access conditions: supported delivery workflow and applicable permitted use.
• 6
  Limit behavior: the documented result of reaching the allowance and the upgrade process.

Request an example matching your intended architecture. A rule for direct playback may not answer a question about several receivers sharing inputs. Keep the dated reply with the quotation so both records refer to the same service.

For an A2Z discussion, review our restream service options, then request a counting-rule confirmation for your setup. Include receiver count, delivery path, observed playback peak, and source activity. Confirm those details before selecting a connection allowance.

Avoid fixed customers-per-connection promises

No universal customers-per-connection multiplier follows from a registered-customer count. Even a measured viewing percentage answers only part of the question. The architecture and supplier rule still determine the relevant source-side measure.

Use this decision sequence:

• 1
  Identify whether players receive media directly or through a relay.
• 2
  Name the unit the supplier counts.
• 3
  Gather time-aligned records at that boundary.
• 4
  Explain duplicates, extra jobs, and session-release delays.
• 5
  Compare the resulting evidence with the confirmed allowance and intended use.

A source allowance also does not prove that your own delivery infrastructure can handle the planned outputs. Review that capacity separately. Keep bandwidth calculations, server sizing, and source purchasing units distinct.

FAQs