Source line terminology
Source line is a commercial label with variable usage. Ask for a written definition alongside the offer. Use the following distinctions to read that definition.
| Term | Meaning in this guide | Responsibility | Separate from |
|---|---|---|---|
| Source account | Access identity and associated supplier terms | Supplier issues access; operator protects it and follows the terms | A single channel or active session |
| Channel feed | A particular media input or presentation | Supplier provides the input; receiving system selects it | The account used to request it |
| Access endpoint | Address used to request a catalog or media resource | Supplier provides the address; receiver uses the required access method | A guaranteed capacity or permission |
| Connection allowance | Limit on an activity defined by the provider | Supplier defines the rule; operator checks usage against it | Total registered customers |
| Customer line | Subscriber access record in a delivery platform | Operator or reseller manages the permitted customer fields | Source ownership or an administrator login |
For example, an account may expose multiple permitted feeds while allowing only a defined amount of active use. The feed list and active-use allowance answer separate questions. A catalog with many entries does not establish the number of sessions the account can use.
Keep the supplier’s exact terminology in your records, then add these working definitions beside it. This avoids changing the meaning between a quotation, a panel screen, and a support conversation.
Source account, endpoint, and individual feed
Access details and playlist resources
A source account identifies permitted access. An endpoint identifies a resource to request. Credentials may accompany the address or appear within a supplied URL, so treat source details as private.
M3U is a playlist format. Xtream-style login describes an access workflow, commonly using a server address, username, and password. Neither term alone specifies the supplier’s connection-counting rule or grants redistribution permission.
An HLS playlist is another useful distinction. RFC 8216 describes media playlists that refer to media segments and master playlists that refer to alternative streams. Receiving playlist text is therefore different from receiving all the video it describes.
This example contains no credentials. Its path suggests an HLS resource, but the address alone cannot establish authentication, actual content, capacity, or allowed use. Do not copy real source URLs into public documents or screenshots.
Channel feeds and stream identifiers
A channel label helps a reader recognize content. A stream identifier helps a system select a record or resource. Neither proves that two entries use the same underlying feed.
Two entries bearing the same channel name may represent different resolutions, languages, or delivery paths. Record the actual feed identifier and selected variant during an authorized evaluation. A channel count should not substitute for an access specification.
Source allowance versus customer account
A customer account is a stored access record. A viewer is a person or device using playback. An upstream pull is the receiving system obtaining media from a source. Keep all three visible in a service discussion.
| Observation | Supported reading | Unsupported reading |
|---|---|---|
| A customer record exists | The platform holds access settings for that customer | The customer is watching now |
| A customer is playing media | A playback path is active | Exactly one billable source unit is in use |
| A receiving system pulls a feed | Media enters that system from the source | Exactly one downstream customer is watching |
IPTV CMS’s Zeus documentation gives one concrete implementation: a subscriber line stores access settings such as expiry, connection cap, and content grants separately from the administrator or reseller account. That is an implementation example, not a specification for every panel.
Reseller credits belong to another layer: the provider’s commercial allocation rules. Do not convert credits into source connections or subscription months without the applicable credit schedule. Saved device logins also need separate treatment from concurrent playback.
Example delivery architectures
These hypothetical examples compare two viewers selecting the same feed. Assume one selected rendition per viewer, no recording or monitoring pulls, and no retry overlap. The relay example additionally assumes the system really shares one source input. No example describes A2Z’s deployed infrastructure or measured billing.
Each viewer receives media from the supplier. In this simplified model, two independent playback sessions reach the source. An operator’s customer database may still manage access, but the media does not pass through an operator relay.
Count the playback sessions at the source boundary separately from the customer records. The supplier must confirm the billable unit.
A receiving system pulls one feed and distributes that input to two viewers. Under the stated assumptions, this model has one shared upstream input and two downstream outputs. The operator handles the relay and its downstream delivery requirements.
MediaMTX documents source selection, on-demand pulling, and reader limits as separate configuration controls. This illustrates the distinction between an input and readers. It does not establish that every panel shares pulls or that a supplier bills one input as one connection.
A service directs viewers to another media address instead of carrying the media itself. In this example, both viewers then receive media from the supplier. An operator-facing address does not, by itself, prove that a relay carries the video.
| Hypothetical path | Receiver at the source boundary | Downstream playback |
|---|---|---|
| Direct | Two independent viewer sessions | Supplier serves both viewers |
| Shared relay | One shared operator input | Relay serves two viewers |
| Redirected | Two viewer sessions after redirection | Supplier serves both viewers |
These are topology counts, not package recommendations. HLS can involve repeated playlist and segment requests during one playback session. HTTP requests, transport connections, playback sessions, and billable units are different measures. Do not derive the supplier’s invoice from a diagram alone.
Provider-specific counting questions
Request answers that describe observable behavior and the relevant counting layer. Use this confirmation card before comparing offers:
- 1Resource supplied: Confirm whether source line means an access account, individual feed, or active-use allowance.
- 2Counted activity: Ask whether the limit applies to upstream pulls, downstream playback, or another defined unit.
- 3Account and network limits: Confirm any per-account, device, IP, server, or territory conditions.
- 4Access method: Ask whether the rule differs across supported delivery methods or output formats.
- 5Session release: Confirm the inactivity period and treatment of reconnecting or overlapping sessions.
- 6Additional activity: Ask how recording, backup inputs, previews, and monitoring are treated.
- 7Access term: Record expiry, renewal conditions, included categories, and permitted use.
Prefer a written example that matches your intended delivery path. Ask the supplier to identify the usage counter and explain its units. Compare that explanation with an authorized evaluation before making a capacity decision.
Content Rights Notice: Technical access does not establish content rights. Obtain the applicable distribution and territorial permissions separately. A playable feed, channel logo, or VIP label does not supply that evidence.
Frequently Asked Questions
Ready to Evaluate Source Feeds for Your Panel?
Discuss stream formats, connection limits, and technical integration directly with A2Z IPTV technical operations.