Live Streaming Options


HLS/DASH:
HTTP segmentation based, high latency
As static HTTP content, well received by players, whether web or native based, and efficient on CDN
distributed by standard HTTP server.
RTSP:
Standard protocol for IP camera video output. Weak browser play support.
Requires router configuration when video source if behind NAT since streaming server have to pull video from video source.
Low latency
RTMP:
Popular with video source since source pushes to streaming server, and therefore no router work is needed when video source is behind NAT.
Low latency
WebRTC:
I believe this will be the protocol to deliver low latency video to browser.
supported by Chrome and Firefox. I don’t include IE/Safari plugin as it requires installation.
Support both VP8/VP9 and H.264 through OpenH264 and ffmpeg
Here is a little page that renders the laptop camera:
http://riowing.net/local/webRTC.htm tested on Edge (Chrome requires https or localhost)

Reference:
https://www.3cx.com/webrtc/which-browsers-support-webrtc
https://www.chromestatus.com/feature/6417796455989248

Advertisements

VLC Streaming


Sample commands of VLC as streaming server on windows 10. Client uses vlc.exe menu Media – Open Network Stream.
set VLC=D:\VLCPortable223\VLCPortable.exe
set MEDIA=Gym2017bshort.mp4
http:
Server: %VLC% –intf dummy –sout=#std{access=http,mux=ts,dst=0.0.0.0:8080} %MEDIA%
Client: http://localhost:8080
rtp: over udp
Server: %VLC% -vvv %MEDIA% –sout “#transcode{vcodec=h264,vb=0,scale=0,acodec=mpga,ab=128,channels=2,samplerate=44100}:rtp{dst=127.0.0.1,port=8080,mux=ts,ttl=10}”
Client: rtp://@:8080
udp:
Server: %VLC% -vvv %MEDIA% –sout “#transcode{vcodec=h264,vb=0,scale=0,acodec=mpga,ab=128,channels=2,samplerate=44100}:std{access=udp,mux=ts,dst=127.0.0.1:8080}”
Client: udp://@:8080
rtsp:
Server: %VLC% -vvv %MEDIA% –sout “#transcode{vcodec=h264,vb=0,scale=0,acodec=mpga,ab=128,channels=2,samplerate=44100}:rtp{sdp=rtsp://127.0.0.1:8080/test}”
Client: rtsp://127.0.0.1:8080/test
multicast:
Server: %VLC% -vvv %MEDIA% –sout “#transcode{vcodec=h264,vb=0,scale=0,acodec=mpga,ab=128,channels=2,samplerate=44100}:rtp{dst=239.255.12.42,port=8080,mux=ts,ttl=10}”
Client: rtp://239.255.12.42:8080
Remotely control server:
Start server: %VLC% –intf rc –rc-host 127.0.0.1:12345 –sout=#std{access=http,mux=ts,dst=0.0.0.0:8080}
Open command console: telnet localhost 12345
enter: add Gym2017bshort.mp4
Start client: http://localhost:8080
In telnet console, before reaching end of media, enter this command to seek media:
seek 1%

Adaptive Streaming on Player Side


I beleive this is how the player switches from one resolution to another on HLS, but I have not found any documentation describing this process on the internet to verify.
First of all, simply switching from, e.g. HighRes0008.ts to LowRes0008.ts, doesn’t work.
1. Most often, HighRes0008.ts desn’t start with a IDR, which make descoding this segment impossible.
2. Even it starts with IDR, they may not be lined up on the frame level.
How the player switch:
1. In preparation to switch to lower resolution, player traces backward on the low resolution play list until it reaches an IDR.
2. based on the PTS on the high resolution playlist, it decides the PTS on the low resolution playlist, which is being switched to. Assuming the destination frame number ID is frame# 481.
3. decodes the low resolution playlist, from IDR to frame# 481, and renders that frame when time comes.
.ts segment contains PES, which in turn contains ES. The PTS is in the PES header.
PCR is only at the .ts layer, which I don’t think is needed in this use case, as long as PTS for audio and video are based on same PCR.
The same layer structure applies to audio too: TS – PES – ES (e.g. hold AAC data)

RTP over RTSP


Why: to simply router configuration, so that only one fixed port number, 554, needs to accept connection.
How: Server sends video in the response of PLAY command. For each channel the format is like this:
[ Dolloar sign $, one byte channel ID, two bytes to say length of data, stream data itself ]
Channel ID is defined in SETUP response for that channel, e.g. RTP/AVP/TCP;unicast;interleaved=0-1, where 0 is RTP and 1 is RTCP. The stream data is sent as binary.
Head up: If RTSP wants RTP to be TCP based, RTP must be embedded into PLAY response, and therefore no such thing as RTP TCP port.
Reference: http://www.ietf.org/rfc/rfc2326.txt
https://www.ietf.org/mail-archive/web/mmusic/current/msg02030.html