Video smear observed with RTT=90m and latency=400ms over a ethernet interface #147
Comments
|
Can anyone suggest how I can improve video quality by changing any other parameters? |
|
In general, please don't forget that by default SRT does "TLPKTDROP", that is, if the lost packet is not recovered in time (that is, before the next-to-lost packet becomes ready to play), it's dropped. If you are experiencing this too often, this simply means that your network is not fast enough for the current value of the latency (default 120ms). Increasing the latency will make the video more delayed towards the sending site, but will give the receiver more time to recover lost packets and this way decrease the chance for "Too Late Packet Drop" to fire. Turning off TLPKTDROP is rather a bad idea because it will tear the sending speed in case when a packet lingers too long with recovering, and this way you'll see scraps on the video anyway. If you experience a UDP packet reordering (also by testing through If you want to know what really happens at the receiver side, make sure that you compile with logs enabled (use |
|
One more thing here. I can see that the source stransmit sending reads the input from UDP. It's possible at least in theory that the packets are being dropped already there. Because I can't see any packet lost reported in the stats. If you can, please try to repeat the test with feeding the source data to stransmist through the pipe ( |
|
Ethouris, Ok, I will test today and update it here. I am testing master branch. Is it stable enough? Suggest me, otherwise. |
|
At least |
|
Ethouris, Here are the commands that I used. Let me know, if I am wrong. Sender side command: Receiver side command: ======= SRT STATS: sid=342177881 |
|
In one occasion, receiver side SRT is printing stats with lots of lost packets. ======= SRT STATS: sid=192438995 |
|
Ok, I can see, we need some good guide for live video streaming using SRT. I'll try to explain the problem short: Tools such as VLC or |
|
I found some instructions how to do it in Issue #86. There's some option that states the live transmission, and this |
|
If you don't pass packet size, stransmit sets it to DEFAULT_CHUNK, which is defined as 1316. Here is the snippet of the code from stransmit.cpp. Do I have to set VLC or ffmpeg's output stream size to 1316 as well? |
|
You have to make sure that the data will be sent in 1316-bytes portions. It's more significant for UDP because when stransmit reads UDP, it simply gets up to 1316 bytes in one call, so if there is more available, it will be lost. From the pipe, stransmit shouldn't lose anything, but if chunks on the input are bigger, the timing for the data may get serious discrepancy, which will lose all the advantages of SRT and its "delivery time smoother".
|
|
Ok, I will try to test and update here. Thanks. |
|
VLC is sending 1316 byes, which matches to SRT packet size, to localhost:11111 |
|
Try to make VLC send to standard output instead and see what happens. Try also to read the stream via UDP from VLC and save it to a file directly. It has happened several times that I've observed disturbances when too many applications at a time do live streaming over UDP on the same machine. |
|
Ethouris, I am using following command to send a movie file to stdout and then piping it to stransmit via stdin. vlc ../big_buck_bunny_720p_h264.mov --sout '#transcode{vcodec=h264,scale=Auto,acodec=mpga,ab=128,channels=2,samplerate=44100}:file{mux=mp4,dst=/dev/stdout,no-overwrite}' | ./stransmit file://con srt://10.1.30.7:22222?mode=rendezvous&latency=300 I see that the vlc is playing 10 minute video in just couple minutes and receiver side vlc does not display anything. Any insight |
|
You know, this is a process involving multiple parts, any of which may fail to work. Start with: You can also use a dummy pipe from stransmit (both arguments specified as Also use Stransmit cannot read faster than the input data are delivered. When the data are not available at the time when stransmit is trying to read them, it's waiting until they are available. |
|
I followed your suggestions and noticed that the ffplay does not play anything either. I think some command line arguments in vlc is wrong. vlc ../big_buck_bunny_720p_h264.mov --sout '#transcode{vcodec=h264,scale=Auto,acodec=mpga,ab=128,channels=2,samplerate=44100}:file{mux=mp4,dst=/dev/stdout,no-overwrite}' | ffplay - |
|
After I changed mux to ts from mp4, the following command works and ffplay plays movie. vlc ../big_buck_bunny_720p_h264.mov --sout '#transcode{vcodec=h264,scale=Auto,acodec=mpga,ab=128,channels=2,samplerate=44100}:file{mux=ts,dst=/dev/stdout,no-overwrite}' | ffplay - However, I see same issue if feed it to stransmit via stdin. vlc ../big_buck_bunny_720p_h264.mov --sout '#transcode{vcodec=h264,scale=Auto,acodec=mpga,ab=128,channels=2,samplerate=44100}:file{mux=ts,dst=/dev/stdout,no-overwrite}' | ./stransmit file://con srt://10.1.30.7:22222?mode=rendezvous&latency=300 |
|
As I said, try dummy pipe first, then stransmit to a file. And use |
|
You mean like this? vlc | stransmit file://con file://con | ffplay - |
|
The following command works fine too. vlc ../big_buck_bunny_720p_h264.mov --sout '#transcode{vcodec=h264,scale=Auto,acodec=mpga,ab=128,channels=2,samplerate=44100}:file{mux=ts,dst=/dev/stdout,no-overwrite}' | stransmit file://con file://con | ffplay - |
|
Try this rendezvous then with |
|
I am always using rendezvous mode. I enabled -s option on receiving side stransmit and see printing stats and the bit rate is around mbps. |
|
@kmudide Please collect CSV stats with |
|
Please also bear in mind buffer size and maxbw configuration. Default receiver buffer size is Default maxbw is 30 Mbps, refer to #552. |
|
No activity. Closing. |
I have checked out master branch and started testing while simulating our network conditions with tc and metem.
Test results
Observed video smear couple of times in 10 minutes video
Test Scenario
Both PC-1 and PC-2 are connected over a Ethernet connection
sudo tc qdisc add dev eth1 root netem delay 90ms
sudo tc qdisc show dev eth1
qdisc netem 8001: root refcnt 2 limit 1000 delay 90.0ms
PC-1 (Ubuntu):
./stransmit -t:0 -s:1000 udp://:11111 srt://10.1.50.7:22222?mode=rendezvous&latency=400
On this same PC, vlc is streaming big_buck_bunny_720p_h264.mov to localhost:11111
PC-2 (Centos):
./stransmit -t:0 -s:1000 srt://10.1.50.240:22222?latency=400&mode=rendezvous udp://:2002
On this same PC gstreamer is listening at localhost:2002 and sending to TV through video OUT.
Stats:
======= SRT STATS: sid=268422821
PACKETS SENT: 0 RECEIVED: 479188
LOST PKT SENT: 0 RECEIVED: 0
REXMIT SENT: 0 RECEIVED: 3775
RATE SENDING: 0 RECEIVING: 1.89605
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW: FLOW: 8192 CONGESTION: 8192 FLIGHT: 0
RTT: 90.259ms BANDWIDTH: 2814.82Mb/s
BUFFERLEFT: SND: 12288000 RCV: 12003000
======= SRT STATS: sid=268422821
PACKETS SENT: 0 RECEIVED: 480047
LOST PKT SENT: 0 RECEIVED: 0
REXMIT SENT: 0 RECEIVED: 3776
RATE SENDING: 0 RECEIVING: 1.89702
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW: FLOW: 8192 CONGESTION: 8192 FLIGHT: 0
RTT: 90.252ms BANDWIDTH: 3167.52Mb/s
BUFFERLEFT: SND: 12288000 RCV: 12214500
======= SRT STATS: sid=268422821
PACKETS SENT: 0 RECEIVED: 481013
LOST PKT SENT: 0 RECEIVED: 0
REXMIT SENT: 0 RECEIVED: 3778
RATE SENDING: 0 RECEIVING: 1.89554
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW: FLOW: 8192 CONGESTION: 8192 FLIGHT: 0
RTT: 90.231ms BANDWIDTH: 1544.24Mb/s
BUFFERLEFT: SND: 12288000 RCV: 12265500
The text was updated successfully, but these errors were encountered: