Live camera streaming za vise prodavnica uz Nginx, FFmpeg i Supervisord

Ponekad prava streaming platforma zapravo nije platforma.

Ovaj projekat je poceo od prakticnog zahteva: obezbediti live camera feed-ove iz vise prodavnica za interne zaposlene kroz odvojene web kabinete, bez uvodjenja teskog video stack-a, bez snimanja i bez gradjenja resenja oko nepotrebnih apstrakcija.

Cilj je bio jednostavan:

• povezati vise lokacija prodavnica
• prikazati live camera feed-ove u browser-u
• pokretati i zaustavljati stream-ove na zahtev iz backend-a
• odrzati sistem operativno jednostavnim
• ostaviti prostor za dodavanje novih prodavnica kasnije

Konacno resenje koristilo je minimalan stack:

• FFmpeg za ingest
• Nginx kao RTMP i HLS sloj
• Supervisord za pokretanje streaming procesa na zahtev
• HLS za playback u browser-u
• RTMP kao medjusloj za transport

Transcoding nije bio potreban. Kamere su vec slale stream-ove u odgovarajucem codec-u, pa je sistem mogao da ostane fokusiran na transport i isporuku, a ne na obradu videa.

Zahtevi

Pocetni rollout obuhvatio je:

• 4 lokacije prodavnica
• 2 kamere po lokaciji
• 8 camera feed-ova ukupno

Ocekuje se rast broja povezanih prodavnica.

Od pocetka je sistem morao da podrzi:

• vise odvojenih konteksta prodavnica
• iskljucivo live streaming
• backend-kontrolisan lifecycle stream-ova
• playback prilagodjen browser-u
• minimalan operativni overhead

Snimanje je bilo izricito van opsega u ovoj fazi. To je pomoglo da arhitektura ostane manja i predvidivija.

Zasto ovaj pristup

Nije bilo potrebe za punom video platformom.

Workload nije zahtevao:

• transcoding u vise bitrate varijanti
• dugorocno skladistenje
• DVR playback
• kompleksnu federaciju pristupa
• distribuciju ka velikoj javnoj publici

Bilo je potrebno pouzdano i razumljivo resenje od camera feed-a do playback-a u browser-u.

Zato je lagan stack bio bolji izbor od teze media platforme.

Princip dizajna bio je jednostavan:

resiti stvarni problem isporuke, a ne hipoteticki problem buduce platforme.

Arhitektura

Na visokom nivou, tok izgleda ovako:

  flowchart LR
    A[Store cameras] --> B[FFmpeg ingest]
    B --> C[Nginx RTMP]
    C --> D[HLS output]
    D --> E[Browser clients]
    F[Backend] --> G[Supervisord]
    G --> B

Komponente

FFmpeg

FFmpeg je zaduzen za ingest camera feed-a i njegovo slanje u streaming pipeline.

U ovom setup-u koristi se kao praktican alat za transport, a ne kao transcoding engine. Posto sve kamere vec salju video u kompatibilnom codec-u, nema potrebe da se CPU trosi na re-encoding.

To znacajno pojednostavljuje sistem:

• manje CPU opterecenje
• manje pokretnih delova
• manja latencija uvedena obradom
• jednostavnije operativno razumevanje sistema

Nginx

Nginx ovde ima dve uloge:

• RTMP kao medjusloj za streaming
• HLS output za playback u browser-u

Svaki stream se upisuje u svoj HLS direktorijum na osnovu imena stream-a. To jasno odvaja output i olaksava backend-u ili frontend sloju da pravilno mapira stream-ove na odgovarajucu prodavnicu ili kabinet.

Ova struktura takodje cini isporuku predvidivom:

• jedno ime stream-a
• jedna output putanja
• jedan playback cilj za browser

Supervisord

Stream-ovi nisu namenjeni da rade stalno.

Pokrecu se i zaustavljaju iz backend-a po potrebi, a Supervisord se koristi kao process manager koji zaista pokrece FFmpeg procese.

To je vazan deo dizajna.

Umesto da se prerano gradi veci orchestration sloj, projekat koristi jednostavan i proveren process supervisor:

• backend odlucuje kada stream treba da pocne
• Supervisord pokrece odgovarajuci proces
• FFmpeg radi ingest i salje stream u Nginx
• browser klijenti preuzimaju HLS output

To odrzava kontrolnu logiku jednostavnom i sprecava da lifecycle stream-ova preraste u poseban infrastrukturni problem.

Zasto RTMP plus HLS

Ova kombinacija postoji sa razlogom.

RTMP kao medjusloj

RTMP dobro funkcionise kao stabilan interni handoff format izmedju ingest i delivery sloja.

U ovom slucaju koristi se kao praktican medjusloj za transport:

• FFmpeg ga lako publish-uju
• Nginx ga lako prima
• jednostavno se organizuje oko imena stream-ova
• dobro odgovara internoj relay arhitekturi

Poenta ovde nije modernost. Poenta je korisnost.

HLS za playback u browser-u

Browser-i ne koriste RTSP direktno na praktican i prenosiv nacin za ovakav interni web workflow.

HLS frontend-u daje format isporuke sa kojim je mnogo lakse raditi u browser-based kabinetima.

To znaci da zaposleni mogu pristupati stream-ovima kroz postojeci web interfejs bez posebnog desktop softvera ili direktne konekcije ka kamerama.

Zasto nema transcoding-a

Ovo je bilo jedno od najvaznijih pojednostavljenja.

Sve kamere su pripadale istoj porodici modela i vec su slale video u potrebnom codec-u. Zbog toga stack nije morao da trosi compute na konverziju formata.

To menja profil celog sistema.

Bez transcoding-a:

