All 35 comments
When you can see this, it means that the sender buffer is nearly overflown - your application sends the data faster than the network can push through.
The value of the flight window may contain some packets that are outside the "real flight window" (ACK cumulation): packets that are already received, but the ACK did not confirm them yet. ACK is time-based, so with higher bitrates it will embrace more packets at once, but according to my observations it can stretch to about 30 packets in the file transfer mode, which usually uses the maximum possible bandwidth (unlike live mode). In a very low bitrate in live mode I saw it even sent once per 4 packets. So this "factor" seems to be insignificant - although it can be also measured in the logs.
ethouris
on 4 Oct 2018
Yes, I am trying higher bitrate videos. I increased both sender and receiver buffer sizes to 20480, I think that fixed it.
I am using version 1.2.0 because latest version(1.3.0 or higher) gives me bitrate of 27/28Mbps at output if I use 40/50 Mbps video. I am unable to get the latest version working even with maxbw set to 0 or the one I'm using(say 40Mbps). Any idea where it is limiting the bandwidth?
Thanks.
prabh13singh
on 5 Oct 2018
It's not the problem of a too mall buffer, it's the problem of a too slow network. The buffer is keeping the data only temporarily. The speed of flushing the buffer must on average equalize with the speed of filling the buffer; if the latter is constantly on average higher, the transmission with this bitrate is simply not possible.
ethouris
on 5 Oct 2018
Hi @ethouris
I was hitting these conditions and losing some packets, any idea to overcome them?
_(m_iSndBufSize - m_pSndBuffer->getCurrBufSize()) * m_iPayloadSize < len_
and
_timespan > msecThreshold_
I have tried to increase the latency, but that didn't work.
prabh13singh
on 22 Oct 2018
Hi, we´re facing the same issue when we moved to v1.3... (Latest version(1.3.0 or higher) gives me bitrate of 27/28Mbps at output if I use 40/50 Mbps video). We also had modified the buffers in v1.2 to allow us to send hig bitrate TS but it is not working on v1.3...did you managed to get something higher than 30Mbs working on v1.3?
rmsoto
on 23 Oct 2018
Well, I heard this problem many times; actually nothing has fundamentally changed in the processing in 1.3.0, just the handshake, and there are also some additional virtual calls for the sake of congestion control (although most of them just replaced the entries that were virtual calls in UDT as well).
There were some suspicion on the logging system, some people reported better performance when the logging was off completely (use --disable-logging in configure). Please try to test with this, an input on that would be very enlightening.
ethouris
on 23 Oct 2018
Ok, we will try that...I also read some interesting things on page 29 and 30 of a draft document posted in other issue...I´ll tell you something when we test both things.
rmsoto
on 23 Oct 2018
@rmsoto Please let me know if it works and what specification of video did you use?
prabh13singh
on 23 Oct 2018
@prabh13singh @ethouris, I tested some things that doesn´t work at all in v1.3 which works perfectly in v1.2:
--disable-logginggave us less than 1Mb of better output traffic in v1.3- Setting maxbw and inputbw to 0 or to the expected bitrate doesn´t work neither
- Changing the values of m_iFlightFlagSize, m_iSndBufSize and m_iRcvBufSize to higher values in order to allow more bandwidth into an srt session from srtcore/core.cpp does not work as expected.
In this case we´re trying to send an MPTS MPEG-TS of 90Mbps but we can only receive about 80Mbs with v1.3, using 1.2 works fine...
Regards,
rmsoto
on 23 Oct 2018
I haven't tried increasing buffer sizes on v1.3. I'm now only working with v1.2. I increased size of both sender and receiver buffers to almost 40k and m_iFlightFlagSize to 50k. . I was losing packets when I was using two instances of 60Mbps video on same machine.
Then, we changed SRT_TLPKTDROP_MINTHRESHOLD to 2000 instead of 1000. It's working fine now. Btw, what values of buffers are you using & are you increasing/decreasing the values with increase /decrease in bit-rate ?
prabh13singh
on 23 Oct 2018
@prabh13singh where is SRT_TLPKTDROP_MINTHRESHOLD ??
My FIXED values are:
m_iFlightFlagSize = 65536;
m_iSndBufSize = 65000;
m_iRcvBufSize = 65000;
(this allowed me to do a "TS TimeDelay" of 10sec in a HEVC 4k 90Mbs TS)
Also setting the maxbw parameter to something above the TS+overhead let us send more than 30Mbs into a SRT session...normally we set that to 100Mbs
rmsoto
on 23 Oct 2018
SRT_TLPKTDROP_MINTHRESHOLD is the minimum value used by TLPKTDROP to drop late packets. Increasing it would give the application some more time to retain the packets.
Also setting the maxbw parameter to something above the TS+overhead let us send more than 30Mbs into a SRT session...normally we set that to 100Mbs
So, what you mean here is not using auto internal input rate calculation and manually setting maxbw, right?
prabh13singh
on 23 Oct 2018
yess, this avoids the 30mbs output limit per session...or I guess so :-/
rmsoto
on 23 Oct 2018
Thank you very much @rmsoto. I'll try that too. What's the maximum bit-rate that you've used so far?
prabh13singh
on 23 Oct 2018
100Mbs @prabh13singh I only found that TLPKTDROP can be set like a boolean, true or false...where I can change the SRT_TLPKTDROP_MINTHRESHOLD value?
rmsoto
on 23 Oct 2018
In core.cpp, search for _#define SRT_TLPKTDROP_MINTHRESHOLD_,
in _int CUDT::sendmsg(const char* data, int len, int msttl, bool inorder, uint64_t srctime)_ function in v1.2
prabh13singh
on 23 Oct 2018
One more thing came to my mind that you can help me with testing, until I prepare some test that reproduces it by myself.
If you are using stransmit application for testing in 1.2.0, note that the successor of this application in 1.3.0 version is srt-test-live (you need to --enable-testing to make it compile), whereas srt-live-transmit is almost completely rewritten user application. The difference is that the new one uses asynchronous reading. I have some suspicions about that the epoll system and the overall functioning of the non-blocking mode. Might be that I'm completely wrong, but if you can help me with this, at least there will be a large FA to rule out.
ethouris
on 23 Oct 2018
Thanks, tomorrow I will test those things.
[Overon]
RAÚL MANSILLA
Innovation | R&D
[skype]
El 23 oct 2018, a las 18:33, Sektor van Skijlen <[email protected]notifications@github.com> escribió:
One more thing came to my mind that you can help me with testing, until I prepare some test that reproduces it by myself.
If you are using stransmit application for testing in 1.2.0, note that the successor of this application in 1.3.0 version is srt-test-live (you need to --enable-testing to make it compile), whereas srt-live-transmit is almost completely rewritten user application. The difference is that the new one uses asynchronous reading. I have some suspicions about that the epoll system and the overall functioning of the non-blocking mode. Might be that I'm completely wrong, but if you can help me with this, at least there will be a large FA to rule out.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Haivision/srt/issues/477#issuecomment-432320660, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AghWHoZudAr8c3bD0U5dOFpt5xF79mMpks5un0TUgaJpZM4XERZZ.
rmsoto
on 23 Oct 2018
Hello @ethouris I´ve tried to compile after ./configure --enable-testing and I get this:
Linking CXX executable srt-test-live
CMakeFiles/srt-test-live.dir/testing/testmedia.cpp.o: In functionSrtCommon::Init(std::string, int, std::map
testmedia.cpp:(.text+0x3e7a): undefined reference to KmStateStr(SRT_KM_STATE)'
testmedia.cpp:(.text+0x3e8b): undefined reference toKmStateStr(SRT_KM_STATE)'
testmedia.cpp:(.text+0x3e9c): undefined reference to KmStateStr(SRT_KM_STATE)'
collect2: error: ld returned 1 exit status
CMakeFiles/srt-test-live.dir/build.make:213: recipe for target 'srt-test-live' failed
make[2]: *** [srt-test-live] Error 1
CMakeFiles/Makefile2:238: recipe for target 'CMakeFiles/srt-test-live.dir/all' failed
make[1]: *** [CMakeFiles/srt-test-live.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Linking CXX executable srt-test-relay
CMakeFiles/srt-test-relay.dir/testing/testmedia.cpp.o: In functionSrtCommon::Init(std::string, int, std::map
testmedia.cpp:(.text+0x3f22): undefined reference to KmStateStr(SRT_KM_STATE)'
testmedia.cpp:(.text+0x3f33): undefined reference toKmStateStr(SRT_KM_STATE)'
testmedia.cpp:(.text+0x3f44): undefined reference to KmStateStr(SRT_KM_STATE)'
collect2: error: ld returned 1 exit status
CMakeFiles/srt-test-relay.dir/build.make:213: recipe for target 'srt-test-relay' failed
make[2]: *** [srt-test-relay] Error 1
CMakeFiles/Makefile2:273: recipe for target 'CMakeFiles/srt-test-relay.dir/all' failed
make[1]: *** [CMakeFiles/srt-test-relay.dir/all] Error 2
Linking CXX executable srt-test-file
CMakeFiles/srt-test-file.dir/testing/testmedia.cpp.o: In functionSrtCommon::Init(std::string, int, std::map
testmedia.cpp:(.text+0x3e7a): undefined reference to KmStateStr(SRT_KM_STATE)'
testmedia.cpp:(.text+0x3e8b): undefined reference toKmStateStr(SRT_KM_STATE)'
testmedia.cpp:(.text+0x3e9c): undefined reference to KmStateStr(SRT_KM_STATE)'
collect2: error: ld returned 1 exit status
CMakeFiles/srt-test-file.dir/build.make:213: recipe for target 'srt-test-file' failed
make[2]: *** [srt-test-file] Error 1
CMakeFiles/Makefile2:203: recipe for target 'CMakeFiles/srt-test-file.dir/all' failed
make[1]: *** [CMakeFiles/srt-test-file.dir/all] Error 2
Makefile:117: recipe for target 'all' failed
make: *** [all] Error 2
rmsoto
on 24 Oct 2018
Ah, sorry, I overlooked that. Looxlike --enable-testing can't be combined with --disable-logging. This KmStateStr function is disabled together with logging, but this testing app is using it to display the encryption state after connection.
You can either re-enable logging, or if you want to combine these two, just remove the log that displays it: in testing/testmedia.cpp file find std::string KmStateStr(SRT_KM_STATE state), block this and the following Verb() instruction that uses it.
I the meantime, I'll file myself a bug :)
ethouris
on 24 Oct 2018
Hi there!
With srt-test-live is worse than using srt-live-transmit... :-(
[Overon]
RAÚL MANSILLA
Innovation | R&D
[skype]
El 24 oct 2018, a las 13:12, Sektor van Skijlen <[email protected]notifications@github.com> escribió:
Ah, sorry, I overlooked that. Looxlike --enable-testing can't be combined with --disable-logging. This KmStateStr function is disabled together with logging, but this testing app is using it to display the encryption state after connection.
You can either re-enable logging, or if you want to combine these two, just remove the log that displays it: in testing/testmedia.cpp file find std::string KmStateStr(SRT_KM_STATE state), block this and the following Verb() instruction that uses it.
I the meantime, I'll file myself a bug :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Haivision/srt/issues/477#issuecomment-432614266, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AghWHq6TA6gQVCZ3hsw1YOC820TNdjLTks5uoEsDgaJpZM4XERZZ.
rmsoto
on 24 Oct 2018
Ok, at least I know more so that I will be attempting to reproduce it by myself.
ethouris
on 24 Oct 2018
_17:31:45.315924/stransmit D: SRT.c: cong, NOW: 1540503105315922, BYTES 889428, TMSPAN 118_
It occurs when timespan > (m_SndTsbPdDelay/2) or (timespan_ms > (m_iPeerTsbPdDelay_ms/2)) in v1.3
What is timespan?
prabh13singh
on 25 Oct 2018
Just a small update on this: we will be researching this problem and trying to reproduce it in out environment.
ethouris
on 13 Nov 2018
Thank you
prabh13singh
on 13 Nov 2018
I was checking the inter-packet interval (m_ullInterval) on both sides. Server side shows 8 but the client side shows 108. Shouldn't they be same?
prabh13singh
on 13 Nov 2018
@prabh13singh m_ullInterval is a datasend-only parameter. Even if both side were sending data, this value will rarely be the same.
jeandube
on 13 Nov 2018
Is there any way to check if the srt receiver is sending output stream at the rate equal to the rate at which it srt_sender is receiving input stream?
prabh13singh
on 13 Nov 2018
What SRT tries to do is to replicate at the receiver output the packets pattern presented at the sender input. There is no way inside SRT to prove it. One would have to write an application with specially crafted packets.
jeandube
on 13 Nov 2018
The mechanism inside SRT is making sure that the application is given green light to extract the packet at the time that represents the time when it was scheduled for sending by the sender. "Represents" means that there is some time shift made, however the relative time between two the same consecutive packets should be "replayed" on the receiver as they were at the sender.
Whether the application deals with the packet exactly at the moment when it's given this green light, or later, is another matter. And the trouble is that if the application delays the packet extraction at one packet, then it will have less time to wait for the next one, and if this waiting time decreases below 0, then the cumulated latency at particular packet will cause that the next packet will be also late extracted.
ethouris
on 30 Nov 2018
Ok, as you had some performance problem as I remember, I have an experimental version that should make it better. I detected some performance problem, such that although there's some ::select call before ::recvmsg, it's only for 10ms, still many iterations simply run for nothing. I've made this loop trying to get the nearest time when it is expected to handle any update, and ::select now sleeps until maximum this time, or until a packet is received. I have made a trial test with that and as the current version makes about 5-6 iterations per one received packet (most of them being just useless runaround), this version makes roughly 1 iteration per one received packet. If you can help me and try out how this version works for you (we had some problems with getting any certain results for performance degradation in 1.3.1 and reproduce it reliably, and on the other hand you were not the only one to report this problem).
This is now on my repository replica: https://github.com/ethouris/srt/tree/dev-rcvworker-sleeps
ethouris
on 7 Dec 2018
Im going to test it...let´s see what happen. Thanks @ethouris
rmsoto
on 13 Dec 2018
Hello again!!
I´m still not able to transmit more than 83-84Mbps in one session. I tested with v1.2.0, v1.3.1 and v1.3.2...
@ethouris did you finally find out anything relevant?
Regards,
rmsoto
on 9 May 2019
Nothing so far. The above mentioned branch also contained things that made things better only in case of low bitrate, for high bitrates you simply have very little probability that a call to ::recvmsg will return nothing and you'll have an empty run of a loop.
To block the drops on the sender, you can use snddropdelay option, if you set it to -1, this mechanism is turned off (this may potentially retransmit packets uselessly, wasting this way the link capacity).
ethouris
on 10 May 2019
Hello, thanks for the tip but no way, I can't get more than 83Mbps into one SRT session. Neither with your tips nor @maxlovic ones :-/
rmsoto
on 10 May 2019
Related issues
amukhsimov
·
3Comments
chenjinli
·
6Comments
Svyatk0
·
6Comments
DigitalTVDev
·
4Comments
DmytroIatskyi
·
10Comments