haivision / srt Goto Github PK

Just released Wowza 4.7.2 has support for SRT.

https://www.wowza.com/docs/how-to-create-and-use-stream-files-in-wowza-streaming-engine-manager
https://www.wowza.com/docs/how-to-specify-per-stream-settings-in-stream-files#srtstreams

Has anyone had any success pushing to it from stransmit? I have not. If you have, can you share the commands used?

There happens to be a situation when the sending buffer is not yet completely purged (still some buffers wait for sending), but the closing process simply exits before this can be fully done.

The closing function should be aware of blocking mode on sending and make sure that the sending buffer is empty before it allows the function to return.

When running with master or v1.2, stransmit reports 'bind: no error' if specifying a multicast source for a UDP input.

For example:

./stransmit -r:1000 udp://@239.186.31.73:1234 -c:1328 srt://10.186.4.41:9000

My test server does have multiple NICs installed, and I have attempted to 'steer' the choice of multicast adapter with such a URL (trying both target adapter inside host in URL, and adapter of 'source' of multicast):

./stransmit -r:1000 udp://[email protected]:1236 srt://10.186.6.104:9000

However, I have no luck.

As a receiver, I can confirm that stransmit will output to multicast (although I'm not having a lot of luck passing arguments to bind the output to a chosen adapter...)

Hi all!

I'm completely new to SRT and have an issue.
I have MPEG2 TS over IP streamer which outputs udp://239.10.10.3:1234 stream. It is in the same network with SRT server (PC). I try to make an SRT stream and send it to remote SRT receiver (PC) and make udp://239.10.10.3:1234 again but no luck. The server connects to listener but can't start the transmission. Command line:
Server: ./stransmit -v udp://239.10.10.3:1234 srt://10.85.10.27:5000
Listener: ./stransmit -v srt://:5000 udp://239.10.10.3:1234
I tried for the listener: ./stransmit -v srt://:5000?adapter=10.85.10.27 udp://239.10.10.3:1234 - no difference

What are the right SRT settings for my case?

Thank you in advance!

Dear,

Im telling you that Im building an html with php to be able to control the ./stransmit sender and receiver.
What I can not do is get the logs that the ./stransmit delivers and display them in the html or php.
Would you have any ideas that could help me?

Greetings and thanks
Martin

Little questions:
ms -t:<timeout=0> - connection timeout
bites -c:<chunk=1316> - max size of data read in one step
bits -b: - set SRT bandwidth
per sec -r:<report-frequency=0> - bandwidth report frequency
per sec -s:<stats-report-freq=0> - frequency of status report
Am I right?

Because when I set timeout -t:60
./stransmit -v -t:60 udp://@239.10.10.3:1234?adapter=10.10.70.50 srt://10.85.10.22:5000?latency=8000
I don't see that stransmit wait for 60 sec before exit, timeout is about only a few seconds

We are getting more and more SRT fans :)

We have seen that Haivision demonstrate video that stayed in sync:
http://www.haivision.com/products/secure-reliable-transport

This is amazing and i´m thinking how you did this Haivision. I have an Live HEVC Encoder SoC which is able to generate a h.264 and HEVC at the same bitrate/resolution/fps etc.. Cause the timing of the encoding (preset vs. motion estimation) are different in timestamps, but not too far to each other, max. maybe 80-120ms.

I can get set both streams in MpegTS via UDP to grab them both.

How can SRT help me to sync both streams? I do not find any information about syncing in SRT or i oversee it yet.

When you think that you can mix SRT audio an video channels with an big "sync" buffer, then the possibilities for IPTV are endless.

Anyone?

The application using SRT should rely on information found in the srt.pc file.

The problem is that the API is suited for C language (to make it most possibly universal), and an a build system for the C application would have to be somehow instructed that it should link against libstdc++/libc++.

I did it by adding -lstdc++ in Libs: section - but this has caused another problem: a C++ application must find this option and take it out, at least when it's going to link the application against libstdc++ statically.

Something sensible is required so that the same PC file can be used for C applications using SRT and C++ applications using SRT and linking against libstdc++ statically. Might be that some extra steps are required in particular case, such as reading from a custom variable from a pc file.

hello,
I've used a while ago sample-apps from UDT for file transfer and I was quite astonished about performance in comparison to SCP/FTP on high-latency networks.

So I thought that I might could use stransmit-process for file delivery too, but connection drops.

Sender
./stransmit file:///Users/test/source.file srt://40.74.114.99:4000?mode=caller

Receiver
./stransmit srt://:4000/?mode=listener file:///home/test/destination.file

Issue/question
I see that connection breaks without any reason, should given setup work for file-transmission?

There's a need for an application that would do multiple simultaneous transfers, but it would be seen from the firewall/route perspective as using exactly one link.

The recognition of which transfer is which when making a connection can be done by using the streamid feature.

Title is self explanitory. I would like to be able to view report output while still output to file://con

Not in every case of platform/system combination is it possible to rely on that the OpenSSL.cmake file will function correctly. Moreover, it was already requested that haicrypt work with also different providers for an SSL library.

Is that possible that when find_package(OpenSSL) somehow fails, the system tries to apply for OpenSSL by trying out the pkg-config file directly (pkg_search_module)?

I've been setting up a test environment, with the focus on Windows compilation, and I have seen a few problems. With the master branch, I would get access violations on the receiver after some time (normally correlated to UDP packet loss). I have seen this with compilations of stransmit, and within my own test implementation of a receiver.

I decided to test with 'dev' branch, but I cannot (with same input arguments) get any data to flow. My test receiver seems to never step past srt_accept call when sending from stransmit.

Since I'm always unsure that the problem might not be my side, I have forked the repo and then connected up 'artefacts' from the build using the appveyor.yml file included (which I hope would rule out my local building issues, if they existed).

However, I still cannot get stransmit to work from 'dev' branch.

You can see builds here:

https://ci.appveyor.com/project/cinegy/srt/history

And fork here:

https://github.com/Cinegy/srt

Before diving in to try and work out what goes wrong - is this a known issue on Windows?

Hi,
to obey LGPL we need to build libs dynamically. I'm not sure I did it right but at least it works.
run configure as following:

./configure --ENABLE_DYNAMIC:BOOL=1

It makes much easier to integrate with libraries in a clean way.

Testing with tag 1.2.0 built (with the VS2013 compiled edition), and 'master' (with VS2015) I get an access violation on my Win10 laptop (with SRT used over WiFi to make it work harder) used to receive a 2.5mbps UDP MPEGTS stream.