• CPU vise nije glavni problem
• mreza postaje dominantan resurs
• pokretanje stream-a ostaje jednostavnije
• operativni otisak ostaje manji
• planiranje kapaciteta je lakse

To je bio tacno pravi tradeoff za ovaj projekat.

Sistem je namenjen da efikasno prosledjuje live video, a ne da ga transformise.

Backend-kontrolisan lifecycle

Jos jedan praktican zahtev bio je da stream-ovi ne rade stalno.

Stream-ovi se ukljucuju i iskljucuju iz backend-a kada su potrebni u kabinet interfejsu. To je vazno i zbog operativne kontrole i zbog potrosnje resursa.

Taj model ima smisla kada:

• nisu svi feed-ovi potrebni stalno
• korisnici otvaraju stream-ove na zahtev
• infrastruktura treba da ostane fokusirana na stvarnu upotrebu
• lifecycle procesa treba da ostane vezan za logiku aplikacije

U ovom dizajnu aplikacija je zaduzena za nameru, a Supervisord za izvrsenje.

Takvo razdvajanje je jednostavno i korisno.

Skaliranje dalje od prvih prodavnica

Trenutna faza je dovoljno mala da sistem ostane lak za razumevanje:

• 4 prodavnice
• 8 kamera
• HD feed-ovi
• samo live pristup

Ali struktura je namerno spremna za vise prodavnica.

Vazno je da se rast ovde uglavnom svodi na:

• vise definicija stream-ova
• vise upravljanih FFmpeg procesa
• veci mrezni throughput
• nastavak discipline u imenovanju i izolaciji stream-ova

Ovo jos nije problem koji zahteva prepisivanje u media platformu.

To je vazno jer se mnogi sistemi preopterete kompleksnoscu pre nego sto budu stvarno korisceni.

Minimalan stack je na pocetku cesto skalabilnija odluka, jer odrzava operativni model jasnim dok se stvarni obrasci koriscenja tek formiraju.

Zasto je ovo bio dobar izbor

Ovaj pristup dobro radi kada zahtevi izgledaju ovako:

• interni live streaming
• playback u browser-u
• poznat format kamera
• bez transcoding-a
• bez snimanja
• umerena skala
• jasno backend vlasnistvo nad lifecycle-om stream-ova

Posebno je koristan kada je jednostavnost prednost, a ne kompromis.

Stack ostaje lak za objasniti:

• camera feed ulazi
• FFmpeg publish-uju
• Nginx distribuira
• HLS se koristi u browser-u
• Supervisord upravlja lifecycle-om procesa

To je mnogo laksi sistem za odrzavanje nego velika video platforma uvedena prerano.

Gde ovaj pristup nije dobar izbor

Ovaj dizajn nije univerzalan.

Drugo resenje bi imalo vise smisla ako bi sistem zahtevao:

• snimanje i retention
• vise codec ili bitrate varijanti
• distribuciju velikoj javnoj publici
• naprednu kontrolu pristupa na media sloju
• adaptive multi-bitrate paketiranje u vecoj skali
• dublju analitiku kvaliteta playback-a

Takvi zahtevi vode sistem ka drugoj klasi arhitekture.

Ovde to nije bio slucaj.

Operativne lekcije

Nekoliko prakticnih lekcija iz ovog setup-a moze se ponovo primeniti.

1. Minimalno je cesto dovoljno

Ako kamere vec salju odgovarajuci codec i playback u browser-u moze da se resi kroz HLS, nema razloga da se po default-u dodaju transcoding ili tezi media sloj.

2. Backend kontrola pojednostavljuje potrosnju resursa

Pokretanje stream-ova na zahtev umesto stalnog rada svega drzi sistem blize stvarnom korisnickom ponasanju.

3. Process supervision ne mora biti komplikovan

Supervisord je sasvim razuman izbor kada je potrebno kontrolisano start/stop ponasanje za poznat procesni model.

4. Playback u browser-u menja arhitekturu

Glavni razlog za HLS ovde nije teorijska preferencija protokola. To je prakticna web isporuka.

5. Jednostavnost poboljsava odrzavanje

Mali i razumljiv stack je lakse prosiriti nego prenaduvan stack uveden pre nego sto se pojave stvarna ogranicenja.

Isporuka

• Dizajn arhitekture za live-only camera streaming
• Stream ingest setup uz FFmpeg
• RTMP relay sloj uz Nginx
• HLS output struktura po stream-u
• Backend-kontrolisan lifecycle stream-ova
• Process management zasnovan na Supervisord-u
• Model integracije po prodavnici i kabinetu
• Strategija imenovanja stream-ova i razdvajanja output-a
• Browser-kompatibilan delivery put
• Pocetni rollout za vise prodavnica i camera feed-ova

Vreme isporuke

Pocetna implementacija isporucena je kao fokusirani integracioni rad za prvi produkcioni rollout.

Klucni rezultat nije bio samo sam transport stream-ova, vec i praktican operativni model:

• pokretanje stream-a iz backend-a
• predvidiv output po stream-u
• browser-kompatibilna isporuka
• minimalan stack bez teske video platforme

Glavni zakljucak

Ovom projektu nije bila potrebna video platforma.

Bio mu je potreban funkcionalan streaming put za stvarne operacije.

Koriscenjem Nginx, FFmpeg, RTMP, HLS i Supervisord, rezultat je bio mali i razumljiv sistem koji:

• isporucuje live camera feed-ove u browser-u
• podrzava vise lokacija prodavnica
• pokrece stream-ove na zahtev
• ostaje dovoljno jednostavan za odrzavanje i prosirenje

To je cesto bolji inzenjerski izbor.

Ne najveci stack.
Nego pravi.

Povezane usluge

• Observability i Monitoring