Cre­at­ing a TV stream­ing serv­er is no longer a project reserved for major broad­cast­ers and glob­al media com­pa­nies.

Inde­pen­dent con­tent pro­duc­ers, church­es, uni­ver­si­ties, local tele­vi­sion sta­tions, sports orga­ni­za­tions, edu­ca­tion­al com­pa­nies, event pro­duc­ers, con­tent dis­trib­u­tors, and star­tups can now launch live chan­nels and video-on-demand ser­vices that work on web­sites, smart­phones, and Smart TVs.

A mod­ern TV stream­ing serv­er can dis­trib­ute con­tent to:

• Sam­sung Smart TVs;
• LG webOS tele­vi­sions;
• Roku devices;
• Android TV;
• Google TV;
• Fire TV;
• Apple TV;
• smart­phones;
• tablets;
• desk­top browsers;
• con­nect­ed tele­vi­sion appli­ca­tions.

How­ev­er, a pro­fes­sion­al stream­ing plat­form is not sim­ply a web­site con­tain­ing a video play­er.

A com­plete stream­ing sys­tem must receive a video sig­nal, encode it, cre­ate dif­fer­ent qual­i­ty lev­els, pack­age the con­tent into a stream­ing for­mat, deliv­er it over HTTPS, man­age access, mon­i­tor per­for­mance, and scale when the audi­ence grows.

The most com­mon deliv­ery for­mat for broad tele­vi­sion com­pat­i­bil­i­ty is HLS, or HTTP Live Stream­ing. HLS dis­trib­utes live and on-demand con­tent over stan­dard HTTP infra­struc­ture and can use ordi­nary web servers and con­tent deliv­ery net­works. It also sup­ports adap­tive play­back, allow­ing com­pat­i­ble play­ers to change qual­i­ty when net­work con­di­tions change.

This guide explains how to build that infra­struc­ture from the ground up.

You will learn how to:

• choose the cor­rect serv­er;
• receive a stream from OBS or an encoder;
• use RTMP or SRT for con­tri­bu­tion;
• process video with FFm­peg;
• cre­ate adap­tive HLS playlists;
• deploy SRS as a media serv­er;
• con­fig­ure NGINX and HTTPS;
• con­nect the stream to Smart TV appli­ca­tions;
• pro­tect the ori­gin serv­er;
• add a CDN;
• cal­cu­late band­width;
• cre­ate lin­ear chan­nels;
• mon­i­tor avail­abil­i­ty;
• pre­pare the project for pro­duc­tion.

---

🎯 What Is a TV Streaming Server?

A TV stream­ing serv­er is an infra­struc­ture that receives, process­es, stores, pack­ages, and dis­trib­utes video con­tent over the inter­net.

The source of the video may be:

• a stu­dio cam­era;
• an OBS Stu­dio pro­duc­tion;
• a pro­fes­sion­al hard­ware encoder;
• a tele­vi­sion automa­tion sys­tem;
• a playlist of MP4 files;
• a satel­lite receiv­er;
• a remote event;
• a live sports pro­duc­tion;
• anoth­er stream­ing provider;
• a cloud-based play­out plat­form.

The incom­ing sig­nal is called the con­tri­bu­tion stream or ingest stream.

After receiv­ing the source, the plat­form may per­form sev­er­al oper­a­tions:

1. Decode the incom­ing video.
2. Resize it into dif­fer­ent res­o­lu­tions.
3. Re-encode it using a com­pat­i­ble codec.
4. Nor­mal­ize audio.
5. Cre­ate mul­ti­ple bitrate ver­sions.
6. Gen­er­ate HLS or DASH seg­ments.
7. Pub­lish a mas­ter playlist.
8. Deliv­er the con­tent through HTTPS.
9. Cache the seg­ments through a CDN.
10. Send play­back ana­lyt­ics to a mon­i­tor­ing plat­form.

The tele­vi­sion appli­ca­tion nor­mal­ly does not con­nect direct­ly to the cam­era or OBS com­put­er.

Instead, it receives a URL such as:

https://stream.example.com/live/channel1/master.m3u8

That URL points to an HLS mul­ti­vari­ant playlist.

The playlist describes the video qual­i­ties avail­able to the play­er.

For exam­ple:

#EXTM3U

#EXT-X-STREAM-INF:BANDWIDTH=5500000,RESOLUTION=1920x1080
1080p/index.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=3000000,RESOLUTION=1280x720
720p/index.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=1500000,RESOLUTION=854x480
480p/index.m3u8

A com­pat­i­ble Smart TV can select a low­er or high­er stream accord­ing to avail­able band­width and play­back con­di­tions.

This process is known as adap­tive bitrate stream­ing, or ABR.

---

🧩 Understanding the Streaming Architecture

Before installing soft­ware, it is impor­tant to under­stand how the pieces fit togeth­er.

A stan­dard archi­tec­ture looks like this:

Video Source
     ↓
Ingest Protocol
     ↓
Media Server
     ↓
Transcoding
     ↓
Packaging
     ↓
Origin Server
     ↓
CDN
     ↓
Smart TV App or Player

Let us exam­ine each stage.

1. Video source

The source pro­duces the orig­i­nal audio and video sig­nal.

Exam­ples include:

• OBS Stu­dio;
• Wire­cast;
• vMix;
• hard­ware encoders;
• IP cam­eras;
• stu­dio switch­ers;
• tele­vi­sion play­out soft­ware;
• files repro­duced through FFm­peg;
• remote SRT feeds.

The source should have a sta­ble frame rate, pre­dictable audio lev­els, and a res­o­lu­tion suit­able for the tar­get plat­form.

2. Ingest

Ingest is the method used to send the source sig­nal to the media serv­er.

Pop­u­lar con­tri­bu­tion pro­to­cols include:

• RTMP;
• SRT;
• RTSP;
• RIST;
• WHIP;
• MPEG-TS over UDP;
• HLS con­tri­bu­tion.

RTMP remains use­ful because it works with many pro­duc­tion tools and encoders.

SRT is often cho­sen when the source is being trans­port­ed across an unre­li­able net­work. SRS sup­ports stream­ing work­flows involv­ing RTMP, HLS, WebRTC, HTTP-FLV, and SRT, mak­ing it suit­able as a gate­way between con­tri­bu­tion and deliv­ery for­mats.

3. Transcoding

Transcod­ing cre­ates new ver­sions of the incom­ing video.

Sup­pose the stu­dio sends a 1080p stream at 8 Mbps. Your plat­form might gen­er­ate:

• 1080p at 5 Mbps;
• 720p at 3 Mbps;
• 480p at 1.5 Mbps;
• 360p at 700 Kbps.

Users with fast con­nec­tions can watch the high­er qual­i­ty ver­sion. View­ers with unsta­ble or slow­er con­nec­tions can receive a low­er bitrate.

Transcod­ing is one of the most resource-inten­sive parts of a stream­ing plat­form.

4. Packaging

Pack­ag­ing orga­nizes encod­ed video into a deliv­ery for­mat.

Com­mon for­mats include:

• HLS;
• MPEG-DASH;
• CMAF;
• Microsoft Smooth Stream­ing.

For a first mul­ti-plat­form Smart TV project, HLS is often the most prac­ti­cal start­ing point because of its broad ecosys­tem and com­pat­i­bil­i­ty.

5. Origin server

The ori­gin serv­er stores or expos­es:

• HLS playlists;
• MPEG-TS seg­ments;
• frag­ment­ed MP4 seg­ments;
• sub­ti­tle files;
• encryp­tion keys;
• video-on-demand files;
• thumb­nails;
• man­i­fests;
• meta­da­ta.

The ori­gin should be sta­ble and pro­tect­ed. In larg­er deploy­ments, the pub­lic audi­ence should receive the con­tent through a CDN instead of con­nect­ing direct­ly to the ori­gin.

6. CDN

A con­tent deliv­ery net­work caches video seg­ments clos­er to view­ers.

Instead of one serv­er respond­ing to every request, edge loca­tions dis­trib­ute the load.

A CDN can improve:

• scal­a­bil­i­ty;
• geo­graph­ic per­for­mance;
• start­up time;
• ori­gin pro­tec­tion;
• avail­abil­i­ty;
• resis­tance to traf­fic spikes.

7. Application and player

The last stage is the play­er.

The play­er may be part of:

• a Sam­sung Tizen appli­ca­tion;
• an LG webOS appli­ca­tion;
• a Roku Scene­Graph chan­nel;
• an Android TV appli­ca­tion;
• a web appli­ca­tion;
• an iOS or tvOS appli­ca­tion.

The play­er loads the playlist, choos­es an appro­pri­ate qual­i­ty, buffers seg­ments, decodes the media, and dis­plays it to the view­er.

---

🌐 Choosing the Right Streaming Protocol

Dif­fer­ent pro­to­cols solve dif­fer­ent prob­lems.

Using the same pro­to­col for every stage is rarely the best archi­tec­ture.

📡 RTMP

RTMP is com­mon­ly used to send live video from an encoder to a media serv­er.

Exam­ple:

OBS → RTMP → SRS

A pub­lish­ing URL may look like:

rtmp://stream.example.com/live/channel1

RTMP is con­ve­nient for ingest, but it is gen­er­al­ly not the pre­ferred final-deliv­ery pro­to­col for mod­ern Smart TV appli­ca­tions.

A more com­mon work­flow is:

RTMP ingest → HLS delivery

🛰️ SRT

SRT can be use­ful for con­tri­bu­tion over unsta­ble inter­net con­nec­tions.

It includes mech­a­nisms for recov­er­ing from pack­et loss and han­dling net­work vari­a­tion. A media gate­way can receive SRT and con­vert the stream into for­mats such as RTMP, HLS, or WebRTC. SRS doc­u­ments work­flows in which OBS or FFm­peg sends SRT and the serv­er con­verts it into oth­er stream­ing for­mats.

📺 HLS

HLS is designed for live and on-demand dis­tri­b­u­tion over HTTP.

A typ­i­cal HLS stream con­tains:

• a mul­ti­vari­ant playlist;
• one media playlist per ren­di­tion;
• short video seg­ments;
• option­al audio tracks;
• option­al sub­ti­tles;
• option­al encryp­tion infor­ma­tion.

Apple describes HLS as a method of dis­trib­ut­ing live and on-demand media through ordi­nary web servers and CDNs, with dynam­ic adap­ta­tion to avail­able net­work con­di­tions.

📊 MPEG-DASH

MPEG-DASH is anoth­er adap­tive stream­ing for­mat.

It is often used in envi­ron­ments involv­ing:

• Widevine DRM;
• Android devices;
• brows­er play­ers;
• CMAF pack­ag­ing;
• mul­ti-DRM ser­vices.

The man­i­fest com­mon­ly uses the .mpd exten­sion.

⚡ WebRTC

WebRTC is suit­able when very low laten­cy is essen­tial.

Exam­ples include:

• inter­ac­tive auc­tions;
• two-way com­mu­ni­ca­tion;
• remote pro­duc­tion;
• live edu­ca­tion;
• real-time audi­ence inter­ac­tion.

For a tra­di­tion­al lin­ear tele­vi­sion chan­nel, a few sec­onds of delay may be accept­able. HLS is usu­al­ly eas­i­er to cache and scale.

---

🖥️ Server Requirements

Your hard­ware require­ments depend on what the serv­er must do.

A serv­er that only receives an already encod­ed stream and repack­ages it uses far few­er resources than a serv­er that cre­ates four new video qual­i­ties.

Con­sid­er:

• num­ber of chan­nels;
• input res­o­lu­tion;
• input bitrate;
• out­put res­o­lu­tions;
• codec;
• frame rate;
• simul­ta­ne­ous view­ers;
• record­ing require­ments;
• DVR win­dow;
• laten­cy tar­get;
• geo­graph­ic audi­ence.

Small laboratory server

A basic test serv­er may begin with:

2 vCPUs
4 GB RAM
40–80 GB SSD
Ubuntu Server
Public IPv4 address
1 Gbps network port

This can be enough for:

• one test stream;
• RTMP ingest;
• HLS pack­ag­ing;
• lim­it­ed play­back test­ing;
• no heavy mul­ti-ren­di­tion transcod­ing.

Small production project

A small live chan­nel with soft­ware transcod­ing may require:

4–8 vCPUs
8–16 GB RAM
100 GB SSD or more
1 Gbps network
External CDN
Monitoring
Automatic restart

Multi-channel platform

A larg­er OTT or FAST TV ser­vice may use:

Dedicated ingest nodes
GPU-enabled transcoders
Multiple origin servers
Object storage
Load balancing
CDN delivery
Database and API servers
Monitoring stack
Backup encoders
Failover infrastructure

Do not assume that more RAM will solve a transcod­ing bot­tle­neck. Video encod­ing often depends pri­mar­i­ly on CPU or GPU capac­i­ty.

---

📊 How to Calculate Streaming Bandwidth

Band­width plan­ning is essen­tial.

A con­ve­nient esti­mate is:

Data per viewer per hour in GB ≈ bitrate in Mbps × 0.45

For a 3 Mbps stream:

3 × 0.45 = 1.35 GB per viewer per hour

For 100 view­ers watch­ing for one hour:

1.35 × 100 = 135 GB

The required out­bound speed is:

Concurrent viewers × average bitrate

For 100 view­ers at 3 Mbps:

100 × 3 Mbps = 300 Mbps

For 1,000 view­ers:

1,000 × 3 Mbps = 3,000 Mbps

That equals approx­i­mate­ly 3 Gbps.

A serv­er with a 1 Gbps con­nec­tion can­not direct­ly deliv­er 3 Gbps. Even before reach­ing the the­o­ret­i­cal max­i­mum, oper­at­ing-sys­tem over­head, traf­fic bursts, oth­er ser­vices, and net­work lim­its reduce usable capac­i­ty.

This is one rea­son a CDN becomes impor­tant when the audi­ence grows.

Monthly traffic example

Sup­pose your plat­form has:

• 200 dai­ly view­ers;
• 90 min­utes watched per view­er;
• aver­age select­ed bitrate of 2.5 Mbps;
• 30 days per month.

Approx­i­mate traf­fic:

2.5 Mbps × 0.45 = 1.125 GB per hour

Each user watch­es 1.5 hours:

1.125 × 1.5 = 1.6875 GB per viewer

For 200 dai­ly view­ers:

1.6875 × 200 = 337.5 GB per day

For 30 days:

337.5 × 30 = 10,125 GB

That is approx­i­mate­ly 10.1 TB per month.

This cal­cu­la­tion demon­strates why stream­ing costs are often dri­ven more by trans­fer vol­ume than by web­site host­ing.

---

🧰 Recommended Software Stack

A prac­ti­cal open-source stack can include:

Com­po­nent	Pur­pose
Ubun­tu Serv­er	Oper­at­ing sys­tem
Dock­er	Con­tain­er man­age­ment
SRS	Ingest and media gate­way
FFm­peg	Encod­ing and transcod­ing
NGINX	HTTP deliv­ery and reverse proxy
Cert­bot	TLS cer­tifi­cate automa­tion
CDN	Edge deliv­ery
Prometheus/Grafana	Mon­i­tor­ing
API appli­ca­tion	Authen­ti­ca­tion and meta­da­ta

FFm­peg describes itself as a uni­ver­sal media con­vert­er capa­ble of read­ing many types of inputs, fil­ter­ing or transcod­ing them, and writ­ing mul­ti­ple out­put for­mats.

NGINX can oper­ate as an HTTP serv­er, reverse proxy, con­tent cache, load bal­ancer, and TCP/UDP proxy. Its proxy mod­ule can for­ward requests to anoth­er local or remote ser­vice.

---

🚀 Step 1: Create the Linux Server

Choose a VPS, cloud instance, or ded­i­cat­ed serv­er.

For a test project, install a cur­rent Ubun­tu LTS release.

You will need:

Public IP address
SSH credentials
Root or sudo access
A domain name

Con­nect using SSH:

ssh root@YOUR_SERVER_IP

Update the oper­at­ing sys­tem:

apt update
apt upgrade -y

Install basic tools:

apt install -y \
  curl \
  wget \
  git \
  ufw \
  ca-certificates \
  gnupg \
  ffmpeg \
  nginx

Check FFm­peg:

ffmpeg -version

Check NGINX:

nginx -v

---

🐳 Step 2: Install Docker

Install Dock­er using the sup­port­ed method for your oper­at­ing sys­tem.

On a sim­ple Ubun­tu lab­o­ra­to­ry serv­er, the dis­tri­b­u­tion pack­age may be suf­fi­cient:

apt install -y docker.io docker-compose-plugin

Enable the ser­vice:

systemctl enable docker
systemctl start docker

Ver­i­fy:

docker --version
docker compose version

---

📡 Step 3: Run SRS

SRS is an open-source media serv­er focused on real-time stream­ing and sup­ports pro­to­cols includ­ing RTMP, HLS, WebRTC, HTTP-FLV, and SRT.

Cre­ate a project direc­to­ry:

mkdir -p /opt/tv-streaming
cd /opt/tv-streaming

Cre­ate a Dock­er Com­pose file:

nano compose.yml

Exam­ple:

services:
  srs:
    image: ossrs/srs:5
    container_name: srs
    restart: unless-stopped
    ports:
      - "1935:1935"
      - "8080:8080"
    networks:
      - streaming

networks:
  streaming:
    driver: bridge

Start the con­tain­er:

docker compose up -d

Check its sta­tus:

docker compose ps

Read logs:

docker logs -f srs

Offi­cial SRS exam­ples doc­u­ment port 1935 for RTMP and port 8080 for HTTP/HLS deliv­ery.

For pro­duc­tion, pin a sta­ble image ver­sion that you have test­ed rather than auto­mat­i­cal­ly upgrad­ing an unver­i­fied image.

---

🔥 Step 4: Configure the Firewall

Allow SSH, HTTP, HTTPS, and RTMP:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 1935/tcp
ufw enable

Check:

ufw status

Avoid pub­licly expos­ing admin­is­tra­tive APIs unless they are pro­tect­ed.

---

🎥 Step 5: Publish a Stream from OBS

Open OBS Stu­dio and nav­i­gate to:

Settings → Stream

Select a cus­tom ser­vice.

Use:

Serv­er:

rtmp://YOUR_SERVER_IP/live

Stream key:

channel1

The full pub­lish­ing address becomes:

rtmp://YOUR_SERVER_IP/live/channel1

After start­ing the broad­cast, the HLS URL may be avail­able as:

http://YOUR_SERVER_IP:8080/live/channel1.m3u8

This RTMP-to-HLS work­flow is doc­u­ment­ed in the SRS deploy­ment exam­ples.

Test the HLS URL using VLC:

Media → Open Network Stream

Paste:

http://YOUR_SERVER_IP:8080/live/channel1.m3u8

If play­back begins, the basic ingest and pack­ag­ing pipeline is work­ing.

---

🎬 Step 6: Publish a File with FFmpeg

You can sim­u­late a 24-hour tele­vi­sion chan­nel using an MP4 file.

Exam­ple:

ffmpeg \
  -re \
  -stream_loop -1 \
  -i program.mp4 \
  -c:v libx264 \
  -preset veryfast \
  -b:v 3000k \
  -maxrate 3200k \
  -bufsize 6000k \
  -g 60 \
  -keyint_min 60 \
  -sc_threshold 0 \
  -c:a aac \
  -b:a 128k \
  -ar 48000 \
  -f flv \
  rtmp://127.0.0.1/live/channel1

Impor­tant para­me­ters:

-re

Reads the input at approx­i­mate­ly its native play­back speed instead of pro­cess­ing it as fast as pos­si­ble.

-stream_loop -1

Repeats the source indef­i­nite­ly.

-c:v libx264

Encodes the video using H.264.

-preset veryfast

Bal­ances CPU usage and com­pres­sion effi­cien­cy.

-b:v 3000k

Sets the tar­get video bitrate.

-g 60

Sets the GOP length. At 30 frames per sec­ond, 60 frames rep­re­sent approx­i­mate­ly two sec­onds.

-sc_threshold 0

Pre­vents auto­mat­ic scene-cut keyframes from dis­rupt­ing fixed GOP align­ment.

-c:a aac

Encodes audio as AAC.

-f flv

Cre­ates an out­put suit­able for RTMP pub­lish­ing.

FFm­peg sup­ports a wide range of pro­to­cols and out­put con­tain­ers through its libav­for­mat infra­struc­ture.

---

🎚️ Step 7: Create Adaptive Bitrate HLS

A sin­gle-qual­i­ty stream is vul­ner­a­ble to buffer­ing.

A view­er with lim­it­ed band­width may be unable to main­tain a 1080p stream. A view­er with a fast con­nec­tion should not be forced to watch a low-res­o­lu­tion ver­sion.

Cre­ate an encod­ing lad­der.

Suggested starter ladder

Ren­di­tion	Res­o­lu­tion	Video bitrate	Audio
1080p	1920×1080	4.5–6 Mbps	128 Kbps
720p	1280×720	2.5–3.5 Mbps	128 Kbps
480p	854×480	1.2–1.8 Mbps	96 Kbps
360p	640×360	600–900 Kbps	96 Kbps

These val­ues are start­ing points.

Sports, gam­ing, and fast cam­era move­ment gen­er­al­ly require more bitrate than inter­views, pre­sen­ta­tions, or sta­t­ic stu­dio pro­grams.

Cre­ate out­put direc­to­ries:

mkdir -p /var/www/hls/channel1/{1080p,720p,480p}

Exam­ple FFm­peg com­mand:

ffmpeg \
  -i rtmp://127.0.0.1/live/channel1 \
  -filter_complex "
    [0:v]split=3[v1080][v720][v480];
    [v1080]scale=1920:1080[v1080out];
    [v720]scale=1280:720[v720out];
    [v480]scale=854:480[v480out]
  " \
  -map "[v1080out]" -map 0:a:0 \
  -map "[v720out]"  -map 0:a:0 \
  -map "[v480out]"  -map 0:a:0 \
  -c:v libx264 \
  -preset veryfast \
  -g 60 \
  -keyint_min 60 \
  -sc_threshold 0 \
  -b:v:0 5000k \
  -maxrate:v:0 5350k \
  -bufsize:v:0 10000k \
  -b:v:1 2800k \
  -maxrate:v:1 2996k \
  -bufsize:v:1 5600k \
  -b:v:2 1400k \
  -maxrate:v:2 1498k \
  -bufsize:v:2 2800k \
  -c:a aac \
  -b:a:0 128k \
  -b:a:1 128k \
  -b:a:2 96k \
  -ar 48000 \
  -f hls \
  -hls_time 4 \
  -hls_list_size 8 \
  -hls_flags delete_segments+independent_segments \
  -master_pl_name master.m3u8 \
  -var_stream_map "v:0,a:0,name:1080p v:1,a:1,name:720p v:2,a:2,name:480p" \
  -hls_segment_filename "/var/www/hls/channel1/%v/segment_%06d.ts" \
  "/var/www/hls/channel1/%v/index.m3u8"

The out­put struc­ture should resem­ble:

/var/www/hls/channel1/master.m3u8
/var/www/hls/channel1/1080p/index.m3u8
/var/www/hls/channel1/720p/index.m3u8
/var/www/hls/channel1/480p/index.m3u8

The play­er should open:

https://stream.example.com/hls/channel1/master.m3u8

The FFm­peg HLS mux­er includes options for seg­ment dura­tion, playlist size, seg­ment file­names, mas­ter playlists, and mul­ti­ple vari­ant streams.

Important GOP rule

All ren­di­tions should have aligned keyframes.

When the play­er switch­es from 720p to 480p, it should find equiv­a­lent seg­ment bound­aries and decod­ing points.

For 30 fps with a two-sec­ond GOP:

30 × 2 = 60 frames

Use:

-g 60
-keyint_min 60
-sc_threshold 0

For 25 fps:

25 × 2 = 50 frames

Adjust the GOP accord­ing to your actu­al frame rate.

---

🔐 Step 8: Configure a Domain and HTTPS

An IP-based URL is accept­able for test­ing.

Pro­duc­tion should use a domain such as:

stream.example.com

Cre­ate a DNS A record:

Type: A
Name: stream
Value: YOUR_SERVER_IP

Cre­ate an NGINX vir­tu­al host:

nano /etc/nginx/sites-available/stream

Exam­ple:

server {
    listen 80;
    server_name stream.example.com;

    location /hls/ {
        root /var/www;

        types {
            application/vnd.apple.mpegurl m3u8;
            video/mp2t ts;
            video/mp4 mp4 m4s;
        }

        add_header Access-Control-Allow-Origin "*" always;
        add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS" always;
        add_header Access-Control-Allow-Headers "Origin, Range, Accept, Content-Type" always;
        add_header Access-Control-Expose-Headers "Content-Length, Content-Range" always;

        if ($request_method = OPTIONS) {
            return 204;
        }
    }

    location /srs/ {
        proxy_pass http://127.0.0.1:8080/;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Enable it:

ln -s /etc/nginx/sites-available/stream \
      /etc/nginx/sites-enabled/stream

Val­i­date:

nginx -t

Reload:

systemctl reload nginx

NGINX’s proxy mod­ule pass­es requests to upstream ser­vices using direc­tives such as proxy_pass and proxy_set_header.

Install Cert­bot:

apt install -y certbot python3-certbot-nginx

Request a cer­tifi­cate:

certbot --nginx -d stream.example.com

Your stream becomes:

https://stream.example.com/hls/channel1/master.m3u8

HTTPS is impor­tant because browsers, APIs, tele­vi­sion plat­forms, and appli­ca­tion stores increas­ing­ly expect secure media deliv­ery.

---

📺 Connecting the Stream to Smart TV Applications

A tech­ni­cal­ly valid stream can still fail on a tele­vi­sion if the device does not sup­port the codec, playlist tags, audio con­fig­u­ra­tion, or con­tain­er.

Always test on real devices.

Samsung Tizen

Sam­sung pro­vides the AVPlay API for mul­ti­me­dia play­back in tele­vi­sion appli­ca­tions. AVPlay can open remote net­work media URIs, report buffer­ing events, and con­trol play­back. Sam­sung also doc­u­ments adap­tive-stream­ing behav­ior and HLS tag sup­port by Tizen ver­sion.

Con­cep­tu­al JavaScript exam­ple:

const streamUrl =
  "https://stream.example.com/hls/channel1/master.m3u8";

webapis.avplay.open(streamUrl);

webapis.avplay.setDisplayRect(0, 0, 1920, 1080);

webapis.avplay.setListener({
  onbufferingstart: function () {
    console.log("Buffering started");
  },

  onbufferingcomplete: function () {
    console.log("Buffering finished");
  },

  onstreamcompleted: function () {
    console.log("Stream completed");
  },

  onerror: function (error) {
    console.error("Playback error:", error);
  }
});

webapis.avplay.prepareAsync(
  function () {
    webapis.avplay.play();
  },
  function (error) {
    console.error("Prepare error:", error);
  }
);

Do not assume that every HLS tag sup­port­ed by a new­er tele­vi­sion is sup­port­ed by an old­er mod­el.

LG webOS

LG webOS appli­ca­tions may use an HTML5 video ele­ment for com­pat­i­ble media work­flows.

Con­cep­tu­al exam­ple:

<video
  id="player"
  autoplay
  controls
  playsinline
  style="width:100%;height:100%;background:#000"
>
  <source
    src="https://stream.example.com/hls/channel1/master.m3u8"
    type="application/vnd.apple.mpegurl"
  >
</video>

For pro­duc­tion, add:

• error lis­ten­ers;
• retry log­ic;
• net­work mon­i­tor­ing;
• play­er-state han­dling;
• recov­ery after stand­by;
• focus man­age­ment for the remote con­trol.

Roku

Roku sup­ports stan­dard adap­tive pro­to­cols includ­ing HLS and DASH. Roku’s stream­ing spec­i­fi­ca­tions rec­om­mend pro­vid­ing mul­ti­ple video streams at dif­fer­ent qual­i­ty lev­els so the device can select accord­ing to net­work con­di­tions.

Scene­Graph exam­ple:

content = CreateObject("roSGNode", "ContentNode")

content.url = "https://stream.example.com/hls/channel1/master.m3u8"
content.streamFormat = "hls"
content.title = "Live Channel"

m.video.content = content
m.video.control = "play"

Android TV

AndroidX Media3 Exo­Play­er sup­ports HLS through its HLS mod­ule. The media sam­ples con­tained inside the HLS stream must also use for­mats sup­port­ed by the device.

Kotlin exam­ple:

val player = ExoPlayer.Builder(context).build()

val mediaItem = MediaItem.fromUri(
    "https://stream.example.com/hls/channel1/master.m3u8"
)

player.setMediaItem(mediaItem)
player.prepare()
player.play()

A basic depen­den­cy may resem­ble:

implementation("androidx.media3:media3-exoplayer-hls:<version>")

Use the cur­rent test­ed Media3 ver­sion for your appli­ca­tion rather than copy­ing an old ver­sion num­ber with­out ver­i­fi­ca­tion.

---

🌍 Step 9: Add a CDN

The ori­gin serv­er should not nec­es­sar­i­ly deliv­er every seg­ment direct­ly to every view­er.

A CDN can cache the seg­ments and dis­trib­ute them through edge loca­tions.

The archi­tec­ture becomes:

Encoder
   ↓
Ingest server
   ↓
Transcoder
   ↓
HLS origin
   ↓
CDN
   ↓
Smart TV applications

Cache strategy

Live playlists change fre­quent­ly.

Use a short­er cache pol­i­cy for:

master.m3u8
index.m3u8

Seg­ments can nor­mal­ly use a longer cache pol­i­cy:

segment_000123.ts
segment_000124.ts

A stale live playlist may cause:

• play­back behind the live edge;
• miss­ing seg­ments;
• repeat­ed seg­ments;
• start­up fail­ures;
• exces­sive laten­cy.

Protecting the origin

Where sup­port­ed, con­fig­ure the ori­gin so it accepts requests only from:

• CDN address ranges;
• a pri­vate net­work;
• an authen­ti­cat­ed proxy;
• signed requests.

If the ori­gin URL remains pub­licly acces­si­ble, users may bypass your CDN and con­sume your serv­er band­width direct­ly.

---

🛡️ Securing the Streaming Platform

A pub­licly avail­able stream­ing serv­er can attract abuse.

Poten­tial prob­lems include:

• unau­tho­rized restream­ing;
• stolen stream keys;
• band­width theft;
• ori­gin scrap­ing;
• unau­tho­rized pub­lish­ing;
• API attacks;
• token shar­ing;
• exces­sive con­nec­tion attempts.

Use strong publishing keys

Avoid pre­dictable URLs such as:

rtmp://stream.example.com/live/channel1

Use a long pub­lish­ing token:

rtmp://stream.example.com/live/9Gx7pQ2mL8vK4nT1

Do not expose this key in pub­lic JavaScript or appli­ca­tion pack­ages.

Validate publishers

A pro­duc­tion sys­tem should val­i­date:

• stream key;
• user or encoder iden­ti­ty;
• chan­nel sta­tus;
• allowed IP;
• token expi­ra­tion;
• pub­lish­ing per­mis­sions.

Use signed playback URLs

Exam­ple:

https://cdn.example.com/live/channel1/master.m3u8
?expires=1780000000
&token=SIGNED_VALUE

The edge or appli­ca­tion val­i­dates:

• sig­na­ture;
• expi­ra­tion;
• resource path;
• option­al user infor­ma­tion.

Restrict administrative services

Admin­is­tra­tive APIs should be:

• bound to local­host;
• pro­tect­ed by a fire­wall;
• placed behind a VPN;
• authen­ti­cat­ed;
• logged.

Rate-limit abusive requests

Apply lim­its to:

• authen­ti­ca­tion end­points;
• token-gen­er­a­tion end­points;
• API search­es;
• repeat­ed invalid requests;
• account login attempts.

Content protection

Basic projects may use tok­enized URLs or HLS encryp­tion.

Pre­mi­um ser­vices may require plat­form DRM sys­tems and a license serv­er.

DRM archi­tec­ture nor­mal­ly includes:

Packager
License server
Entitlement service
Player integration
Authentication API
Key management

DRM is more com­plex than hid­ing a playlist URL. It should be designed as part of the busi­ness mod­el and device-com­pat­i­bil­i­ty strat­e­gy.

---

⏱️ Managing Latency

Laten­cy is the delay between cap­ture and play­back.

It may be intro­duced by:

• the cam­era;
• encoder buffers;
• net­work trans­port;
• transcod­ing;
• seg­ment dura­tion;
• playlist size;
• CDN caching;
• play­er buffer­ing.

A tra­di­tion­al HLS chan­nel may have sev­er­al sec­onds of laten­cy.

To reduce laten­cy:

1. Short­en seg­ment dura­tion.
2. Use aligned GOPs.
3. Reduce unnec­es­sary buffers.
4. Avoid transcod­ing when it is not required.
5. Place ingest near the encoder.
6. Use a resilient con­tri­bu­tion pro­to­col.
7. Con­fig­ure the CDN for live traf­fic.
8. Reduce the player’s tar­get buffer.
9. Con­sid­er Low-Laten­cy HLS.
10. Con­sid­er WebRTC for tru­ly inter­ac­tive appli­ca­tions.

Reduc­ing seg­ment dura­tion is not free.

Short­er seg­ments increase:

• HTTP requests;
• playlist updates;
• serv­er over­head;
• sen­si­tiv­i­ty to jit­ter;
• CDN com­plex­i­ty.

The cor­rect laten­cy tar­get depends on the prod­uct.

A movie chan­nel may tol­er­ate more delay than a live auc­tion or inter­ac­tive event.

---

🗓️ Creating a 24/7 Linear TV Channel

A stream­ing serv­er dis­trib­utes the chan­nel, but it does not auto­mat­i­cal­ly cre­ate the sched­ule.

For lin­ear tele­vi­sion, you also need a play­out sys­tem.

The play­out decides what should be shown at each time.

Exam­ple sched­ule:

06:00 — Morning News
08:00 — Children’s Program
10:00 — Documentary
11:30 — Commercial Break
12:00 — Midday News
13:00 — Movie
15:00 — Interview Program
17:00 — Sports Magazine
19:00 — Evening News
20:00 — Prime-Time Series

The play­out may man­age:

• pro­gram files;
• live inserts;
• adver­tise­ments;
• sta­tion iden­ti­fi­ca­tion;
• logos;
• bumpers;
• count­downs;
• emer­gency filler;
• sched­ule changes;
• audio nor­mal­iza­tion.

Simple FFmpeg playlist

Cre­ate a file:

playlist.txt

Con­tent:

file 'news.mp4'
file 'bumper.mp4'
file 'documentary.mp4'
file 'commercial.mp4'
file 'interview.mp4'

Run:

ffmpeg \
  -re \
  -f concat \
  -safe 0 \
  -i playlist.txt \
  -c:v libx264 \
  -preset veryfast \
  -b:v 3000k \
  -c:a aac \
  -b:a 128k \
  -f flv \
  rtmp://127.0.0.1/live/channel1

This is accept­able for a lab­o­ra­to­ry.

A pro­fes­sion­al play­out sys­tem should also man­age:

• incon­sis­tent source res­o­lu­tions;
• miss­ing files;
• unex­pect­ed aspect ratios;
• audio loud­ness;
• sched­ule tim­ing;
• live-event switch­ing;
• auto­mat­ed recov­ery;
• pro­gram log­ging;
• adver­tise­ment reports.

---

📅 EPG: Electronic Program Guide

A Smart TV appli­ca­tion becomes more use­ful when it knows what is cur­rent­ly play­ing.

The EPG may include:

• chan­nel name;
• cur­rent pro­gram;
• next pro­gram;
• start and end times;
• descrip­tion;
• poster image;
• rat­ing;
• cat­e­go­ry;
• episode infor­ma­tion.

Exam­ple API response:

{
  "channel": {
    "id": "channel1",
    "name": "Example TV"
  },
  "now": {
    "title": "Morning News",
    "start": "2026-07-10T08:00:00-03:00",
    "end": "2026-07-10T09:00:00-03:00",
    "description": "Daily national and international news."
  },
  "next": {
    "title": "Technology Today",
    "start": "2026-07-10T09:00:00-03:00",
    "end": "2026-07-10T10:00:00-03:00"
  }
}

The TV inter­face can dis­play:

Now: Morning News
Next: Technology Today

For a FAST TV ser­vice, the EPG is cen­tral to nav­i­ga­tion and dis­cov­ery.

---

💾 Adding Video on Demand

The same plat­form may sup­port live and on-demand con­tent.

Live URL

https://stream.example.com/live/channel1/master.m3u8

VOD URL

https://stream.example.com/vod/movie123/master.m3u8

Cre­ate a sim­ple HLS VOD pack­age:

mkdir -p /var/www/vod/movie123
cd /var/www/vod/movie123

Run:

ffmpeg \
  -i /media/movie123.mp4 \
  -c:v libx264 \
  -preset medium \
  -c:a aac \
  -b:a 128k \
  -g 60 \
  -keyint_min 60 \
  -sc_threshold 0 \
  -hls_time 6 \
  -hls_playlist_type vod \
  -hls_segment_filename "segment_%05d.ts" \
  index.m3u8

For a pro­fes­sion­al cat­a­log, also cre­ate:

• adap­tive ren­di­tions;
• sub­ti­tles;
• thumb­nails;
• poster images;
• meta­da­ta;
• cat­e­gories;
• search index­es;
• rec­om­men­da­tion data;
• enti­tle­ment rules;
• resume posi­tion.

---

📈 Monitoring the Streaming Server

A stream can return HTTP 200 and still be bro­ken.

Mon­i­tor­ing should inspect:

• playlist avail­abil­i­ty;
• seg­ment fresh­ness;
• video bitrate;
• audio bitrate;
• res­o­lu­tion;
• frame rate;
• frozen images;
• silence;
• black frames;
• laten­cy;
• buffer­ing;
• CPU;
• mem­o­ry;
• disk usage;
• net­work traf­fic;
• FFm­peg process­es;
• active con­nec­tions;
• HTTP error rates.

Test with FFprobe

ffprobe \
  -v error \
  -show_streams \
  -show_format \
  https://stream.example.com/hls/channel1/master.m3u8

FFprobe is designed to inspect mul­ti­me­dia infor­ma­tion and expose stream and for­mat details for human or auto­mat­ed analy­sis.

Test the HTTP response

curl -I \
  https://stream.example.com/hls/channel1/master.m3u8

Expect­ed response:

HTTP/2 200
content-type: application/vnd.apple.mpegurl

Basic health-check script

#!/usr/bin/env bash

set -u

URL="https://stream.example.com/hls/channel1/master.m3u8"

STATUS=$(curl \
  --silent \
  --output /dev/null \
  --write-out "%{http_code}" \
  "$URL")

if [ "$STATUS" != "200" ]; then
  echo "ALERT: Channel unavailable. HTTP status: $STATUS"
  exit 1
fi

echo "Channel online"

A stronger mon­i­tor should also ver­i­fy that new seg­ments con­tin­ue appear­ing.

A playlist that has stopped updat­ing may still return a suc­cess­ful HTTP response.

---

🔄 Redundancy and Failover

A tele­vi­sion chan­nel should not depend on one process.

A resilient archi­tec­ture may con­tain:

Primary encoder
Backup encoder

Primary ingest
Backup ingest

Primary transcoder
Backup transcoder

Primary origin
Backup origin

Primary CDN
Secondary CDN

The mon­i­tor­ing sys­tem should detect:

• encoder offline;
• no audio;
• no video;
• frozen pic­ture;
• stale playlist;
• FFm­peg crash;
• full disk;
• net­work inter­rup­tion;
• ori­gin fail­ure.

Pos­si­ble recov­ery actions include:

• restart the process;
• switch to the back­up input;
• show an emer­gency slate;
• redi­rect the CDN;
• noti­fy an oper­a­tor;
• launch a back­up vir­tu­al machine.

---

💰 How Much Does a TV Streaming Server Cost?

The cost is deter­mined by more than the VPS price.

Main cost cat­e­gories include:

Cost	Descrip­tion
Com­pute	CPU or GPU transcod­ing
Band­width	Video traf­fic deliv­ered
Stor­age	VOD, DVR, record­ings
CDN	Edge deliv­ery
Mon­i­tor­ing	Met­rics and alerts
DRM	License and key ser­vices
Devel­op­ment	Web­site and Smart TV apps
Play­out	Lin­ear sched­ule automa­tion
Sup­port	Oper­a­tions and inci­dent response
Redun­dan­cy	Back­up sys­tems

Small test project

A small lab­o­ra­to­ry may use:

• one VPS;
• one test chan­nel;
• no CDN;
• one video qual­i­ty;
• lim­it­ed view­ers.

Small professional channel

A pro­duc­tion ser­vice may require:

• ded­i­cat­ed ori­gin;
• mul­ti­ple ren­di­tions;
• CDN;
• HTTPS;
• mon­i­tor­ing;
• back­up process;
• EPG API;
• Smart TV appli­ca­tions.

Large platform

A larg­er ser­vice may require:

• mul­ti­ple transcoders;
• GPU instances;
• mul­ti-region ori­gin;
• sev­er­al CDNs;
• object stor­age;
• DRM;
• ad inser­tion;
• ana­lyt­ics;
• 24/7 oper­a­tions.

Always cal­cu­late pro­ject­ed view­ing hours before launch­ing.

---

❌ Common Streaming Server Mistakes

1. Using shared website hosting

Shared host­ing is usu­al­ly designed for:

• PHP;
• data­bas­es;
• web­sites;
• e‑mail.

It is not nor­mal­ly designed for con­tin­u­ous video transcod­ing, open ingest ports, long-run­ning FFm­peg process­es, or high out­bound traf­fic.

Use a VPS, ded­i­cat­ed serv­er, cloud ser­vice, or spe­cial­ized stream­ing provider.

2. Offering only one bitrate

A sin­gle bitrate cre­ates buffer­ing for slow­er users and wastes qual­i­ty for faster users.

Cre­ate an adap­tive lad­der.

3. Ignoring audio compatibility

A stream may dis­play video but pro­duce no sound.

Use a broad­ly com­pat­i­ble audio for­mat and test on real tele­vi­sions.

4. Failing to align keyframes

Poor­ly aligned GOPs can make adap­tive switch­ing unre­li­able.

Use con­sis­tent GOP val­ues across ren­di­tions.

5. Incorrect MIME types

Use appro­pri­ate types such as:

application/vnd.apple.mpegurl
video/mp2t
video/mp4

6. Missing CORS headers

Web-based play­ers and some appli­ca­tion envi­ron­ments may fail to request media across domains.

Con­fig­ure CORS care­ful­ly.

7. No HTTPS

A secure appli­ca­tion may reject inse­cure media.

Use a valid cer­tifi­cate.

8. Publishing the origin publicly

Users may bypass your CDN.

Pro­tect the ori­gin.

9. No monitoring

Dis­cov­er­ing a fail­ure through view­er com­plaints is not an oper­a­tional strat­e­gy.

Cre­ate auto­mat­ed health checks.

10. Testing only in a desktop browser

A stream that works in Chrome may fail on an old­er tele­vi­sion.

Test on:

• Sam­sung devices;
• LG devices;
• Roku;
• Android TV;
• slow­er net­works;
• Wi-Fi;
• Eth­er­net.

---

✅ Production Checklist

Before launch­ing, ver­i­fy:

[ ] The stream is available over HTTPS
[ ] The domain resolves correctly
[ ] The TLS certificate renews automatically
[ ] HLS MIME types are correct
[ ] CORS is configured
[ ] At least three video renditions exist
[ ] GOPs are aligned
[ ] Segment durations are consistent
[ ] Audio is present and synchronized
[ ] Stream keys are protected
[ ] Administrative ports are restricted
[ ] The CDN is configured
[ ] The origin is protected
[ ] Monitoring is active
[ ] Alerts reach the technical team
[ ] FFmpeg restarts automatically
[ ] The server has sufficient disk space
[ ] Logs are rotated
[ ] Backups exist
[ ] Smart TV applications handle playback errors
[ ] Players retry after connection loss
[ ] The content has proper distribution rights
[ ] Real televisions have been tested

---

❓ Frequently Asked Questions

Can I create a streaming server for free?

You can use open-source soft­ware such as FFm­peg, SRS, and NGINX with­out buy­ing a tra­di­tion­al soft­ware license.

How­ev­er, pro­duc­tion still has costs:

• serv­er rental;
• band­width;
• domain;
• stor­age;
• CDN;
• mon­i­tor­ing;
• appli­ca­tion devel­op­ment.

Can I use my home computer?

A home com­put­er can be used for test­ing.

It is risky for pro­duc­tion because of:

• pow­er out­ages;
• unsta­ble upload;
• dynam­ic IP address­es;
• res­i­den­tial traf­fic lim­its;
• lack of redun­dan­cy;
• hard­ware fail­ure.

How many viewers can one server support?

It depends on:

• aver­age bitrate;
• avail­able out­bound band­width;
• CPU usage;
• num­ber of con­nec­tions;
• disk per­for­mance;
• whether a CDN is used.

A the­o­ret­i­cal 500 Mbps out­bound con­nec­tion serv­ing 3 Mbps streams would sup­port few­er than:

500 ÷ 3 = 166 viewers

The prac­ti­cal lim­it should be low­er because capac­i­ty must be reserved for over­head and traf­fic vari­a­tion.

Do I need a CDN?

Not nec­es­sar­i­ly for a local test.

A CDN becomes increas­ing­ly use­ful for:

• nation­al audi­ences;
• mul­ti­ple regions;
• live events;
• hun­dreds or thou­sands of view­ers;
• traf­fic spikes;
• ori­gin pro­tec­tion.

Which video codec should I use?

For broad com­pat­i­bil­i­ty, H.264 remains a prac­ti­cal base­line.

More effi­cient codecs may reduce band­width but require care­ful device test­ing.

Which audio codec should I use?

AAC is wide­ly used in tele­vi­sion stream­ing work­flows.

Always test the exact pro­file, chan­nel lay­out, sam­pling rate, and bitrate on your tar­get devices.

Can I host several channels?

Yes.

Use dif­fer­ent stream names:

rtmp://stream.example.com/live/news
rtmp://stream.example.com/live/sports
rtmp://stream.example.com/live/movies

Pos­si­ble out­puts:

/live/news.m3u8
/live/sports.m3u8
/live/movies.m3u8

Can I monetize the channel?

Pos­si­ble busi­ness mod­els include:

• sub­scrip­tions;
• adver­tis­ing;
• spon­sor­ships;
• pay-per-view;
• trans­ac­tion­al video;
• FAST chan­nels;
• licens­ing;
• pre­mi­um mem­ber­ships.

You must own or license the rights to dis­trib­ute the con­tent.

---

🏁 Conclusion

Cre­at­ing a TV stream­ing serv­er requires sev­er­al coor­di­nat­ed sys­tems.

The com­plete path is:

Camera, OBS, or Playout
          ↓
      RTMP or SRT
          ↓
         SRS
          ↓
       FFmpeg
          ↓
 Adaptive HLS Packaging
          ↓
    NGINX and HTTPS
          ↓
          CDN
          ↓
 Samsung, LG, Roku, Android TV

SRS can receive and con­vert live-stream­ing pro­to­cols. FFm­peg can encode and trans­form media. NGINX can expose playlists and seg­ments through HTTP or HTTPS. A CDN can dis­trib­ute the traf­fic at scale. Smart TV appli­ca­tions pro­vide the view­er-fac­ing expe­ri­ence.

Begin with a lab­o­ra­to­ry:

1. Cre­ate an Ubun­tu serv­er.
2. Install Dock­er.
3. Run SRS.
4. Pub­lish a stream through OBS.
5. Test the HLS out­put.
6. Con­fig­ure FFm­peg transcod­ing.
7. Cre­ate mul­ti­ple ren­di­tions.
8. Add NGINX.
9. Con­fig­ure HTTPS.
10. Test on real tele­vi­sions.

After the foun­da­tion is sta­ble, expand the plat­form with:

• mul­ti­ple chan­nels;
• 24/7 pro­gram­ming;
• EPG;
• VOD;
• sub­scrip­tions;
• adver­tis­ing;
• ana­lyt­ics;
• DRM;
• CDN failover;
• back­up ori­gins;
• pub­lished Smart TV appli­ca­tions.

A well-designed stream­ing serv­er can grow from a sin­gle exper­i­men­tal chan­nel into a com­plete OTT or FAST TV plat­form.