I have seen similar exceptions on my Win10 desktop (just much less frequently, since there is very little packet loss between source and target).

I tried to catch this issue running debug 'live' against master in VS2015 - but the access violation is outside of the SRT code and somewhere without source (I'm not great at tracing such problems - more of a C# kinda guy really).

To rule out stransmit, I created a managed C++ wrapper around SRT DLL, and exposed this to a C# console tool (which then acted as the multicast re-emitter for the wrapped UDP). This also shows a similar problem, with an access violation happening deep outside my wrapper code and client.

I have tried to test with dev, but as reported in a different issue, the SDK and stransmit just hang when trying to connect (so cannot tell if it might reproduce).

I'm going to try and go back to v1.2 and stabilise my wrapper before trying any harder researching this problem - but I wanted to raise the issue to see if anyone else has witnessed any such issue

I installed cmake and openssl with brew, and got this build failure. I upgraded everything with brew, still got it.

Mac version is 10.12.4 (16E195)

I do not have XCode installed, only the command line tools (installed with xcode-select --install, so maybe that has something to do with it.

Brew info for cmake and openssl

hobbes:srt cdunklau$ brew list cmake openssl
/usr/local/Cellar/cmake/3.8.0/bin/ccmake
/usr/local/Cellar/cmake/3.8.0/bin/cmake
/usr/local/Cellar/cmake/3.8.0/bin/cmakexbuild
/usr/local/Cellar/cmake/3.8.0/bin/cpack
/usr/local/Cellar/cmake/3.8.0/bin/ctest
/usr/local/Cellar/cmake/3.8.0/share/aclocal/cmake.m4
/usr/local/Cellar/cmake/3.8.0/share/cmake/ (2170 files)
/usr/local/Cellar/cmake/3.8.0/share/doc/ (8 files)
/usr/local/Cellar/cmake/3.8.0/share/emacs/site-lisp/cmake/cmake-mode.el
/usr/local/Cellar/cmake/3.8.0/share/man/ (19 files)
/usr/local/Cellar/openssl/1.0.2k/bin/c_rehash
/usr/local/Cellar/openssl/1.0.2k/bin/openssl
/usr/local/Cellar/openssl/1.0.2k/include/openssl/ (75 files)
/usr/local/Cellar/openssl/1.0.2k/lib/libcrypto.1.0.0.dylib
/usr/local/Cellar/openssl/1.0.2k/lib/libssl.1.0.0.dylib
/usr/local/Cellar/openssl/1.0.2k/lib/engines/ (12 files)
/usr/local/Cellar/openssl/1.0.2k/lib/pkgconfig/ (3 files)
/usr/local/Cellar/openssl/1.0.2k/lib/ (4 other files)
/usr/local/Cellar/openssl/1.0.2k/share/man/ (1592 files)

OpenSSL that brew installed is linked right

hobbes:~ cdunklau$ ls -ld /usr/local/opt/openssl
lrwxr-xr-x  1 cdunklau  admin  24 Feb  5 17:32 /usr/local/opt/openssl -> ../Cellar/openssl/1.0.2k

Configure and make output:

hobbes:srt cdunklau$ ./configure 
Running: cmake . -DWITH_OPENSSL_INCLUDEDIR=/usr/local/opt/openssl/include -DWITH_OPENSSL_LDFLAGS=/usr/local/opt/openssl/lib/libcrypto.a
-- The C compiler identification is AppleClang 8.1.0.8020038
-- The CXX compiler identification is AppleClang 8.1.0.8020038
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /usr/local/bin/pkg-config (found version "0.29.2") 
COMPILER: GNU compat: /Library/Developer/CommandLineTools/usr/bin/c++
VERSION: major=1 minor=2 patch=0
Using RELEASE mode
DARWIN detected
C++ VERSION: Setting C++11 compat flag for gnu compiler
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/cdunklau/Development/srt
hobbes:srt cdunklau$ make
Scanning dependencies of target haicrypt
[  2%] Building C object CMakeFiles/haicrypt.dir/haicrypt/hc_openssl_aes.c.o
[  5%] Building C object CMakeFiles/haicrypt.dir/haicrypt/hc_openssl_evp_cbc.c.o
[  8%] Building C object CMakeFiles/haicrypt.dir/haicrypt/hc_openssl_evp_ctr.c.o
[ 11%] Building C object CMakeFiles/haicrypt.dir/haicrypt/hcrypt.c.o
[ 14%] Building C object CMakeFiles/haicrypt.dir/haicrypt/hcrypt_ctx_rx.c.o
[ 17%] Building C object CMakeFiles/haicrypt.dir/haicrypt/hcrypt_ctx_tx.c.o
[ 20%] Building C object CMakeFiles/haicrypt.dir/haicrypt/hcrypt_rx.c.o
[ 22%] Building C object CMakeFiles/haicrypt.dir/haicrypt/hcrypt_sa.c.o
[ 25%] Building C object CMakeFiles/haicrypt.dir/haicrypt/hcrypt_tx.c.o
[ 28%] Building C object CMakeFiles/haicrypt.dir/haicrypt/hcrypt_ut.c.o
[ 31%] Building C object CMakeFiles/haicrypt.dir/haicrypt/hcrypt_xpt_srt.c.o
[ 34%] Building C object CMakeFiles/haicrypt.dir/haicrypt/hcrypt_xpt_sta.c.o
[ 37%] Linking C static library libhaicrypt.a
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libhaicrypt.a(hc_openssl_evp_cbc.c.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libhaicrypt.a(hc_openssl_evp_cbc.c.o) has no symbols
[ 37%] Built target haicrypt
Scanning dependencies of target haisrt
[ 40%] Building CXX object CMakeFiles/haisrt.dir/srtcore/api.cpp.o
/Users/cdunklau/Development/srt/srtcore/api.cpp:2638:20: warning: unused function 'set_result'
      [-Wunused-function]
static inline void set_result(set<UDTSOCKET>* val, int* num, UDTSOCKET* fds, set<UDTSOCKET>::co...
                   ^
1 warning generated.
[ 42%] Building CXX object CMakeFiles/haisrt.dir/srtcore/buffer.cpp.o
In file included from /Users/cdunklau/Development/srt/srtcore/buffer.cpp:65:
In file included from /Users/cdunklau/Development/srt/srtcore/buffer.h:68:
In file included from /Users/cdunklau/Development/srt/srtcore/list.h:68:
In file included from /Users/cdunklau/Development/srt/srtcore/common.h:77:
/Users/cdunklau/Development/srt/srtcore/utilities.h:582:17: warning: absolute value function 'abs'
      given an argument of type 'int64_t' (aka 'long long') but has parameter of type 'int' which may
      cause truncation of value [-Wabsolute-value]
            if (abs(m_qDrift) > MAX_DRIFT)
                ^
/Users/cdunklau/Development/srt/srtcore/buffer.cpp:1454:34: note: in instantiation of member function
      'DriftTracer<1000, 5000, true>::update' requested here
    bool updated = m_DriftTracer.update(iDrift);
                                 ^
/Users/cdunklau/Development/srt/srtcore/utilities.h:582:17: note: use function 'std::abs' instead
            if (abs(m_qDrift) > MAX_DRIFT)
                ^~~
                std::abs
1 warning generated.
[ 45%] Building CXX object CMakeFiles/haisrt.dir/srtcore/cache.cpp.o
[ 48%] Building CXX object CMakeFiles/haisrt.dir/srtcore/ccc.cpp.o
[ 51%] Building CXX object CMakeFiles/haisrt.dir/srtcore/channel.cpp.o
In file included from /Users/cdunklau/Development/srt/srtcore/channel.cpp:85:
/Users/cdunklau/Development/srt/include/srt_compat.h:88:8: warning: comparison of function
      'clock_gettime' not equal to a null pointer is always true [-Wtautological-pointer-compare]
   if (clock_gettime != NULL)
       ^~~~~~~~~~~~~    ~~~~
/Users/cdunklau/Development/srt/include/srt_compat.h:88:8: note: prefix with the address-of operator to
      silence this warning
   if (clock_gettime != NULL)
       ^
       &
/Users/cdunklau/Development/srt/include/srt_compat.h:101:8: warning: comparison of function
      'clock_getres' not equal to a null pointer is always true [-Wtautological-pointer-compare]
   if (clock_getres != NULL)
       ^~~~~~~~~~~~    ~~~~
/Users/cdunklau/Development/srt/include/srt_compat.h:101:8: note: prefix with the address-of operator
      to silence this warning
   if (clock_getres != NULL)
       ^
       &
/Users/cdunklau/Development/srt/include/srt_compat.h:129:17: error: cannot initialize a variable of
      type 'const char *' with an rvalue of type 'void *'
    const char* pos = memchr(s, 0, maxlen);
                ^     ~~~~~~~~~~~~~~~~~~~~
/Users/cdunklau/Development/srt/include/srt_compat.h:134:5: error: "FIXME!!"
   #error "FIXME!!"
    ^
2 warnings and 2 errors generated.
make[2]: *** [CMakeFiles/haisrt.dir/srtcore/channel.cpp.o] Error 1
make[1]: *** [CMakeFiles/haisrt.dir/all] Error 2
make: *** [all] Error 2

hello,

I test following setup:

sender
transmitting udp-stream to relay 40.74.114.99
./stransmit udp://127.0.0.1:10000 srt://40.74.114.99:4000?mode=caller -r:10 -s:10 -t:10

relay
relaying srt-stream port 4000 incoming as listener to srt-stream port 4002 as listener
./stransmit srt://:4000/?mode=listener srt://:4002?mode=listener -r:10 -s:10 -v -t:10

receiver
receiving stream from relay over srt-port 4002
./stransmit srt://40.74.114.99:4002/?mode=client file://con | ffplay -

issue/question
receiver drops connection to relay.
Then relay-stransmit-process exits and so also sender-stransmit-process.
Is this correct behavior?
I would expect, stransmit-relay-processs remains listening/running.

======= SRT STATS: sid=858452265
PACKETS SENT: 0 RECEIVED: 0
LOST PKT SENT: 0 RECEIVED: 0
REXMIT SENT: 0 RECEIVED: 0
RATE SENDING: 0 RECEIVING: 0
BELATED RECEIVED: 58 AVG TIME: 1.844478248e+16
REORDER DISTANCE: 0
WINDOW: FLOW: 8192 CONGESTION: 8192 FLIGHT: 0
RTT: 255.174ms BANDWIDTH: 0.011648Mb/s
BUFFERLEFT: SND: 12288000 RCV: 11884500
<< 1128 -> sent
+++/+++SRT TRANSFER: 6776084B DURATION: 20512ms SPEED: 322.609kB/s
<< 564 -> sent
<< 376 -> sent
<< 752 -> sent
<< 564 -> sent
<< 564 -> sent
<< 376 -> sent
<< 376 -> sent
<< 376 -> FAILURE
srt_sendmsg: [2001] Connection was broken.
SrtCommon: DESTROYING CONNECTION, closing sockets
SrtCommon: DESTROYING CONNECTION, closing sockets

Code missing or soft link invalid?

Howdy,

I'm trying to run some simple tests using the SRT C API, and started by trying out the testcapi.c app. I managed to get it to build, but I couldn't find an example of creating an actual server.

Here's my simple PR to add a test c api based server: #21

As per Pull Request #67, the AppVeyor check fails and it reports very strange errors concerning libSSL.

This wasn't seen before, as well as this looks like if we have a build-breaking version now as latest master!

Hi EveryOne,
I am trying to explore and see how we can use the SRT to overcome the Packet Loss Issue(Local Wireless Network) with little introduction of Latency & Buffering into the overall System.

I started off by using the Stransmit APP as described below over Wired LAN:
PC1 (VLC first instance: UDP out :9000) : Streaming MP4
|
SERVER1 (stransmit: UDP :9000, SRT server mode out :1234)
./stransmit -v udp://srv1_ip:9000 srt://srv1_ip:1234/?mode=server
|
SERVER2 (PC2 stransmit: SRT client mode in :1234, UDP out :9001)
./stransmit -v srt://srv1_ip:1234/?mode=client udp://pc1_ip:9001
|
PC2 (VLC second instance: UDP in :9001)

Using the above setup I can see some data is getting transmitted from PC1->PC2, But the video performance is not up-to the mark, even over the Wired Ethernet Connection.
I could barely play 480@30FPS Video but 1080P@60 is too bad and it pauses a lot and buffer a lot in between.

So this made me into thinking...

1. Is Stransmit is a correct way to test Video Streaming over SRT?
2. Is there any parameters that I need to provide other than what specified above?
3. Is this could be issue with VLC app which is dropping lots of late Frame?

I believe that I am missing some key information here. Can someone provide me the correct direction?
Regards,
Gurtaj

Are there any efforts made/experiments done to see if the SRT protocol could be compiled for the Axis ip-camera ACAP platform? Or are there any foreseeable incompatibilities which would prevent such a 3rd party application?

I have run server by command:
/srt-master/stransmit -v udp://:5555 'srt://0.0.0.0:9000?mode=server&latency=500'

and client by command:
/srt-master/stransmit 'srt://xxx.xxx.xxx.xxx:9000/?mode=client&latency=2000' udp://127.0.0.1:5000 -s:100 -r:100 -t:60

And see stats report with 0 values for packages:

======= SRT STATS: sid=831244345
PACKETS SENT: 0 RECEIVED: 0
LOST PKT SENT: 0 RECEIVED: 0
REXMIT SENT: 0 RECEIVED: 0
RATE SENDING: 0 RECEIVING: 0
BELATED RECEIVED: 1230 AVG TIME: 1.844674407e+16
REORDER DISTANCE: 0
WINDOW: FLOW: 8192 CONGESTION: 8192 FLIGHT: 0
RTT: 173.01ms  BANDWIDTH: 0.011648Mb/s
BUFFERLEFT: SND: 12288000 RCV: 11914500
+++/+++SRT TRANSFER: 13063141084B DURATION: 75666814ms SPEED: 168.608kB/s

I have build srt from master branch source
What should I do additional that stransmit calculate collect more statistic?

Thanks at advance.

Hi, thanks a lot to open source this work, it is very interestig option for people who work in the live streaming maket.
But I compiled this code in a Docker (Ubuntu 16 first, and Ubuntu 14 after) and I could NOT make it work (corrupted output).
Thinking that the problem could have been the docker I compiled again in a VM Cent OS 6 (VMWare), and the following test resulted in the same corrupted output that I saw in my docker experiment.

CentOS test:

SOURCE (terminal1):

ffmpeg -f lavfi -re -i smptebars=duration=60:size=1280x720:rate=30 -f lavfi -re -i sine=frequency=1000:duration=60:sample_rate=44100 -pix_fmt yuv420p -c:v libx264 -b:v 1000k -g 30 -keyint_min 120 -profile:v baseline -preset veryfast -c:a libfdk_aac -b:a 96k -f mpegts udp://127.0.0.1:5000

SRT TX (terminal2):

./stransmit -r:10 -s:5 udp://:5000 srt://:9000

SRT RX & play (terminal3):

./stransmit srt://127.0.0.1:9000 file://con | ffplay -

This is a sample of what ffplay claims:

[aac @ 0x7f3d5c006f20] decode_pce: Input buffer exhausted before END element found
[aac @ 0x7f3d5c006f20] channel element 1.6 is not allocated f=0/0   
[aac @ 0x7f3d5c006f20] channel element 2.5 is not allocated
[aac @ 0x7f3d5c006f20] Sample rate index in program config element does not match the sample rate index configured by the container.
[aac @ 0x7f3d5c006f20] decode_pce: Input buffer exhausted before END element found
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatchsq=    0B f=0/0   
[aac @ 0x7f3d5c006f20] Prediction is not allowed in AAC-LC.
[aac @ 0x7f3d5c006f20] channel element 1.6 is not allocated
[aac @ 0x7f3d5c006f20] channel element 2.5 is not allocated
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatchsq=    0B f=0/0   
[aac @ 0x7f3d5c006f20] channel element 3.12 is not allocated
[aac @ 0x7f3d5c006f20] SBR was found before the first channel element.
[aac @ 0x7f3d5c006f20] channel element 2.10 is not allocated
[aac @ 0x7f3d5c006f20] channel element 1.6 is not allocated
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatchsq=    0B f=0/0   
[aac @ 0x7f3d5c006f20] channel element 2.13 is not allocated
[h264 @ 0x7f3d5c16c5e0] left block unavailable for requested intra mode at 0 27
[h264 @ 0x7f3d5c16c5e0] error while decoding MB 0 27
[h264 @ 0x7f3d5c16c5e0] concealing 1489 DC, 1489 AC, 1489 MV errors in I frame
[aac @ 0x7f3d5c006f20] channel element 2.4 is not allocated
[aac @ 0x7f3d5c006f20] channel element 3.4 is not allocated
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatchsq=    0B f=0/0   
[aac @ 0x7f3d5c006f20] skip_data_stream_element: Input buffer exhausted before END element found
[aac @ 0x7f3d5c006f20] If you heard an audible artifact, there may be a bug in the decoder. Clipped noise gain (-172 -> -100) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[aac @ 0x7f3d5c006f20] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/MPlayer/incoming/ and contact the ffmpeg-devel mailing list.
[aac @ 0x7f3d5c006f20] If you heard an audible artifact, there may be a bug in the decoder. Clipped noise gain (-175 -> -100) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[aac @ 0x7f3d5c006f20] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/MPlayer/incoming/ and contact the ffmpeg-devel mailing list.
[aac @ 0x7f3d5c006f20] If you heard an audible artifact, there may be a bug in the decoder. Clipped noise gain (-175 -> -100) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[aac @ 0x7f3d5c006f20] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/MPlayer/incoming/ and contact the ffmpeg-devel mailing list.
[aac @ 0x7f3d5c006f20] If you heard an audible artifact, there may be a bug in the decoder. Clipped noise gain (-177 -> -100) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[aac @ 0x7f3d5c006f20] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/MPlayer/incoming/ and contact the ffmpeg-devel mailing list.
[aac @ 0x7f3d5c006f20] SSR is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[aac @ 0x7f3d5c006f20] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/MPlayer/incoming/ and contact the ffmpeg-devel mailing list.
[aac @ 0x7f3d5c006f20] channel element 2.5 is not allocated
[aac @ 0x7f3d5c006f20] skip_data_stream_element: Input buffer exhausted before END element found
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatchsq=    0B f=0/0   
[aac @ 0x7f3d5c006f20] Sample rate index in program config element does not match the sample rate index configured by the container.
[aac @ 0x7f3d5c006f20] decode_pce: Input buffer exhausted before END element found
[aac @ 0x7f3d5c006f20] channel element 3.4 is not allocated
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatchsq=    0B f=0/0   
[aac @ 0x7f3d5c006f20] Reserved bit set.
[aac @ 0x7f3d5c006f20] channel element 3.4 is not allocated
    Last message repeated 2 times
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatchsq=    0B f=0/0   
[aac @ 0x7f3d5c006f20] Prediction is not allowed in AAC-LC.
[aac @ 0x7f3d5c006f20] channel element 1.6 is not allocated
[aac @ 0x7f3d5c006f20] skip_data_stream_element: Input buffer exhausted before END element found
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatchsq=    0B f=0/0   
[aac @ 0x7f3d5c006f20] skip_data_stream_element: Input buffer exhausted before END element found
[aac @ 0x7f3d5c006f20] channel element 2.4 is not allocated
[h264 @ 0x7f3d5c16c5e0] left block unavailable for requested intra mode at 0 27
[h264 @ 0x7f3d5c16c5e0] error while decoding MB 0 27
[h264 @ 0x7f3d5c16c5e0] concealing 1489 DC, 1489 AC, 1489 MV errors in I frame
[aac @ 0x7f3d5c006f20] channel element 2.13 is not allocatedf=0/0   
    Last message repeated 1 times
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatchsq=    0B f=0/0   
[aac @ 0x7f3d5c006f20] skip_data_stream_element: Input buffer exhausted before END element found
[aac @ 0x7f3d5c006f20] Inconsistent channel configuration.
[aac @ 0x7f3d5c006f20] get_buffer() failed
[aac @ 0x7f3d5c006f20] channel element 3.4 is not allocated
[aac @ 0x7f3d5c006f20] Prediction is not allowed in AAC-LC.
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatchsq=    0B f=0/0   
[aac @ 0x7f3d5c006f20] channel element 3.6 is not allocated
[aac @ 0x7f3d5c006f20] channel element 2.13 is not allocatedf=0/0   
    Last message repeated 1 times
[aac @ 0x7f3d5c006f20] Sample rate index in program config element does not match the sample rate index configured by the container.
[aac @ 0x7f3d5c006f20] decode_pce: Input buffer exhausted before END element found
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatch
[aac @ 0x7f3d5c006f20] decode_pce: Input buffer exhausted before END element found
[aac @ 0x7f3d5c006f20] channel element 2.4 is not allocated f=0/0   
[aac @ 0x7f3d5c006f20] channel element 3.4 is not allocated
[h264 @ 0x7f3d5c1652c0] left block unavailable for requested intra mode at 0 27
[h264 @ 0x7f3d5c1652c0] error while decoding MB 0 27
[h264 @ 0x7f3d5c1652c0] concealing 1489 DC, 1489 AC, 1489 MV errors in I frame
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatchsq=    0B f=0/0   
[aac @ 0x7f3d5c006f20] Sample rate index in program config element does not match the sample rate index configured by the container.
[aac @ 0x7f3d5c006f20] decode_pce: Input buffer exhausted before END element found
[mpegts @ 0x7f3d5c0008c0] PES packet size mismatchsq=    0B f=0/0   
[aac @ 0x7f3d5c006f20] Sample rate index in program config element does not match the sample rate index configured by the container.
[aac @ 0x7f3d5c006f20] decode_pce: Input buffer exhausted before END element found
[aac @ 0x7f3d5c006f20] TYPE_FIL: Input buffer exhausted before END element found
[aac @ 0x7f3d5c006f20] channel element 2.13 is not allocated
[aac @ 0x7f3d5c006f20] Sample rate index in program config element does not match the sample rate index configured by the container.
[aac @ 0x7f3d5c006f20] decode_pce: Input buffer exhausted before END element found

PS : I also tried to save the file and play it later, and I also tried to send it to UDP receiving it in ffmpeg. All experiments same result: Corrupted output

So there's a deadlock issue in SRT. Here's all the info I got on it and how to reproduce.

My configuration: Windows 10 x64. I built SRT from my shared branch ( #35 ) with the only modification being adding a srt_startup call to the first line of main (didn't work otherwise) and commenting out line 3143 of core.cpp because it caused a crash in debug mode. Here's the diff file

Steps to reproduce:

1. Start some sort of thing streaming over UDP. I just used VLC to stream a video
2. Start a stransmit process to send the data from that udp stream over SRT with the -tsbpd flag.
3. Start another stransmit process to receive that data send from the first and send it over a different UDP port also with the -tsbpd flag
4. Startup something to check if that UDP data is being recieved. I used VLC.
5. Startup clumsy and add 5% packet loss and 80ms of lag over the UDP socket SRT is sending/recieving on.

Here's a diagram:

Wait. Eventually the video will stop, and the sender process will close:

You can now attach a debugger to the process and you'll see that it's in deadlock:

One thread is trying to lock m_RecvLock on core.cpp:4595, with this call stack:

That same thread is holding the m_RcvLossLock mutex from core.cpp:4553.

A different thread is trying to lock m_RcvLossLock from core.cpp:4876 with this call stack:

While that same thread is holding the m_RecvLock mutex from core.cpp:1445

They are both waiting on each other.

Also this should be a supported scenario for SRT to run, it's all about handing latency and packet loss, so it's unfortunate that is crashes with any amount of either.

Interestingly enough, it works fine if the latency is set to at least double the lag added in clumsy (the rtt).

Congratulations on the new SRT alliance.

I compiled the source on Ubuntu 16.04 LTS.
And got stransmit to do something:

# stransmit -kv udp://0.0.0.0:9110 udp://localhost:9120
# netstat -na | grep 9110
udp        0      0 0.0.0.0:9110            0.0.0.0:* 

But it does not LISTEN or accept udp or SRT connections
I read stransmit.cpp but I need help with URI Args I think

I want to listen for and accept TS/SRT connections and pipe them to TS/UDP.
In other words, terminate an SRT tunnel on a remote server.

Can you please provide an over view of the functionality and some command line examples.

Thanks for any help

Whenever the bandwidth being sent (the packetized data + potential retransmissions) exceeds the users maximum connection speed, it goes into a bit of a nutty cycle (sending out massive amounts of retransmission requests which further leads to more packet loss) that seems to ignore the MAXBW option set on SRT.

Is there a setting that I'm missing here that would allow me to more gracefully handle issues where the bandwidth in use exceeds the max bandwidth?

An example is a user has a 5mbps connection. If the user ends up sending 7mbps, the retransmissions caused by the dropped packets end up skyrocketing to 20-40mbps out. This further causes more packets to be dropped and eventually all active connections on that machine are dropped. My assumption was that the MAXBW would also apply to retransmissions to prevent it from exhibiting this behavior.

Setting MAXBW and OHEADBW both do not seem to have any affect on this behavior. Everything works extremely well as long as we are below the users maximum bandwidth.

Thanks a lot!

These are the main settings we use on client/server:

bool tsbpd_mode = true;
int tsbpd_delay = 400;
bool tlpktdrop_mode = true;

srt_setsockopt(sock.s.srt, 0, SRTO_TSBPDMODE, &tsbpd_mode, sizeof(bool));
srt_setsockopt(sock.s.srt, 0, SRTO_TSBPDDELAY, &tsbpd_delay, sizeof(int));
srt_setsockopt(sock.s.srt, 0, SRTO_TLPKTDROP, &tlpktdrop_mode, sizeof(bool));

We send everything with srt_sendmsg()

I am running the stransmit application with the following commands for both server and client running on the same box and the transmit seems to be working.
./stransmit udp://239.153.13.16:1234 srt://127.0.0.1:1234/?mode=server
./stransmit srt://127.0.0.1:1234/?mode=client udp://239.235.13.2:1234

however, when I try to run the client and server on different box, the transmit of the data stops working.
./stransmit udp://239.153.13.16:1234 srt://239.212.212.212:1234/?mode=server
./stransmit srt://239.212.212.212:1234/?mode=client udp://239.235.13.2:1234

Can someone please help.

Right now when you launch stransmit it runs for one session, then shuts off.

I'd love to see if there could be a persistent daemon that is a tunnel between a client and a server natively as part of the stransmit technology. Sort of like how stunnel works.

I'd also love if there was a way for it to take in TCP streams, and spit out TCP streams on the other side. For example, RTMP input from an encoder -> srt client -> srt -> srt sever -> RTMP to a server. You could also use it to accelerate HTTP push content.

I know this works, but this is logically wrong.

The logical split of this is that the common stuff, including "compat" or "platform dependent" things is a dependency of both haicrypt and srt, no matter that haicrypt is also a dependency of srt. So, for example, when srt is using gettimeofday() - and its crafted version on Windows - it uses part of the "platform compat" stuff, which has nothing to do with haicrypt.

There are two possible approaches, which don't break the logic of this whole breakdown:

• Keep all libraries compiled to separate files. However this means that the "compat" stuff must be compiled into yet another library, say "srtcompat". This will be then dependency of haicrypt and srt, independently, and it will result in having 3 library files.
• Keep everything in one library file. Actually haicrypt is a kinda private dependency of srt and there's no need for it to be exposed (actually even its public headers are not installable). In this case, all 3 things can be maintained as separate subprojects, but everything can be compiled into one library.

Consider both solutions. Remember though that the latter is simple, simplifies installation and deployment, and, what is most important, gettimeofday() or any other compat stuff doesn't need to be exported at all.

When you set
ASSERT_NE(srt_setsockopt(m_bindsock, 0, SRTO_PBKEYLEN, &aes256, sizeof aes256), SRT_ERROR);
ASSERT_NE(srt_setsockopt(m_bindsock, 0, SRTO_PASSPHRASE, passphrase, strlen(passphrase)), SRT_ERROR);
for bind socket you will receive encrypted chunks for some time but after some time you will start getting normal chunks.
You can easily reproduce this case:

• first start stransmit without passphrase

./stransmit BigBuckBunny.ts "srt://localhost:1234/?mode=server"

and start client to get ts and play it

./stransmit "srt://127.0.0.1:1234/?mode=client" file://con | ffplay -

you will not get any error message from ffplay and video starts playing from beginning.

• if you set passphrase parameter

./stransmit BigBuckBunny.ts "srt://localhost:1234/?mode=server&passphrase=01234567890"

and then start client with ffplay

./stransmit "srt://127.0.0.1:1234/?mode=client&passphrase=01234567890" file://con | ffplay -

you will get a lot of error message from ffmpeg. video starts from ~10 from beginning. if you try to just store ts into file you will find there is no mpegts_start_mark 'G' in first and many others packets on 188 byte boundary. so message corrupted for some time from beginning. After some time messages starts working and recv get decrypted messages.

if you try to interrupt server you will get core dump and following messages in console:

-------- REQUESTED INTERRUPT!
02:47:43.137041/stransmit!!FATAL!!: SRT.c: sendmsg: UNEXPECTED EXCEPTION: St13runtime_error: Requested exception interrupt
^C
-------- REQUESTED INTERRUPT!
terminate called after throwing an instance of 'std::runtime_error'
what(): Requested exception interrupt
Aborted (core dumped)

in my application I see interesting effect

	SRTSOCKET m_bindsock = srt_socket(AF_INET, SOCK_DGRAM, 0);
	ASSERT_NE(m_bindsock, SRT_ERROR);

    ASSERT_NE(srt_setsockopt(m_bindsock, 0, SRTO_RCVSYN, &no, sizeof no), SRT_ERROR); // for async connect
    // set key len and passphrase for server socket so it should be inherited
    int aes256 = 32;
    ASSERT_NE(srt_setsockopt(m_bindsock, 0, SRTO_PBKEYLEN, &aes256, sizeof aes256), SRT_ERROR);
    ASSERT_NE(srt_setsockopt(m_bindsock, 0, SRTO_PASSPHRASE, passphrase, strlen(passphrase)), SRT_ERROR);

    sockaddr_in sa;
    memset(&sa, 0, sizeof sa);
    sa.sin_family = AF_INET;
    sa.sin_port = htons(9999);
	sa.sin_addr.s_addr = INADDR_ANY;
    sockaddr* psa = (sockaddr*)&sa;

    ASSERT_NE(srt_bind(m_bindsock, psa, sizeof sa), SRT_ERROR);
    ASSERT_NE(srt_listen(m_bindsock, SOMAXCONN), SRT_ERROR);

    sockaddr_in scl;
    int sclen = sizeof scl;

	SRTSOCKET m_sock = srt_accept(m_bindsock, (sockaddr*)&scl, &sclen);
	ASSERT_NE(m_sock, SRT_INVALID_SOCK);

    {
        // IMPORTANT COMMENT. PLEASE READ IT
        // if I remove sleep then  getsockopt below will return pbkeylen = 0. with sleep we have
        // proper value. so it looks like property inheritance performed in background and 
        // required some time. but what to do to get first package decrypted ?**
        sleep(5);
        int pbkeylen;
        int pbkeylensize = sizeof pbkeylen;
        ASSERT_NE(srt_getsockopt(m_sock, 0, SRTO_PBKEYLEN, &pbkeylen, &pbkeylensize), SRT_ERROR);
        ASSERT_EQ(pbkeylensize , 4);
        ASSERT_EQ(pbkeylen, 32);
    }

it looks like decryption starts working after some time. and before that time both my app and stransmit get encrypted packages on recv calls. After some time recv start returning decrypted messages.

There are several encoding appliances still on CentOS 6, having instructions to make it work would be useful.

Compiling and running on CentOS 6 using the README for CentOS 7 results in the following runtime errors:

stransmit: /usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.20' not found (required by stransmit)
stransmit: /usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.19' not found (required by stransmit)
stransmit: /usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.15' not found (required by stransmit)

brew install cmake
brew install openssl
export OPENSSL_ROOT_DIR=$(brew --prefix openssl)
export OPENSSL_LIB_DIR=$(brew --prefix openssl)"/lib"
export OPENSSL_INCLUDE_DIR=$(brew --prefix openssl)"/include"
./configure
make

If you don't do above exports (mac 10.12.6) I get the following at the make stage:

[ 82%] Linking CXX shared library libsrt.dylib Undefined symbols for architecture x86_64: "_EVP_aes_128_ctr", referenced from: _hcOpenSSL_EVP_CTR_SetKey in hc_openssl_evp_ctr.c.o "_EVP_aes_192_ctr", referenced from: _hcOpenSSL_EVP_CTR_SetKey in hc_openssl_evp_ctr.c.o "_EVP_aes_256_ctr", referenced from: _hcOpenSSL_EVP_CTR_SetKey in hc_openssl_evp_ctr.c.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [libsrt.1.2.0.dylib] Error 1 make[1]: *** [CMakeFiles/srt.dir/all] Error 2 make: *** [all] Error 2

My intent is to transmit an mpeg-ts stream with a fixed 5 second delay on the receiver side to allow for ample retransmission time of missed packets. My simplified example code setup for sender and receiver are below. Upon connection, the receiver's srt_recvmsg(..) starts by getting the packets with an expected 5 second delay from the sender; however, after approximately 30 seconds, that delay has linearly reduced to approximately 150ms. Is anyone else seeing this problem? Is there an error in my setup or am I fundamentally misunderstanding something?

//--------------------------------------------
Sender Setup example code:

int tsbpdMode = 1;
srt_setsockopt(ssock, 0, SRTO_TSBPDMODE, &tsbpdMode, sizeof(tsbpdMode));
int latencyMs = 5000;
srt_setsockopt(ssock, 0, SRTO_LATENCY, &latencyMs, sizeof(latencyMs));
srt_connect(ssock, (struct sockaddr*)&server, sizeof(server));
while(1){
waitForNextPkt(pkt, pktlen);
srt_sendmsg2(ssock, pkt, pktlen, NULL);
}

//--------------------------------------------
Receiver Setup example code:

int tsbpdMode = 1;
srt_setsockopt(rsock, 0, SRTO_TSBPDMODE, &tsbpdMode, sizeof(tsbpdMode));
int latencyMs = 5000;
srt_setsockopt(rsock, 0, SRTO_LATENCY, &latencyMs, sizeof(latencyMs));
srt_bind(rsock, (struct sockaddr*)&(serverdesc), sizeof(serverdesc));
srt_listen(rsock, 1);
csock = srt_accept(rsock, (struct sockaddr*)&from, &fromlen);
while(1){
bytesRead = srt_recvmsg(csock, buf, buflen);
}

According to the SRT team, SRT is designed to transport live streams. Transmitting a file is not a supported use case of the protocol or the stransmit utility. The stransmit utility allows for file input and output options as a way to allow for stdin/stdout.

This is an issue for us as we work with both livestream and archived content. In some cases we overlay both for certain use cases. While we're working to establish a workaround, support for both livestream and archived / filed-based content would make the protocol and the srtransmit utility something we could standardize on as oppose to experiment with. Thanks.

How can we set latency & passphase in stransmit?

I try to set latency in the stransmit uri, like:

Server
srt://IP:PORT?mode=server&latency=250

Client
srt://IP:PORT?mode=client&latency=250

How can i set passpharse in uri as well?

Doesn't work..

Thanks for SRT!

Somewhere between 1 minute and an hour stransmit server/receiver drops the client connection.
The process stays running and the port is still blocking,
but it will not accept reconnection attempts fron the client/caller.

On the encoder client I get one of these two errors:
107 (Transport endpoint is not connected)
104 (connection reset by peer)

the stransmit error is always the same:
FAILURE
recvmsg: [-1000] Unknown error.

I think it comes from stransmit.cpp line 1210 in bytevector READ; stat == SRT_ERROR.

Can I do something to avoid this error,
or can we catch the condition and recover the stream?

# stransmit -k -v srt://xx.xx.xx.xx:9100?mode=server udp://xx.xx.xx.xx:9110 >> /var/log/stransmit.`date +%s`.log 2>&1 &
    [1] 18048
# netstat -na | grep 9100
udp        0      0 xx.xx.xx.xx:9100      0.0.0.0:*       
# head stransmit.1493555817.log
Parameters:
        mode = 'server'
Opening SRT source server(blocking) on xx.xx.xx.xx:9100
PRE: blocking mode set: 1 timeout 0
Binding a server on xx.xx.xx.xx:9100 ... listen...  accept...  connected.
STARTING TRANSMISSION: 'srt://xx.xx.xx.xx:9100?mode=server' --> 'udp://xx.xx.xx.xx:9110'
 << 376  ->   sent
 << 376  ->   sent

### a few minutes later...
### encoder 'send buffer' and 'retransmit rate' spike high
### encoder state is disconnected: Last Error: 107 (Transport endpoint is not connected)

# tail -2 stransmit.1493555817.log
    FAILURE
    recvmsg: [-1000] Unknown error.
# ps -aef | grep stransmit
root     18048 15889  2 14:36 pts/2    00:00:09 stransmit -k -v srt://xx.xx.xx.xx:9100?mode=server udp://xx.xx.xx.xx:9110
# netstat -na | grep 9100
udp   427072      0 xx.xx.xx.xx:9100      0.0.0.0:*

Once srt_accept is called, it seems to be waiting for client socket infinitely.
Is there any API to cancel this waiting? If it's not cancellable, CUDTUnited::accept should use pthread_cond_timedwait instead of pthread_cond_wait.

(gdb) thread 5
[Switching to thread 5 (Thread 0x7f78b21fd700 (LWP 30964))]
#0  0x00007f78c9f761ad in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
(gdb) bt
#0  0x00007f78c9f761ad in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0
#1  0x00007f78c1488254 in CUDTUnited::accept(int, sockaddr*, int*) (this=0x7f78c16c17a0 <CUDT::s_UDTUnited>, listen=<optimized out>, addr=0x7f78b21fcd80, addrlen=0x7f78b21fcd50) at /home/joykim/git/srt-package/src/srt/srtcore/api.cpp:725
#2  0x00007f78c14884ba in CUDT::accept(int, sockaddr*, int*) (u=<optimized out>, addr=<optimized out>, addrlen=<optimized out>) at /home/joykim/git/srt-package/src/srt/srtcore/api.cpp:1867
#3  0x00007f78c1a713e1 in idle_listen_callback (data=0x562f186e4830)
    at ../subprojects/gst-plugins-bad/ext/srt/gstsrtserversink.c:213
#4  0x00007f78ca425725 in g_main_dispatch (context=0x562f187fc780) at gmain.c:3234
#5  0x00007f78ca425725 in g_main_context_dispatch (context=context@entry=0x562f187fc780) at gmain.c:3899
#6  0x00007f78ca425ae8 in g_main_context_iterate (context=0x562f187fc780, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3972
#7  0x00007f78ca425e02 in g_main_loop_run (loop=0x562f187fc580) at gmain.c:4168
#8  0x00007f78c1a7159d in thread_func (data=0x562f186e4830)
    at ../subprojects/gst-plugins-bad/ext/srt/gstsrtserversink.c:241
#9  0x00007f78ca44c9a5 in g_thread_proxy (data=0x562f1876b400) at gthread.c:784
#10 0x00007f78c9f70049 in start_thread () at /usr/lib/libpthread.so.0
#11 0x00007f78c9cb0f0f in clone () at /usr/lib/libc.so.6

Hi
I am new to SRT and manged to make it working
On receiving end, i use the below command
./stransmit -v srt://:9000 udp://@225.6.220.41:3000

Can you tell me how to add TTL value to the multicast ?
i tried ./stransmit -v srt://:9000 udp://@225.6.220.41:3000?ttl=32 , but not working

I would be very interested to see if this can be used for high quality low latency screen sharing.

For example with ffmpeg -y -f x11grab.

"file://con" is a bit hackish. Please consider something similar to pipe:[ file descriptor # ]

Besides being more explicit, it would also allow using file descriptors other than 0 and 1

During the works with file transfer support (congestion control), I found it necessary to make various refactoring works, mainly in the following areas:

• old UDT legacy symbols have to be removed or made an alias to existing SRT symbols. There should be just one set of symbols to be possibly updated when adding new features.
• all reusable components should be moved to appropriate locations, as follows:
  • utilities.h: should be in common directory and contain general purpose utilities
  • srtcore/common.h: should contain only SRT-related utilities
  • common/appcommon.hpp: should contain only common things used by SRT applications
• Options should be also able to handle "enum" type values - a predefined set of strings mapped to particular enum values, which is the value type used by particular socket option

Hi All,

I've been using SRT to transmit RTP Video Streams Packet to over one-to-one SRT Socket API's.

With this approach, I can only send video to few number of clients connected to Same router.
What I want to achieve here is to send the data using SRT to Multicast Group and Receiver subscribe to the group and start receiving data, given that I can still take the advantage of SRT Protocol ( packet recovery and re-transmit, latency)

Is that possible using SRT now?

Regards,
Gurtaj

This is not an issue, i want to discuss a pipeline for several SRT locations worldwide.

We plan to setup a demo pipeline for SRT around the world.

I have crosscompile SRT transmit and installed it on our low power ARM devices in our Datacenters in Germany (Frankfurt), in Miami (USA) and Asia Tokyo for testing. For stablest transmission i would like to setup a whole SRT pipeline.

I want to use SRT all the time cause we will have then the stables transmission.

We start with UDP on my localhost as a MPEGTS Livestream and we sent it to first location in frankfurt:

Local Maschine:
udp://192.168.1.119:9000 srt://:9000?mode=client

In Frankfurt and for a first test i setup:
srt://:9000?mode=server udp://locahost:9001

For SRT back pipe in Frankfurt:
udp://localhost:9001 srt://:9002?mode=server

For testing this pipeline i try now a local playback on my notebook:
srt://:9002 file con HEVC Decoder

And it works.

To reduce the number of pipelines and protocols transmuxing from SRT vs. UDP, i tried to setup 2 server instances:

srt://:9000?mode=server srt://:9001?mode=server -v

Then send our local transmuxed UDP stream to frankfurt:
udp://192.168.1.119:9000 srt://:9000?mode=client

Grab it back on localmaschine:
srt://:9001 - HEVC Decoder

Works for 10-20 seconds, then i got:

But, after some seconds i got:
srt_sendmsg: [5004] Operation not supported: Invalid socket ID.
SrtCommon: DESTROYING CONNECTION, closing sockets

Is there an other better way with other modes in SRT?

When we have a first stable pipe, i will start send SRT around the world :)

Happy IP-Streaming.

This is an issue we experienced initially with UDT. That said - despite SRT using UDT underneath - the behaviour is slightly different.

setup 1

• UDP source (DVB-T stream)
• stransmit sender
• link under test
• stransmit reader
• UDP sink

setup 2

• UDP source (DVB-T stream)
• stransmit sender
• link under test
• Makito X Decoder + HDMI display

Under normal conditions what we put into the SRT link we get out. Increasing RTT to 500ms (at link level) is still OK. However, when we add a small percentage of jitter (10ms with 25% correlation) it's getting interesting. The sender increases its output to about 200% while the reader indicates lost traffic.

In general no payload is lost. For small bandwidth usage everything keeps running, above a certain level (e.g. 15Mbit) the SRT link breaks down after 10-20 seconds.

So what's going on here? How can a 2% variation in RTT have such odd effects? How - if possible - can this be avoided?

As per request, the API should be unified and the user shouldn't worry which function should be used in which mode and in which mode it is not allowed.

The sending and receiving functions should get only different names due to different signatures and sets of parameters, but they should do exactly the same job, unless this is something on different level of abstraction (such as sendfile/recvfile functions), whereas the alternatives of how the function should behave should be selected by internal parameters, which define the transmission mode.

Do also a cleanup of the API and make the legacy UDT API a secondary, backward alias or optional C++ API parts.