Video CDN for streaming: what the delivery layer does for you
Video CDN for streaming on Flicknexs: adaptive HLS through the delivery layer, signed URLs with an expiry, referer protection, bandwidth included per plan.
Flicknexs delivers every title as adaptive-bitrate HLS through an included delivery layer, with a signed-URL flag and time-to-live in storage settings and a bandwidth allowance stated per plan on our pricing page.
Trusted by industry leaders
50+ OTT platforms powered by Flicknexs
Quick answer: A video CDN for streaming is the delivery layer that serves video segments from servers near each viewer, so playback starts fast and holds its quality under load. Flicknexs includes that delivery layer and a bandwidth allowance in every plan, serves adaptive-bitrate HLS, expires playback links through signed URLs, and configures referer protection on request.
Flicknexs provides video cdn as part of its white-label OTT platform. Flicknexs delivers every title as adaptive-bitrate HLS through an included delivery layer, with a signed-URL flag and time-to-live in storage settings and a bandwidth allowance stated per plan on our pricing page.
Why the video CDN for streaming is the part of the bill you should understand
Storage is cheap and predictable. Delivery is neither, and it is where streaming services get surprised. Every minute a viewer watches pulls megabytes from a server, and the cost of moving those bytes to a phone in another country scales with your audience, not with your catalog. An operator who does not know the bandwidth allowance in their plan, the size of their renditions and the average watch time per session cannot forecast the one line on the bill that grows with success. This page exists so you can do that sum before launch rather than after the first big month.
Flicknexs treats delivery as part of the platform rather than a separate account you must open. Each plan carries a stated bandwidth allowance alongside its storage, transcoding produces adaptive-bitrate HLS with a master playlist, and the delivery layer serves the segments to the web player and every device app. The signed-URL flag and its time-to-live live in storage settings. Hotlink protection by referer is configured at the delivery layer on request. There is no separate delivery contract, no per-region pricing table and no second dashboard to reconcile against your invoice.
Two public references explain the mechanics this page relies on. The HTTP Referer header, documented on the Mozilla Developer Network, is what hotlink protection reads to decide whether a segment request came from your player or from a page that embedded your stream without permission. The HLS specification published by the IETF as RFC 8216 defines the master playlist, the media playlists and the segment format that the player fetches. Understanding both takes an hour and pays off the first time a support ticket says a video works on one site and fails on another.
What the Flicknexs delivery layer does with each request
Everything in this table is either in the platform code or configured at the delivery layer as noted. The bandwidth figures come from our pricing page.
Adaptive HLS
Each title is packaged as HLS with a master playlist listing every rendition.
Included delivery
Segments are served through the delivery layer that comes with every plan.
Bandwidth per plan
Each plan states a bandwidth allowance next to its storage on our pricing page.
Signed URLs
A storage setting turns on signed playback URLs with a time-to-live you choose.
Referer protection
Hotlink protection at the delivery layer allows only approved domains and apps, set up on request.
Entitlement first
Plan, purchase, preview and country rules are checked before any playback URL is issued.
Live and on-demand
Live streams and on-demand titles use the same HLS delivery and the same player.
Session analytics
Player sessions record watch time, completion and device, which drive the bandwidth forecast.
Source: Flicknexs platform documentation and architecture specification, 2026-09-03.
How the video CDN for streaming works on Flicknexs
From the upload to the last segment, here is the path a title takes and what the admin controls along the way.
Transcoding produces the renditions the delivery layer serves
After upload, the transcoding queue produces a ladder of renditions, by default 720p, 480p and 360p, and writes a master playlist that lists them. Those files are what the delivery layer serves. The size of each rendition is the main driver of bandwidth, so the ladder you choose on the video transcoding page sets your delivery cost as much as your audience does. A leaner ladder for talking-head content is the cheapest optimization available.
The player fetches a master playlist and then segments
When an entitled viewer presses play, the player receives a playback URL for the master playlist, reads the available renditions, and starts requesting short media segments from the delivery layer. It measures how fast segments arrive and moves up or down the ladder to avoid stalls. Each segment request is an ordinary HTTP request, which is why referer checks and signed URLs work the way they do.
Signed URLs put an expiry on every playback link
In storage settings the signed-URL flag adds a signature and an expiry to each playback URL, and the time-to-live field sets how long the link is valid. After that window the delivery layer refuses the request. A link copied from the browser and pasted elsewhere stops working, while a legitimate viewer who reloads the page simply receives a fresh signed link from the platform.
Referer protection checks where the request came from
The delivery layer can be configured to read the HTTP Referer header on each request and refuse segments when the page or app is not on your approved list. This is set up on request rather than from the admin. It stops a third-party site from embedding your player and serving your bandwidth to its audience. Native apps identify themselves differently from browsers, so the list is built with the Flicknexs team to cover both.
Bandwidth is counted against the plan allowance
Every segment served counts toward the bandwidth allowance stated for your plan on our pricing page. The web-only plan and the F3 and F4 plans state a monthly allowance; the F1 and F2 plans state an annual one, which suits services whose traffic peaks around a few releases. Watch-hours and completion reports in analytics show which titles and devices consume the most, so you can tune the ladder or the catalog.
Live streams travel the same path
A live event is packaged as HLS in near real time and served by the same delivery layer, with the same entitlement check, the same signed-URL behavior and the same referer rules. Pay-per-view on a live event therefore protects the stream the same way it protects a film. Because live audiences arrive at once, the allowance math for a live event is peak concurrent viewers multiplied by rendition bitrate and duration.
How to set up delivery in the Flicknexs admin
Five steps that take an afternoon, most of it spent on the forecast rather than the settings.
- 1
Pick the plan whose allowance fits your forecast
Estimate monthly watch-hours from your expected audience and average session length, multiply by the bitrate of the rendition most viewers will land on, and compare the result with the allowance in each plan sentence on our pricing page. Choose the plan that leaves headroom for a good month, and note whether its allowance is stated per month or per year.
- 2
Set the rendition ladder to match the content
Open the transcoding settings and choose the ladder. The default of 720p, 480p and 360p suits most catalogs; add higher renditions only where the source and the audience justify the bandwidth. Upload a test title and note the size of each rendition in the job record, because those numbers feed the forecast from step one.
- 3
Turn on signed URLs and set the time-to-live
In Settings, then Storage, switch the signed-URL flag on and enter a time-to-live in seconds. Films and live events suit a short window; long lectures suit a longer one so a paused viewer does not lose the link. Save, then play a test title in a private browser and confirm it starts and that a copied link fails after the window.
- 4
Request referer protection with your domain list
Write down every domain that hosts your player, including staging and any marketing microsite, and ask the Flicknexs team to configure hotlink protection at the delivery layer with that list. The native apps are included in the setup. Add this list to your launch runbook so a future microsite is added before it goes live rather than after it fails.
- 5
Watch the usage reports for the first month
Open the analytics reports for player sessions, watch-hours by user and device breakdown after the first week of traffic. Compare the observed bandwidth with the forecast, identify the titles and devices that dominate, and adjust the ladder if a mobile-heavy audience is being served renditions it cannot display. Repeat monthly until the forecast and the bill agree.
Limits and tradeoffs of the video CDN for streaming
What the delivery layer does not do, said plainly so your architecture review has no surprises.
Bring-your-own delivery is not offered on the plans
The platform includes the delivery layer, and the plans do not offer a self-serve option to route playback through a delivery account you hold elsewhere. Bandwidth is metered against the plan allowance rather than billed by an outside provider. If your organization has a contractual reason to use its own delivery arrangement, raise it with the enterprise team before signing; it is a scoping conversation, not a switch in the admin.
One delivery layer, not several
Flicknexs serves through a single delivery layer rather than switching between several providers per request. For almost every audience that is the right tradeoff: one path to monitor, one set of referer rules, one bandwidth meter. Operators who require failover between independent delivery providers should treat that as an enterprise requirement to scope, not as something a plan includes.
HLS only, and the manifest is not token-authenticated
Delivery is HLS with a master playlist. There is no second packaging format, and the master playlist is protected by the signed-URL expiry and the entitlement check rather than by a per-viewer token embedded in the manifest itself. For most catalogs that is sufficient. Studio contracts that require encryption belong on the DRM video protection page, where encryption through the delivery layer on request is explained.
The allowance is a number, and traffic above it needs a conversation
The pricing page states the bandwidth allowance per plan and does not publish a rate for traffic beyond it. Rather than assume one, ask for a written quote before a launch or a live event that could exceed the allowance, and keep the analytics reports open so you see the trend early. A plan step up is often cheaper than a surprise, and the annual figures reward operators who plan ahead.
Referer protection needs a maintained list and a request
Because hotlink protection is configured at the delivery layer, it is set up on request and every domain that embeds your player must be on the list. Browsers do not always send a Referer header, for example under strict privacy settings, so a small share of legitimate requests can be refused if the rule is too strict. The Flicknexs team tunes the rule with you to balance protection against those cases.
A fitness studio forecasting its delivery bill
A worked example for a fitness studio selling on-demand classes and one live class a day to a subscriber base spread across three countries.
The studio has a library of four hundred classes averaging forty minutes and expects two thousand subscribers who each watch about ten classes a month. That is roughly thirteen thousand watch-hours a month. Most viewers are on phones and tablets, so the studio keeps the default ladder of 720p, 480p and 360p and expects the player to sit on 480p for much of the mobile audience. Using the rendition sizes recorded in its own transcoding jobs, the studio estimates its monthly delivery and finds it fits inside the F3 monthly allowance stated on our pricing page with headroom for growth.
Signed URLs go on with a time-to-live of two hours, long enough for a paused class and short enough that a link shared in a group chat dies before the next session. Referer protection is requested with three domains: the main site, the staging site and a landing page used for a January campaign. The daily live class runs through the same delivery path; peak concurrency of three hundred viewers at 480p for forty-five minutes adds a predictable amount to the monthly total, which the studio records in a spreadsheet alongside the analytics watch-hours report.
After the first month, the device breakdown shows a larger television audience than expected, watching on Android TV and Fire TV in the evening. Those sessions pull the 720p rendition and push bandwidth up faster than the phone forecast assumed. The studio adjusts its forecast, decides the television audience is worth the cost, and asks for a written quote for the next tier before the spring campaign rather than waiting to see the invoice. The video transcoding page helped it decide not to add a higher rendition.
Pre-launch checklist for delivery
Ten checks that take an hour and prevent the most common first-month surprises.
- You know whether your plan states its bandwidth allowance per month or per year, and the number is in your launch spreadsheet.
- A written forecast multiplies expected watch-hours by the bitrate of the rendition most viewers will land on, per device type.
- The rendition ladder matches the content and the audience, and the size of each rendition from a real job is recorded.
- The signed-URL flag is on in storage settings and a copied playback link fails after the time-to-live you chose.
- Referer protection has been requested with a complete domain list that includes staging and every marketing landing page.
- A test title plays on web, on a phone and on one television app, and the player switches renditions on a throttled connection.
- A live test stream has been run through the same delivery path with the entitlement check and pay-per-view rule that the real event will use.
- The analytics watch-hours, completion and device breakdown reports are bookmarked and someone owns the monthly comparison against the forecast.
- You have asked in writing what happens if traffic exceeds the allowance, and the answer is filed with the plan contract.
- Support knows that a video which works on your site but fails on a partner site is usually a referer list issue, not an outage.
How the delivery layer interacts with the device apps and your revenue
The same delivery path serves every screen, and the bandwidth it consumes is the cost side of every plan and purchase you sell.
The web player and the Android, iOS, Android TV and Fire TV apps all fetch the same HLS playlists and segments from the same delivery layer, and the add-on Roku, Samsung, LG and Apple TV apps do the same when built. Television apps tend to land on the highest rendition in the ladder because they sit on fixed connections and large screens, which is why a growing television audience moves the bandwidth line faster than a phone audience of the same size. The video transcoding page explains how the ladder is chosen, and the DRM video protection page explains the signed-URL and encryption layers that ride on top of delivery.
On the revenue side, delivery is the cost of every subscription and every pay-per-view sale. A rental window on the video paywall page defines how many times a title can be watched, and each of those plays is delivered bandwidth. A subscription plan with heavy watchers costs more to serve than one with light watchers at the same price, which is a reason to read the watch-hours by user report before setting plan prices. The payment gateways page covers how those plans are billed; none of the gateways see bandwidth, so the reconciliation between revenue and delivery is something you do in your own spreadsheet from the analytics reports.
Which plan includes the video CDN
Standard layers
The delivery layer, adaptive HLS, the signed-URL flag and the session analytics are part of every plan. Referer protection at the delivery layer is configured on request on any plan. What changes between plans is the bandwidth allowance and the storage that comes with it. F1 Standard is the web-only plan, with 300 GB of storage and 20 TB of bandwidth yearly; see our pricing page for current plan and pricing details. F1 Standard includes 300 GB of storage and 20 TB of bandwidth yearly for website streaming; see our pricing page for current plan and pricing details. F2 Super includes 300 GB of storage and 20 TB of bandwidth yearly, and adds native Android and iOS mobile apps; see our pricing page for current plan and pricing details.
Pricing & billing
F3 Premium includes 1 TB of storage and 10 TB of bandwidth monthly, and adds Android TV and Fire TV apps; see our pricing page for current plan and pricing details. F4 Enterprise includes 2 TB of storage and 20 TB of bandwidth monthly and adds dedicated support to everything in F3; Samsung, LG, Roku and Apple TV apps are add-ons on any plan. See our pricing page for current plan and pricing details. Note that F1 and F2 state their allowance per year while the web-only plan, F3 and F4 state it per month, which matters when your traffic is seasonal.
Annual savings
Yearly billing on F1 to F4 costs less per month than monthly billing; see our pricing page for current plan and pricing details. Plans are flat fees and Flicknexs takes no commission on your revenue; payment-gateway fees are between you and your gateway. See our pricing page for current plan and pricing details. The pricing page does not publish a rate for traffic above the allowance, so ask for a written quote before a launch that could exceed it.
Conclusion: what to do next
Already on Flicknexs
If you already run on Flicknexs, open the analytics watch-hours and device reports today and compare the last month of delivery with the allowance in your plan. Then check that the signed-URL flag is on and that every domain hosting your player is on the referer list. If the television share of your audience is growing, revisit the ladder before it grows further. Those three checks take an hour and settle most delivery questions.
Choosing a platform
If you are choosing a platform, ask each vendor three things in writing: whether delivery is included or billed by a separate provider, what the bandwidth allowance is and whether it is monthly or annual, and what happens above it. Then ask how playback links are protected and whether referer rules are available. A vendor who cannot answer the allowance question plainly is asking you to guess the largest variable on your bill.
Before a rights call
Read the companion pages next. The video transcoding page shows how the rendition ladder is built, because rendition size drives bandwidth more than anything else. The DRM video protection page explains signed URLs, the watermark and encryption on request. The video paywall page connects rental windows and pay-per-view plays to the delivery those plays consume. Together they give you the complete cost picture.
Frequently Asked Questions
Everything you need to know about the video CDN on Flicknexs.
Yes. Every plan states a bandwidth allowance next to its storage, and delivery runs through the layer included with the platform rather than a separate provider account. According to our pricing page, F3 Premium includes 10 TB of bandwidth per month and F4 Enterprise 20 TB per month, and no rate is published for traffic above the allowance.
Three ways. Entitlement is checked before any playback URL is issued. The signed-URL flag in storage settings adds a signature and an expiry to each link, with a time-to-live you set. Referer protection at the delivery layer, configured on request, refuses segment requests from domains and apps that are not on your approved list.
Not as a plan option. The platform includes the delivery layer and bandwidth is metered against the plan allowance, so there is no self-serve setting to route playback through a delivery account you hold elsewhere. If your organization has a contractual requirement for its own delivery arrangement, raise it with the enterprise team as a scoping conversation.
It depends on the plan. F1 Standard includes 300 GB of storage and 20 TB of bandwidth yearly for website streaming; see our pricing page for current plan and pricing details. F2 also states its allowance per year; the web-only plan, F3 and F4 state theirs per month. Seasonal services with a few large releases often prefer the annual shape.
The pricing page does not publish a rate for traffic above the allowance, so Flicknexs does not quote one here. Ask for a written quote before a launch or live event that could exceed it, watch the analytics watch-hours report monthly, and consider the next plan tier when the trend points upward.
Adaptive-bitrate HLS with a master playlist that lists each rendition from the transcoding ladder. The player reads the master playlist and requests media segments, moving between renditions as the connection changes. Live streams and on-demand titles use the same format and the same delivery path, so there is one thing to monitor.
Multiply expected monthly watch-hours by the bitrate of the rendition most viewers will land on, split by device type because televisions pull higher renditions than phones. Use the rendition sizes recorded in your own transcoding jobs rather than a generic figure, then compare the result with the allowance sentence for each plan.
It can if the rule is too strict, because some browsers omit the Referer header under privacy settings and native apps identify themselves differently from web pages. That is why it is configured on request with the Flicknexs team, who tune the rule to cover your domains and apps while keeping the refusals to unapproved embeds.
Only if the time-to-live is shorter than the pause and the player needs a fresh link. Set the window to suit your content: a couple of hours for long lectures, a few minutes for short clips. A legitimate viewer who reloads receives a new signed link from the platform because their entitlement is rechecked.
The path is the same: HLS packaged in near real time, served by the same delivery layer, with the same entitlement, signed-URL and referer behavior. What differs is the arithmetic, because live audiences arrive together. Estimate peak concurrent viewers multiplied by rendition bitrate and event length, and add it to the monthly total.
The analytics section records player sessions with watch time and completion, a watch-hours report by user, and a device and platform breakdown. Together they show which titles and which screens consume the most, which is what you need to compare observed delivery with the allowance and to decide whether the ladder needs adjusting.
Yes, more than any other single change. Rendition size is the main driver of bytes served, so a ladder that tops out at 720p for talking-head content serves far less than one with higher renditions. The video transcoding page explains how to choose the ladder per catalog and what each option costs in bandwidth.