librist issueshttps://code.videolan.org/rist/librist/-/issues2024-03-04T17:15:36Zhttps://code.videolan.org/rist/librist/-/issues/175librist fails compiling in MSYS2/MinGW64/GCC 13.2 in libmbedcrypto.a(entropy_...2024-03-04T17:15:36ZLigH-delibrist fails compiling in MSYS2/MinGW64/GCC 13.2 in libmbedcrypto.a(entropy_poll.c.obj): undefined reference to `BCryptGenRandom'I use the media-autobuild suite co build a static ffmpeg for Windows in an MSYS2 environment with MinGW32 or MinGW64 and GCC 13.2. Currently I changed the script back to revert a previous change, because MSYS2 does not ship cJSON for Min...I use the media-autobuild suite co build a static ffmpeg for Windows in an MSYS2 environment with MinGW32 or MinGW64 and GCC 13.2. Currently I changed the script back to revert a previous change, because MSYS2 does not ship cJSON for MinGW32 anymore [I reenabled the use of librist's internal cJSON](https://github.com/m-ab-s/media-autobuild_suite/issues/2593#issuecomment-1931809959): `extracommands=("-Dbuiltin_cjson=true")`
The MinGW32 pass builds librist without an error:
[librist-git/build-32bit/ab-suite.build.log](/uploads/6ce06354fd30b68dda64b0cdb93e7906/ab-suite.build.log)
The MinGW64 pass now fails:
[librist-git/build-32bit/ab-suite.build.log](/uploads/e06f4aec03a65a2325d538178121d1cf/ab-suite.build.log)
```
[42/54] Linking target tools/ristsender.exe
FAILED: tools/ristsender.exe
"gcc.bat" -o tools/ristsender.exe tools/ristsender.exe.p/ristsender.c.obj tools/ristsender.exe.p/oob_shared.c.obj tools/ristsender.exe.p/srp_shared.c.obj tools/ristsender.exe.p/.._contrib_getopt-shim.c.obj tools/ristsender.exe.p/.._contrib_time-shim.c.obj tools/ristsender.exe.p/.._contrib_pthread-shim.c.obj "-Wl,--allow-shlib-undefined" "-Wl,-O1" "-fstack-protector-strong" "-mtune=generic" "-O2" "-pipe" "-static-libgcc" "-static-libstdc++" "-D_FORTIFY_SOURCE=2" "-fstack-protector-strong" "-mtune=generic" "-O2" "-D__USE_MINGW_ANSI_STDIO=1" "-mthreads" "-Wl,--start-group" "librist.a" "-pthread" "-lws2_32" "-lmbedcrypto" "-lws2_32" "-liphlpapi" "-lmbedcrypto" "-Wl,--subsystem,console" "-lkernel32" "-luser32" "-lgdi32" "-lwinspool" "-lshell32" "-lole32" "-loleaut32" "-luuid" "-lcomdlg32" "-ladvapi32" "-Wl,--end-group"
G:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: G:/MABS/msys64/mingw64/lib/../lib/libmbedcrypto.a(entropy_poll.c.obj):(.text+0x43): undefined reference to `BCryptGenRandom'
collect2.exe: error: ld returned 1 exit status
```
Full set of log files collected by M-AB-S:
[logs.zip](/uploads/0d471c272f44c3eb49c897cb70e75b61/logs.zip)https://code.videolan.org/rist/librist/-/issues/174Add per-byte stats2024-02-08T16:24:09ZGuillermo TrejoAdd per-byte statsCan per-byte stats be added? Currently now we have, for example:
```
struct rist_stats_sender_peer {
...
/* num sent packets */
uint64_t sent;
/* num received packets */
uint64_t received;
/* retransmitted packets */
uint64_t retr...Can per-byte stats be added? Currently now we have, for example:
```
struct rist_stats_sender_peer {
...
/* num sent packets */
uint64_t sent;
/* num received packets */
uint64_t received;
/* retransmitted packets */
uint64_t retransmitted;
```
or
```
struct rist_stats_receiver_flow {
...
/* num sent packets */
uint64_t sent;
/* num received packets */
uint64_t received;
/* lost packets */
uint32_t lost;
```
Could the same versions be added but counting the bytes?
e.g.
```
struct rist_stats_receiver_flow {
...
/* num sent bytes */
uint64_t bytes_sent;
/* num received bytes */
uint64_t bytes_received;
/* lost bytes */
uint32_t bytes_lost;
```https://code.videolan.org/rist/librist/-/issues/173Slow packet feed results in packet loss (listener/sender, caller/receiver)2023-11-10T12:57:34ZRichard HazlewoodSlow packet feed results in packet loss (listener/sender, caller/receiver)It appears that feeding single packets into a listener/sender results in one not arriving at a caller/receiver.
Flipping around to a caller/sender, listener/receiver does not have the same issue.
Sample code attached.
[listen_snd_...It appears that feeding single packets into a listener/sender results in one not arriving at a caller/receiver.
Flipping around to a caller/sender, listener/receiver does not have the same issue.
Sample code attached.
[listen_snd__caller_rcv__single.c](/uploads/ca481c25cd7be53b6b886401ca999f86/listen_snd__caller_rcv__single.c)
Compiled against libRIST at: 1e805500dc14a507598cebdd49557c32e514899fhttps://code.videolan.org/rist/librist/-/issues/170Huge loss of precision when converting timestamps from NTP to RTP and viceversa2023-11-27T19:05:12ZGuillermo TrejoHuge loss of precision when converting timestamps from NTP to RTP and viceversaat srt/udp.c:
```
uint32_t timestampRTP_u32( int advanced, uint64_t i_ntp )
{
if (!advanced) {
i_ntp *= RTP_PTYPE_MPEGTS_CLOCKHZ;
i_ntp = i_ntp >> 32;
return (uint32_t)i_ntp;
}
else
{
// We just need the middle 32 bits, i.e....at srt/udp.c:
```
uint32_t timestampRTP_u32( int advanced, uint64_t i_ntp )
{
if (!advanced) {
i_ntp *= RTP_PTYPE_MPEGTS_CLOCKHZ;
i_ntp = i_ntp >> 32;
return (uint32_t)i_ntp;
}
else
{
// We just need the middle 32 bits, i.e. 65536Hz clock
i_ntp = i_ntp >> 16;
return (uint32_t)i_ntp;
}
}
```
And in general in all the conversions from NTP to RTP, shouldn't the shift occur before the multiplication?
In NTP, you have the seconds in the most significant 32 bits of the 64-bit timestamp. So if you grab that giant number and multiply by 90000, you have an overflow because now you have a number that does not fit in the 64bits of the uint64_t.
In the next line, you are discarding the lowest 32bits of the NTP (fractions of seconds) anyway, so you could just do that first and THEN multiply by 90000.
The same goes for converting RTP to NTP if you change this. You should first divide by 90000 and then shift 32 bits to the right to recover the NTP format (the fractions of seconds in the lowest 32 bits is lost in the conversion of course).
Here is a demostrated example. I have this NTP timestamp (the lowest 32 bits are erased for more clarity):
![Screenshot_20230913_184808](/uploads/64acd3308220eda4320fef65568e4c82/Screenshot_20230913_184808.png)
Then I multiply by 90000. A number with 19 digits is converted to a number with 24 digits (max for uint64_t is 20 digits)
![image](/uploads/ba00d04d6c6d5624e30ed05f0e689363/image.png)
If you do that in C++ instead of a calculator, the moment you do the multiplication you will have a number that does not make any sense because it is truncated.
I hope I made myself clear. Thanks!https://code.videolan.org/rist/librist/-/issues/161[FR] Provide public accessor to acquire peer cname2023-10-30T15:06:26ZRichard Hazlewood[FR] Provide public accessor to acquire peer cnameThe authorization connection callback provides various socket-related identifiers, but these do not easily disambiguate some remote connections; e.g. multiple remote connections from the same host: the port value is the only difference, ...The authorization connection callback provides various socket-related identifiers, but these do not easily disambiguate some remote connections; e.g. multiple remote connections from the same host: the port value is the only difference, but this is from the server's POV.
The `cname` is a useful identifier, but (AFAICT) this is only available from the stats; it can be used, but we have to wait for stats to arrive (and, in some configurations, this only happens once data starts to flow - even though the connection has been made).
The `cname` field is available in the `rist_peer` struct, but this struct is opaque. This could be accessed via trickery (as described in the [Wiki](https://code.videolan.org/rist/librist/-/wikis/5.-libRIST-Function-Reference)), but it would be useful if an accessor was provided: much like `rist_peer_get_id`.0.2.11https://code.videolan.org/rist/librist/-/issues/158[FR] Allow specification of local port for caller2023-10-30T15:06:22ZRichard Hazlewood[FR] Allow specification of local port for callerWhen configuring a peer as a caller there appears to be little way to control the `local_port` setting in the (opaque) `peer_config` struct.
The `rist_create_peer` function in [udp.c](https://code.videolan.org/rist/librist/-/blob/maste...When configuring a peer as a caller there appears to be little way to control the `local_port` setting in the (opaque) `peer_config` struct.
The `rist_create_peer` function in [udp.c](https://code.videolan.org/rist/librist/-/blob/master/src/udp.c#L578) selects an incrementing port value, offset from 32768.
When trying to manually configure the `rist_peer_config` struct, by forcing the `address_family`, the `physical_port` field appears to be used for the _destination_ port. But, AFAICT, the local_port is still not configurable.
In a larger system, with potential races to acquire ports, or a locked down network (e.g. firewall), this can be problematic.0.2.11https://code.videolan.org/rist/librist/-/issues/156Ristreceiver weight strange behavior on Windows2023-04-04T13:24:28ZManuelRistreceiver weight strange behavior on WindowsTesting a connection with two routes, when configuring its weight, RISTreceiver on Windows only connects through one route. Same parameters but using RISTreceiver on MacOS, it correctly distributes the load between the paths.Testing a connection with two routes, when configuring its weight, RISTreceiver on Windows only connects through one route. Same parameters but using RISTreceiver on MacOS, it correctly distributes the load between the paths.https://code.videolan.org/rist/librist/-/issues/155Ristreceiver stats are not displayed on Windows2023-04-04T10:31:24ZManuelRistreceiver stats are not displayed on WindowsApparently the RISTreceiver statistics are not displayed on Windows. Same parameters if they work on RISTreceiver MacOS. On Windows only RISTsender statistics work. In all cases the connection is established without problems and the para...Apparently the RISTreceiver statistics are not displayed on Windows. Same parameters if they work on RISTreceiver MacOS. On Windows only RISTsender statistics work. In all cases the connection is established without problems and the parameter used is "-v 6".
Error probado en Windows 7 y Windows 11.
![image](/uploads/94eedee00232041ab148d65c30f96281/image.png)https://code.videolan.org/rist/librist/-/issues/145How many sender contexts/peers do I need in this configuration?2022-07-11T06:03:57ZOliver CollyerHow many sender contexts/peers do I need in this configuration?Video server (VS) has streams A, B and C and listens out for video player (VP) connections. VS I assume has one (or more?) rist senders. VP has a rist receiver.
VPs can connect to the VS and view either A, B or C. VPs are in separate lo...Video server (VS) has streams A, B and C and listens out for video player (VP) connections. VS I assume has one (or more?) rist senders. VP has a rist receiver.
VPs can connect to the VS and view either A, B or C. VPs are in separate locations (IP addresses).
More than one VP can view A, B or C at the same time.
I obviously don't want to send all of A, B and C to each VP as one "flow" and have the VP separate them.
Does VS need to listen on one separate port for each of A, B and C?
If yes, does this require an independent rist sender context per port, or can one sender listen on all ports? I think it can, by creating a peer with "//@:port" for each one? So, if I have a peer per port, how do I send packets from A, B or C to the right peer? Is it something relating to the virt_dst_port?
If no, and I can do it all by having one rist sender context listening on one port, again how do I send packets from A, B or C to the appropriate VP? Can a receiver that "dials-in" provide any information in the initial handshake that could be used to conceptually link it to the stream A, B or C that it requires?
I know I can create a separate rist sender context for each of A, B and C, each set up to listen, and VP just needs to choose the right port to connect to, and this would work, but is that the only way to achieve this set up?https://code.videolan.org/rist/librist/-/issues/144Peer config parameters, which side: sender, receiver or both? (and other Qs)2022-07-09T08:27:04ZOliver CollyerPeer config parameters, which side: sender, receiver or both? (and other Qs)I'm experimenting with integrating libRIST into my project and I have a few questions.
My use-case is a custom video stream server streaming video to a custom video player. The video server will have a rist sender set to listen mode. Th...I'm experimenting with integrating libRIST into my project and I have a few questions.
My use-case is a custom video stream server streaming video to a custom video player. The video server will have a rist sender set to listen mode. The player will then have a rist receiver which connects to the rist sender. It's possible more than one player will connect to the same rist sender.
1. I am trying to understand which side the peer config needs setting for different parameters.
For example, if my video source has a bitrate of 4mbps, then do I set that (+overhead) on the video server (sender) side, on the receiver side, or both? I have come from a background of using SRT and I set this on the server/sender side with SRT. Is it the same with RIST?
2. Similar Q regarding the buffer size. Is that sender or receiver side or both? What happens if I set the sender to buffer size X, but receivers have different buffer sizes? I would think that the sender side would need to have a buffer of the maximum of all its peers, so that it still has the packets available to send to the peers if they request? Is it my responsibility to ensure this is the case? On SRT (which is one-to-one only, or at least was) I think it takes the maximum.
3. I would like to be able to change to a different bitrate without breaking the connection, as I can do with SRT, but am I right in thinking that at the moment one cannot change the bitrate setting of the peer config without restarting both sender + receiver?
Thank you for your time.https://code.videolan.org/rist/librist/-/issues/141When connection is lost, socket error and stats callback stops2022-03-04T16:09:29ZBlueWaterCrystalWhen connection is lost, socket error and stats callback stopsHi,
When the connection is lost both receiver and sender has a wall of text socket error and both have to be restarted.
On the sender, the stats callback stops when 50% packet drop or loss of connection
```
The receiver code is fully...Hi,
When the connection is lost both receiver and sender has a wall of text socket error and both have to be restarted.
On the sender, the stats callback stops when 50% packet drop or loss of connection
```
The receiver code is fully ristreceiver.c in tools
The sender code is partially ristsender.c in tools
```https://code.videolan.org/rist/librist/-/issues/140URL parameters rtp-sequence and rtp-timestamp are not supported2023-10-30T15:06:17ZMichel Vanden BroeckeURL parameters rtp-sequence and rtp-timestamp are not supportedFor the rtp URL, additional parameters "rtp-sequence" and "rtp-timestamp" to enable the carry over of sequence number and timestamp are not working. Seen with v0.2.6.For the rtp URL, additional parameters "rtp-sequence" and "rtp-timestamp" to enable the carry over of sequence number and timestamp are not working. Seen with v0.2.6.0.2.11https://code.videolan.org/rist/librist/-/issues/139Ristsender and Ristreceiver Tunneling Examples2022-03-03T13:14:23ZEnes UserRistsender and Ristreceiver Tunneling ExamplesHello,
I have been testing tun_support branch for a while. I tried to test the examples given in [this](https://code.videolan.org/rist/librist/-/wikis/2.-ristsender-Syntax-and-Examples) wiki page. When I test the second example, I can s...Hello,
I have been testing tun_support branch for a while. I tried to test the examples given in [this](https://code.videolan.org/rist/librist/-/wikis/2.-ristsender-Syntax-and-Examples) wiki page. When I test the second example, I can see that only one port is opened for both data and message transmission. This contradicts the given information which states that one extra port is used for messaging if tun name is not specified. My question is whether the examples are out of date. If they are, is there a better source I can use to test tun_support branch?
Thanks in Advance,
Eneshttps://code.videolan.org/rist/librist/-/issues/136Bonding implementation in Rist receiver (Simple Profile)2021-12-21T13:39:09ZNassim TLILIBonding implementation in Rist receiver (Simple Profile)Hello, Please someone could show me an example of C code setting up a rist receiver with Bounding feature.
I saw the "ristreceiver.c" test code but I think it does not support bounding.Hello, Please someone could show me an example of C code setting up a rist receiver with Bounding feature.
I saw the "ristreceiver.c" test code but I think it does not support bounding.https://code.videolan.org/rist/librist/-/issues/127Announce: librist now available on macOS through Homebrew2021-11-18T10:54:12ZThierry LelegardAnnounce: librist now available on macOS through HomebrewHi,
The RIST library (shared and static), its header files and the four basic tools (`ristreceiver`, `ristsender`, `rist2rist` and `ristsrppasswd`) are now available on macOS as a standard Homebrew package, including on the new M1 ("App...Hi,
The RIST library (shared and static), its header files and the four basic tools (`ristreceiver`, `ristsender`, `rist2rist` and `ristsrppasswd`) are now available on macOS as a standard Homebrew package, including on the new M1 ("Apple Silicon") Arm64-based Mac systems.
[Homebrew](https://brew.sh/) is the standard package manager for all open-source software on macOS.
If you already have Homebrew setup on your Mac, installing RIST is just this:
~~~
brew install librist
~~~
If you haven't installed Homebrew yet, the somewhat esoteric command to install it is published on top of the [Homebrew](https://brew.sh/) home page:
~~~
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
~~~
On classical x86_64 Intel Macs, Homebrew is installed in `/usr/local`. On Arm64-based Macs, the root is `/opt/homebrew`. Make sure to have its `bin` subdirectory in your `PATH`.
If you had installed the previous temporary "Homebrew tap" that I had setup for RIST, deactivate it before reinstalling the new official version:
~~~
brew uninstall rist
brew untap tsduck/rist
~~~
To get this, I have pushed a "Homebrew formula" (that's the way it is named) [for librist](https://github.com/Homebrew/homebrew-core/blob/master/Formula/librist.rb), which acts as a request to include a new package in Homebrew. That request was merged today. Note that the official package name is `librist`, not `rist`, upon request from the Homebrew maintainers.https://code.videolan.org/rist/librist/-/issues/126Questions on authentication, what to do in librist vs application2021-09-21T14:53:00ZThierry LelegardQuestions on authentication, what to do in librist vs applicationHi,
I have a couple of questions concerning authentication and how the work is shared between librist and the application.
I have read the [wiki article on authentication](https://code.videolan.org/rist/librist/-/wikis/Authentication-a...Hi,
I have a couple of questions concerning authentication and how the work is shared between librist and the application.
I have read the [wiki article on authentication](https://code.videolan.org/rist/librist/-/wikis/Authentication-and-the-ristsrppasswd-Utility). Then I looked at files `librist_srp.h` (public header) and `eap.c`/`.h` (internal libsrt files). The protocol is mostly handled inside libsrt and this is fine.
However, looking at the applications `ristreceiver.c` and `ristsender.c`, I see that they have to provide their own `cb_auth_connect`. This callback simply builds an OOB message and sends it back to the peer where it will be processed internally by the EAP part of libsrt. Am I right?
If I understand correctly, isn't there a mismatch in the respective roles of librist and the application? The structure of the OOB message which is used to transport authentication message is part of EAP and should be remain internal to librist. Even more, the simple fact that the authentication callback shall return an OOB message is internal to the EAP part of librist. In other words, `rist_enable_eap_srp` should setup its own authentication callback which does the job. Maybe `rist_enable_eap_srp` is invoked too early to setup an authentication callback. In that case, a specific "enable auth callbacks for eap srp" function should be added.
As an additional request, would it be possible to move into librist the management of password files as used by `ristsrppasswd`? I understand that this feature is not really a RIST feature, any application can implement its own authentication validation mechanism. However, having such a feature in librist would allow any application to be compatible with `ristsrppasswd` without duplicating `tools/srp_shared.c` in each application.
To summarize, I suggest that applications have two possible simple levels of authentication:
1. Provide a `user_verifier_lookup_t` function, call `rist_enable_eap_srp` (and possible an additional rist function later) and that's all. The application should not have to mess with the internal OOB message as used in EAP SRP.
2. Same as 1. with a librist-provided `user_verifier_lookup_t` function which handles `ristsrppasswd` files.
Does it make sense?https://code.videolan.org/rist/librist/-/issues/125Announce: RIST plugin for TSDuck2021-10-21T20:48:57ZThierry LelegardAnnounce: RIST plugin for TSDuckHello,
For those who use [TSDuck](https://tsduck.io), I have pushed an initial version of a very simple RIST plugin.
If you haven't yet used TSDuck, this is a general-purpose toolbox for Digital TV engineers using MPEG transport stream...Hello,
For those who use [TSDuck](https://tsduck.io), I have pushed an initial version of a very simple RIST plugin.
If you haven't yet used TSDuck, this is a general-purpose toolbox for Digital TV engineers using MPEG transport streams. Its basic version comes with 13 input plugins, 11 output plugins and 72 packet processing plugins. Third-party or private proprietary plugins and extensions also exist.
The new `rist` plugin is used as input and output plugin. The current version is simple, several sender/receiver URL's, encryption but no authentication for now.
The plugin documentation has been added in the [TSDuck user's guide](https://tsduck.io/download/docs/tsduck.pdf).
The `rist` plugin can be compiled on Linux, macOS and Windows. However, it is not compiled by default on Linux because `librist` is not available in any Linux distro. Building TSDuck binary packages with RIST support would create a dependency on non-existing `librist` packages.
To build TSDuck yourself with RIST support, first install `librist`. Either rebuild it and install it yourself or use one of the pre-built Linux packages from [project rist-installer](https://github.com/tsduck/rist-installer/releases), a sister-project of TSDuck. Once `librist` is installed, just use `make RIST=1` to build TSDuck with RIST support. See [more details here](https://tsduck.io/doxy/building.html).
On Windows, the situation is simpler. There is no central repository and all tools and libraries must be downloaded from their original location. Moreover, a library which is compiled with a recent version of Windows can be used on all versions (this is not the case on Linux where each version of a distro has a specific repository of packages). The [project rist-installer](https://github.com/tsduck/rist-installer/releases) also provides binaries for Windows. These binaries are downloaded before building TSDuck, just like any other dependency. As a consequence, Windows is currently the only version of TSDuck with pre-built RIST support. The [nightly builds](https://tsduck.io/download/prerelease/) will contain a RIST-enabled TSDuck by tomorrow (use version 2.28-2534 or higher).
On macOS, `librist` has been recently added to Homebrew and TSDuck is now built is RIST support on macOS.
If anyone is interested in testing this, please do. Any feedback is welcome, especially since I am not a RIST expert (I didn't even know that acronym a few weeks ago, until a TSDuck user suggested to support RIST as input/output plugin).
I may have a few questions. I will post them in this thread. The first one concerns the granularity of transported data. Is RIST stream-oriented or message-oriented? If a block of N bytes is sent using `rist_sender_data_write()`, is it guaranteed that the same N bytes are grouped in the same data block as read by `rist_receiver_data_read2()`? In the case of MPEG transport streams, the sender always sends an integral number of TS packets. I would like to know if the received will get complete TS packets in each data blocks or if some sort of buffering / reassembly is required. In practice, my tests demonstrate that this is the case but is it guaranteed or just an effect of pushing chunks of data in the stream (as it is often the case with TCP, until it breaks).
If you are interested in the [project rist-installer](https://github.com/tsduck/rist-installer/), we can discuss this too.https://code.videolan.org/rist/librist/-/issues/121Assigning Outgoing Port For Client2023-10-30T15:06:13ZEnes UserAssigning Outgoing Port For ClientHello,
Is there anyway to assign the outgoing port of the client side? From my understanding, it is randomly assigned. Or will there be a socket option to assign a value to this port in the future? Because we need to know the outgoing p...Hello,
Is there anyway to assign the outgoing port of the client side? From my understanding, it is randomly assigned. Or will there be a socket option to assign a value to this port in the future? Because we need to know the outgoing port for our implementation to add some level of security.
Thank you
Enes0.2.11https://code.videolan.org/rist/librist/-/issues/114DTLS implementation in ristsender and ristreceiver2021-08-09T16:34:22ZEnes UserDTLS implementation in ristsender and ristreceiverHello,
I have been trying to implement DTLS to ristsender and ristreceiver tools. I use mbedtls library. But I am not sure where to start. Should DTLS handshake be initiated inside or outside of ristsender and ristreceiver for instance?...Hello,
I have been trying to implement DTLS to ristsender and ristreceiver tools. I use mbedtls library. But I am not sure where to start. Should DTLS handshake be initiated inside or outside of ristsender and ristreceiver for instance? I am looking for some advice or resource to make things a little bit clear.
Thanks in advance
Eneshttps://code.videolan.org/rist/librist/-/issues/113Multiplex, only the last stream is working2021-07-05T07:31:48ZMextrilMultiplex, only the last stream is workingProblem : ristsender only sending the last stream when sender act as listener (@).
It's working properly when the listener in receiver side.
Sender:
ristsender -i 'udp://224.1.1.1:7001?stream-id=10,udp://224.1.1.2:7002?stream-id=20...Problem : ristsender only sending the last stream when sender act as listener (@).
It's working properly when the listener in receiver side.
Sender:
ristsender -i 'udp://224.1.1.1:7001?stream-id=10,udp://224.1.1.2:7002?stream-id=20' \
-o 'rist://@192.168.1.30:8200?cname=sender01' -p 1 -v 8
Receiver:
ristreceiver -i 'rist://192.168.1.30:8200?cname=receiver01' \
-o "udp://224.4.4.1:7001?stream-id=10,udp://224.4.4.2:7002?stream-id=20" -p 1 -v 6
Attached the logs.
[rcv.txt](/uploads/1a33c3447be80017d6008f1946f09874/rcv.txt)
[snd.txt](/uploads/12d7b09727c419d6b70b537f086f8fca/snd.txt)0.3 release