Hvis du prøver at google oplysninger omkring SRT så finder du henvisninger til noget som er en metode til at lave undertitler til video og det er det så også men SRT er en forkortelse for Secure Reliable Transmission.
En sikker og stabil transmission som altså er hurtigere end rtmp via tcp og hurtig som udp.
Real-Time Messaging Protocol (rtmp) er meget benyttet til videostreamning fra en bruger til youtube/facebook osv. men den er ikke specielt hurtig og der en del evt. unødvendig trafik mellem sender og modtager som SRT ikke laver.
Andre protokoler findes som kan pause en stream og man har behov for at kontrollere data strømmen mellem modtager og afstender og evt. udfald/tab af data pakker sker så skal modtageren måske sige hvis den har modtaget 5 pakker men stadig mangler pakke nr 3 ud af måske 100 så skal den bede om at få pakke nr 3 igen og dette skal den gøre inden at den evt. må beslutte sig for at forsætte videre uden men på dette område skulle SRT netop være betydeligt bedre og hurtigere end RTMP.
Jeg har så besluttet mig for at begrænse brugen af rtmp en lille smule nu og få lidt praktisk erfaring med fremtidens streamning protokol SRT men RMTP samt HLS er dog forsat benyttet til udgående streams til facebook rtmps og youtube etc.
Det er min tanke at jeg vil afprøve fordelen med SRT mellem kamera og evt. OBS som så modtager nogle kamera streams via SRT fra min Raspberry PI4 med Elgato Capture endhed på USB3.
Derudover er en konvertering fra SRT til RTMP/RTMPS via FFMPEG/VLC konvertering/gateway som så kan man let restreame data videre til evt. tjenester rtmp/s som ikke har eller tilbyder SRT muligheden endnu.
VLC player skulle håndtere SRT og via UDP dermed skulle OBS/VLC og tilsvarende fint kunne inkludere SRT hvis jeg er lidt heldig - ellers er det måske ligesom med min installeret FFmpeg noget som også skal compileres med i VLC playeren.
Det vil sige at foruden rtmp så vil jeg lave en SRT restreamning tjeneste fordi eks. You/Facebook har måske ikke en SRT mulighed endnu og fordelen ved srt er jo synlig og hvis et mobilt kamera via wifi kan give en bedre udgående stream så er SRT bonus og et alternativ til Zixy.
En række virksomheder dvs. mere end 300 virksomheder har allerede taget SRT til sig fordi den er fri og Opensource faktisk ganske godt dokumenteret og meget bedre end RTMP så det ikke altid det bedste som er det mest udbredte men omvendt så ville det ikke blive inkluderet i flere produkter hvis det ikke også var fordi man kan se værdien i at hvad SRT evt. har og tilbyde som en Open og fri standard til at erstatte den benyttede RTMP på længere sigt - de er begyndt at skrive på deres produkter at de er SRT Ready og der implementering til mange platforme.
Jeg vil dog anbefale at man kigger på deres eksempler og deres logo er en link til deres alliance hvor man også kan se eksempler på hvordan SRT virker.
Sourcekoden til SRT kan downloades på https://github.com/Haivision/srt
UPDATE - NY Guide til SRT compilering findes her
sudo git clone https://github.com/Haivision/srt
# We need SRT to be installed in the system also to be SRT Ready !
sudo -s
export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"
#!/bin/bash
==============================================
My Current RP4 Script look like this
|
Herunder vises eksempel på hvordan SRT klare en 4K stream med 2% pakke tab på en 4mbit stream og det er jo ikke så tosset kvalitet inklusiv mindre delay.
Det kan være en option og benytte TCP istedet for UDP (måske).
En rigtig god forklaring på hvordan SRT virker og hvorfor det mere giver mening at overveje denne protokol frem for rtmp og evt. som en fattigmands udgave af Zixi.
Undergroundnews er nu SRT Ready med srt-->rtmp-->hls løsninger på vej.
En metode med en ffmpeg som understøtter srt kan være at lave rtmp :
./ffmpeg -i srt://:4000?mode=listener -c copy -f flv rtmp://127.0.0.1:1935/live/streamkey
SRT Vmix/Setup
Zixi
En anden tilsvarende protokol er Zixi som bla. JVC er nu begyndt at benytte i deres kamera og den er dog heller ikke fri/opensource og der ligesom nogle internet servere som skal modtage data og sende det videre det typisk og ofte OpenSource baseret servere vi kan godt forvente at rtmp vil blive skiftet ud med nogle bedre protokokoler og metoder indbygget i streamning tjenester og vores udstyr som kamera osv.
En ret god video viser lidt nogle eksempler på hvorfor Zizi er bedre end RTP men Zicy den er ikke ikke fri og på licens - så det begrænset hvem der kan være med her hvor SRT er veldokumenteret.
NDI
NDI fra er ikke heller ikke fri og helt OpenSource - selvom den er delvis tilgængelig for OBS så besluttede Newtek sig pludselig for koden ikke kunne benyttes af FFMPEG og et eller andet licens bølv også blev NDI fjernet fra FFMPEG.
Se mere vdr. ffmpeg og Newtek licens udfordringer her hvor de ikke kunne sælge FFmpeg sammen med deres kode hvis den ikke var på samme licens vilkår.
Der findes dog ældre udgaver af ffmpeg findes som så har haft NDI muligheden men i det er næsten blot en Unicast/Mulicast via UDP med en udvidet index tjeneste og oversigt som kan laves via
andre metoder som SAP og mdns (apples bounjour) med en praktisk oversættelse af navne til ip adresser og porte - men NDI er alligevel også en relevant standard som er blevet populær for netværks streams.
Jeg har afprøvet NDI på Linux og OBS samt windows hvilket også virker men jeg har brug for FFMPEG eller VLC håndtere de ønskede protokoller og playout bliver i sidste ende en rtmp/hls stream på webserveren lige nu som stadard men også mellem server og klient vil der ske ændringer med de aktuelle benyttede metoder hvor webRTC også er en stream kommunikations protokol som vil blive benytte mere.
RTMP - selvom er bøvlet og mindre klog er det jo anvendt flere steder så for historiske årsager har vi den dybere forklaring ;)
HLS