RTMP eller SRT streaming

12 december 2019 Skrevet af 
i Blogs
  • Skriftstørrelse
Bedøm denne artikel
(0 bedømmelser)
RPI4 with Camlink DIY Filip Stadler RPI4 with Camlink DIY Filip Stadler RPI4 with Camlink DIY Filip Stadler

SRT er en kommende og bedre erstatning for RTMP protokollen til streaming.

Den aktuelle RTMP protokol er ikke optimal til mobile netværk og wifi - derfor experimentere jeg med SRT som streamning protokol mellem kamera enhed og OBS.
Evt. publisering på websider vil dog være en blanding af rtmp og hls lidt endnu - men hvor rtmp ofte benytter TCP så benytter SRT sig normalt af UDP pakker der kan sendes som unicast eller multicast.

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.

 

SRT Alliance

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

 

Ubuntu/RaspberryPI Rasbian Buster on way to be SRT Ready

sudo git clone https://github.com/Haivision/srt
cd srt

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install tclsh pkg-config cmake libssl-dev build-essential
sudo ./configure
sudo make

# We need SRT to be installed in the system also to be SRT Ready !

sudo make install

# If you like to Compile a ffmpeg on Rasberry with OMX enable h264_omx

git clone https://github.com/FFmpeg/FFmpeg.git
cd FFmpeg

sudo -s

export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"

 ./configure --arch=armel --target-os=linux --enable-gpl --enable-omx --enable-omx-rpi --enable-libx264 --enable-libx265 --enable-libx265 --enable-nonfree --enable-mmal --enable-libsrt

 make

The ffmpeg is not installed but its compiled and ready to run in your current working directory.

(this is mabye /home/pi/ffmpeg) :)

On the big OBS/VLC vmix computer:

#!/bin/bash
echo "We Listen for the SRT on 9001 and Publish on 127.0.0.1:4002"
srt-live-transmit srt://:9001 udp://127.0.0.1:4002&vlc udp://@:4002

On the CAM2 raspberryPI computer:
# I my setup I have a rasberryPI4 called cam2 and I would like to make a SRT connection to my OBS computer
# I run this this to make a way for the SRT traffic outgoing from CAM2 on port 9001

#!/bin/bash
echo "To be or not to be SRT Ready....please note if your rouer/firewall needed to do udp port forward"
echo "Else just replace (srt.undergroundnews.dk) with the local ip of the OBS/VLC/vmix computer on a local area network."

# This only needed if you ffmpeg or OBS does not come with the srt protocol allReady included ;)


tx="/home/pi/srt/srt-live-transmit -v udp://127.0.0.1:4002:pkt_size=1316&bitrate=5500000 srt://srt.undergroundnews.dk:9001"
$tx&

# Now You will have a SRT way to test SRT from CAM2 to local udp port 4002 and this will become a srt stream
# for the destination

#!/bin/bash
destination="udp://127.0.0.1:4002?pkt_size=1316&bitrate=5500000"
ffmpeg="ffmpeg"
#ffmpeg=/"home/pi/FFmpeg/ffmpeg"

$ffmpeg -f lavfi -re -i smptebars=duration=30:size=1920x1080:rate=25\
 -f lavfi -re -i sine=frequency=1000:duration=30:sample_rate=44100 -pix_fmt yuv420p\
 -c:v h264_omx -b:v 4M -g 25 -keyint_min 120 -profile:v baseline\
 -f mpegts $destination

==============================================

My Current RP4 Script look like this

#! /bin/bash
# Undegroundnews.dk RaspberryPI4

printf "\n### Live Stream\n"

#OBS_DEST="-f flv rtmp://stream.undergroundnews.dk/appname/key"

# The udp://127.0.0.1:4002 is really a SRT Ready Destination ;)
# echo "To be or not to be SRT Ready...."
# srt-live-transmit -v udp://127.0.0.1:4002:pkt_size=1316&bitrate=5500000 srt://{public ip}:9001"
# Remember to do a port forward in your firewall to your OBS/VLC/VMIX

OBS_DEST="-f mpegts udp://127.0.0.1:4002?pkt_size=1316&bitrate=5500000"


# If srt is supported by your ffmpeg just do
#OBS_DEST="-f mpegts srt://srt.undergroundnews.dk:4001?pkt_size=1316&bitrate=5500000&passphrase=secretdemokey"

##########################################################################
# SSL Stunnel destination to facebook via 127.0.0.1 note port 127.0.0.1:19350 is used in stunnel
#OBS_DEST="-f flv rtmp://127.0.0.1:19350/rtmp/{yourkey}"

#####################


#Videocodec="h264"
Videocodec="h264_omx"
#Videocodec="libx265"
#Videocodec="libx264"
#Videocodec="mpeg2video"

VideoDev="/dev/video0"
AudioDev="hw:1,0"

# -pix_fmts
#Pixelformat="yuv420p"
#Pixelformat="yuv422p"

#printf "\n### Resets usb device first\n"

# Camlink problem test
# sudo usbreset 0fd9:0061
# camlink 4K
# sudo usbreset 0fd9:0066
# echo "Waiting 30 secs"
# sleep 30


printf "\n### Ready to start Transmission using $Videocodec codec\n"

ffmpeg -hide_banner -f alsa -ac 2 -i $AudioDev -re -f v4l2 -i $VideoDev -c copy -vcodec $Videocodec\
 -acodec aac -b:a 128k -ar 44100\
 -qmin 2 -qmax 51 -b:v 4M -maxrate:v 100M -g 50 -keyint_min 25\
 -crf 18\
 -tune zerolatency \
 -preset veryfast \
-flags +global_header\
 $OBS_DEST

printf "\n### End of the streaming transmission\n"


Depending on your ffmpeg compilation replace h264_omx with normal libx264 also my own compilation did not understand the -preset veryfast and I don't know why for sure ? but maybe some ffmpeg guru can give me a hint ;)

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

 


 

9257 Senest ændret Søndag, 23 maj 2021 14:28
Mere i denne kategori: