Feature: Multiple streams/channels

Title is really self descriptive. Would be really cool to have the ability to make multiple feeds available.
Fantastic work so far @GRVYDEV, I've been looking for something like this for a while!

While this would be cool I am not exactly sure that this is where I want this project to go. I will keep it in mind though! Best case scenario this wont be added for a while anyways

While this would be cool I am not exactly sure that this is where I want this project to go. I will keep it in mind though! Best case scenario this wont be added for a while anyways

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams?  As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams?  As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams? As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

This would be awesome... but a nightmare as it would involve making OBS send multiple streams to the server and that would take a lot of modification to OBS

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams? As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

This would be awesome... but a nightmare as it would involve making OBS send multiple streams to the server and that would take a lot of modification to OBS

I would like to +1 this feature request and volunteer some time to work on this. Early 2020 I went about setting up my own streaming server and found the landscape to be pretty empty. Your project goes end-to-end, even including a frontend, and is more straightforward and self-contained than anything else out there. This project has a lot of potential, great job!
I've been thinking about what it would take to turn the backend (inget + webrtc) into a multi-tenant server (can receive multiple streams from multiple origins and send each to a unique webrtc endpoint). It would definitely involve collaboration between ingest and webrtc, in the form of sharing config and communicating events to each other.
In other words, I'm imagining a server that could be configured something like this, where you explicitly define each endpoint:
[server]
# the websocket port
webrtc-port = 8080
# need to have a "pool" of RTP ports that can be handed out in FTL handshakes
# the backend isn't listening to any of these at first, but when a handshake is finalizing,
# the backend chooses one available port from this pool, marks it in-use, and starts
# listening on that port. when a stream disconnects, need to put its port back into
# the pool.
rtp-port-range-start = 65535
rtp-port-range-end = 65555

[streams]

[streams.default]
# "default" is just the stream name used for logging
# path is used to build the websocket URL. so to view this stream, the frontend will
# open a websocket to http(s)://example.com:8080/websocket
path = "websocket"
# this is the channel id used to derive the stream key. the "server" config section would
# probably need a "hmac" config value, pair those together to generate the stream key.
channel = 123456789

[streams.example]
path = "test"
channel = 987654321

With all the communication between "ingest" and "webrtc" (to open/close UDP for RTP ports, and to start/stop accepting requests at certain websocket URLs, all in response to handshakes), it would be a lot easier if the backend were a single binary. I see that Rust's webrtc implementation is not ready for use, which explains why Go handles those parts. But given the simplicity of the FTL handshaking process, it is conceivable that the Go code could do the handshake as well as its current roles.
Would you consider a PR that subsumes the ingest project into the webrtc project, creating a single Go binary for the entire backend? This would be a preliminary step towards multi-tenent, the next step would probably be to add a configuration system.

I would like to +1 this feature request and volunteer some time to work on this. Early 2020 I went about setting up my own streaming server and found the landscape to be pretty empty. Your project goes end-to-end, even including a frontend, and is more straightforward and self-contained than anything else out there. This project has a lot of potential, great job!
I've been thinking about what it would take to turn the backend (inget + webrtc) into a multi-tenant server (can receive multiple streams from multiple origins and send each to a unique webrtc endpoint). It would definitely involve collaboration between ingest and webrtc, in the form of sharing config and communicating events to each other.
In other words, I'm imagining a server that could be configured something like this, where you explicitly define each endpoint:
[server]
# the websocket port
webrtc-port = 8080
# need to have a "pool" of RTP ports that can be handed out in FTL handshakes
# the backend isn't listening to any of these at first, but when a handshake is finalizing,
# the backend chooses one available port from this pool, marks it in-use, and starts
# listening on that port. when a stream disconnects, need to put its port back into
# the pool.
rtp-port-range-start = 65535
rtp-port-range-end = 65555

[streams]

[streams.default]
# "default" is just the stream name used for logging
# path is used to build the websocket URL. so to view this stream, the frontend will
# open a websocket to http(s)://example.com:8080/websocket
path = "websocket"
# this is the channel id used to derive the stream key. the "server" config section would
# probably need a "hmac" config value, pair those together to generate the stream key.
channel = 123456789

[streams.example]
path = "test"
channel = 987654321

With all the communication between "ingest" and "webrtc" (to open/close UDP for RTP ports, and to start/stop accepting requests at certain websocket URLs, all in response to handshakes), it would be a lot easier if the backend were a single binary. I see that Rust's webrtc implementation is not ready for use, which explains why Go handles those parts. But given the simplicity of the FTL handshaking process, it is conceivable that the Go code could do the handshake as well as its current roles.
Would you consider a PR that subsumes the ingest project into the webrtc project, creating a single Go binary for the entire backend? This would be a preliminary step towards multi-tenent, the next step would probably be to add a configuration system.

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams? As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

Multiple video & audio feeds from different streamers. The reason why I ask is that I was thinking about using this as a centralised low-latency "cleanfeed" (that remote talent accesses) for some live video production work which sometimes involves multiple distinct feeds. There are closed source, enterprise solutions to this but the investment needed is a little too much for my purposes (and wallet). :D
@woodrowbarlow gets what I mean.

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams? As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

Multiple video & audio feeds from different streamers. The reason why I ask is that I was thinking about using this as a centralised low-latency "cleanfeed" (that remote talent accesses) for some live video production work which sometimes involves multiple distinct feeds. There are closed source, enterprise solutions to this but the investment needed is a little too much for my purposes (and wallet). :D
@woodrowbarlow gets what I mean.

I see this comment from you (@GRVYDEV ) in #16:

This is the reason that I want to keep the ingest decoupled from the WebRTC broadcast though as someone could easily swap another ingest in as long as it outputs RTP packets.

Which makes perfect sense to me and implies that you would be more interested in adding an API between ingest and webrtc than you would be in combining them -- if going this route at all, that is.

I see this comment from you (@GRVYDEV ) in #16:

This is the reason that I want to keep the ingest decoupled from the WebRTC broadcast though as someone could easily swap another ingest in as long as it outputs RTP packets.

Which makes perfect sense to me and implies that you would be more interested in adding an API between ingest and webrtc than you would be in combining them -- if going this route at all, that is.

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams? As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

Multiple video & audio feeds from different streamers. The reason why I ask is that I was thinking about using this as a centralised low-latency "cleanfeed" (that remote talent accesses) for some live video production work which sometimes involves multiple distinct feeds. There are closed source, enterprise solutions to this but the investment needed is a little too much for my purposes (and wallet). :D
@woodrowbarlow gets what I mean.

+1 here. The ability to host a single instance of this and have multiple producers each send a production feed to the same instance if multiple broadcasts are ongoing with multiple commentators per producer connecting to each of the clean feeds would literally be our drop in replacement for Mixer. Would also mean for our large scale events where we want to have as many remote camera operators as possible, one instance of this project could allow us to bring in multiple 1080p60 streams with minimal latency for broadcasting purposes.

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams? As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

Multiple video & audio feeds from different streamers. The reason why I ask is that I was thinking about using this as a centralised low-latency "cleanfeed" (that remote talent accesses) for some live video production work which sometimes involves multiple distinct feeds. There are closed source, enterprise solutions to this but the investment needed is a little too much for my purposes (and wallet). :D
@woodrowbarlow gets what I mean.

+1 here. The ability to host a single instance of this and have multiple producers each send a production feed to the same instance if multiple broadcasts are ongoing with multiple commentators per producer connecting to each of the clean feeds would literally be our drop in replacement for Mixer. Would also mean for our large scale events where we want to have as many remote camera operators as possible, one instance of this project could allow us to bring in multiple 1080p60 streams with minimal latency for broadcasting purposes.

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams? As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

Multiple video & audio feeds from different streamers. The reason why I ask is that I was thinking about using this as a centralised low-latency "cleanfeed" (that remote talent accesses) for some live video production work which sometimes involves multiple distinct feeds. There are closed source, enterprise solutions to this but the investment needed is a little too much for my purposes (and wallet). :D
@woodrowbarlow gets what I mean.

+1 here. The ability to host a single instance of this and have multiple producers each send a production feed to the same instance if multiple broadcasts are ongoing with multiple commentators per producer connecting to each of the clean feeds would literally be our drop in replacement for Mixer. Would also mean for our large scale events where we want to have as many remote camera operators as possible, one instance of this project could allow us to bring in multiple 1080p60 streams with minimal latency for broadcasting purposes.

Lets not forget about bandwidth here though!

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams? As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

Multiple video & audio feeds from different streamers. The reason why I ask is that I was thinking about using this as a centralised low-latency "cleanfeed" (that remote talent accesses) for some live video production work which sometimes involves multiple distinct feeds. There are closed source, enterprise solutions to this but the investment needed is a little too much for my purposes (and wallet). :D
@woodrowbarlow gets what I mean.

+1 here. The ability to host a single instance of this and have multiple producers each send a production feed to the same instance if multiple broadcasts are ongoing with multiple commentators per producer connecting to each of the clean feeds would literally be our drop in replacement for Mixer. Would also mean for our large scale events where we want to have as many remote camera operators as possible, one instance of this project could allow us to bring in multiple 1080p60 streams with minimal latency for broadcasting purposes.

Lets not forget about bandwidth here though!

I see this comment from you (@GRVYDEV ) in #16:

This is the reason that I want to keep the ingest decoupled from the WebRTC broadcast though as someone could easily swap another ingest in as long as it outputs RTP packets.

Which makes perfect sense to me and implies that you would be more interested in adding an API between ingest and webrtc than you would be in combining them -- if going this route at all, that is.

I love the idea of multiple channels HOWEVER there are a lot of challenges to overcome but I am willing to support if people are willing to help. My initial hesitation is due to the time it would take to implement this by myself however I have always planned to support this in the future. If you look here you can see that I want the ingest to relay on the loopback interface. I feel as if this would make it easier to control but I also like the idea of an API between ingest and webrtc services which could easily be done via websockets on the loopback interface (although im not sure where rust support for websockets is at). I am definitely interested in discussing this further!

I see this comment from you (@GRVYDEV ) in #16:

This is the reason that I want to keep the ingest decoupled from the WebRTC broadcast though as someone could easily swap another ingest in as long as it outputs RTP packets.

Which makes perfect sense to me and implies that you would be more interested in adding an API between ingest and webrtc than you would be in combining them -- if going this route at all, that is.

I love the idea of multiple channels HOWEVER there are a lot of challenges to overcome but I am willing to support if people are willing to help. My initial hesitation is due to the time it would take to implement this by myself however I have always planned to support this in the future. If you look here you can see that I want the ingest to relay on the loopback interface. I feel as if this would make it easier to control but I also like the idea of an API between ingest and webrtc services which could easily be done via websockets on the loopback interface (although im not sure where rust support for websockets is at). I am definitely interested in discussing this further!

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams? As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

Multiple video & audio feeds from different streamers. The reason why I ask is that I was thinking about using this as a centralised low-latency "cleanfeed" (that remote talent accesses) for some live video production work which sometimes involves multiple distinct feeds. There are closed source, enterprise solutions to this but the investment needed is a little too much for my purposes (and wallet). :D
@woodrowbarlow gets what I mean.

+1 here. The ability to host a single instance of this and have multiple producers each send a production feed to the same instance if multiple broadcasts are ongoing with multiple commentators per producer connecting to each of the clean feeds would literally be our drop in replacement for Mixer. Would also mean for our large scale events where we want to have as many remote camera operators as possible, one instance of this project could allow us to bring in multiple 1080p60 streams with minimal latency for broadcasting purposes.

Lets not forget about bandwidth here though!

True! To explain the request a bit more, bandwidth limitations are actually why this is such a game changer for some of our team! While some of our producers have high upload speeds, others have more limited bandwidth to use. After Mixer shut down, we had to move to more peer-to-peer based solutions as most server based solutions were commercial in nature and being honest, well beyond our budget to use. This means that some of our producers actually use more bandwidth pushing out multiple individual peer-to-peer streams than what they can use to push our broadcasts to their respective platforms, so this will help out even our team that have 2 ISPs to try and workaround this cap. Really love this project, early days but I'm excited about its future!

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams? As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

Multiple video & audio feeds from different streamers. The reason why I ask is that I was thinking about using this as a centralised low-latency "cleanfeed" (that remote talent accesses) for some live video production work which sometimes involves multiple distinct feeds. There are closed source, enterprise solutions to this but the investment needed is a little too much for my purposes (and wallet). :D
@woodrowbarlow gets what I mean.

+1 here. The ability to host a single instance of this and have multiple producers each send a production feed to the same instance if multiple broadcasts are ongoing with multiple commentators per producer connecting to each of the clean feeds would literally be our drop in replacement for Mixer. Would also mean for our large scale events where we want to have as many remote camera operators as possible, one instance of this project could allow us to bring in multiple 1080p60 streams with minimal latency for broadcasting purposes.

Lets not forget about bandwidth here though!

True! To explain the request a bit more, bandwidth limitations are actually why this is such a game changer for some of our team! While some of our producers have high upload speeds, others have more limited bandwidth to use. After Mixer shut down, we had to move to more peer-to-peer based solutions as most server based solutions were commercial in nature and being honest, well beyond our budget to use. This means that some of our producers actually use more bandwidth pushing out multiple individual peer-to-peer streams than what they can use to push our broadcasts to their respective platforms, so this will help out even our team that have 2 ISPs to try and workaround this cap. Really love this project, early days but I'm excited about its future!

@kanki6315 I think you've misunderstood; FTL+RTP+WebRTC can provide sub-second latency, but only if the available bandwidth is sufficient for the feeds you're pushing. Lightspeed doesn't reduce bandwidth consumption. If you're maxing out bandwidth, you'll drop frames across the board and the only fix is to increase bandwidth or decrease stream quality.

@kanki6315 I think you've misunderstood; FTL+RTP+WebRTC can provide sub-second latency, but only if the available bandwidth is sufficient for the feeds you're pushing. Lightspeed doesn't reduce bandwidth consumption. If you're maxing out bandwidth, you'll drop frames across the board and the only fix is to increase bandwidth or decrease stream quality.

@kanki6315 I think you've misunderstood; FTL+RTP+WebRTC can provide sub-second latency, but only if the available bandwidth is sufficient for the feeds you're pushing. Lightspeed doesn't reduce bandwidth consumption. If you're maxing out bandwidth, you'll drop frames across the board and the only fix is to increase bandwidth or decrease stream quality.

Maybe I did - the way I understood it is that the streamer sends the data to the RTC instance with a single stream. Then, each consumer of the stream has a unique WebRTC connection to the RTC instance which is relaying and repeating the incoming stream to each viewer. This means the streamer is only sending data once no matter how many people are connected to the stream.

@kanki6315 I think you've misunderstood; FTL+RTP+WebRTC can provide sub-second latency, but only if the available bandwidth is sufficient for the feeds you're pushing. Lightspeed doesn't reduce bandwidth consumption. If you're maxing out bandwidth, you'll drop frames across the board and the only fix is to increase bandwidth or decrease stream quality.

Maybe I did - the way I understood it is that the streamer sends the data to the RTC instance with a single stream. Then, each consumer of the stream has a unique WebRTC connection to the RTC instance which is relaying and repeating the incoming stream to each viewer. This means the streamer is only sending data once no matter how many people are connected to the stream.

@kanki6315 Oh, it seems I misunderstood your original issue. You are correct. Although, if you want to do anything with the independent streams, like composite them into a single output, you'll need one instance of OBS that takes in all the streams (except I don't think mainline OBS can take in a webrtc stream) and re-streams the final mix to yet another endpoint.

@kanki6315 Oh, it seems I misunderstood your original issue. You are correct. Although, if you want to do anything with the independent streams, like composite them into a single output, you'll need one instance of OBS that takes in all the streams (except I don't think mainline OBS can take in a webrtc stream) and re-streams the final mix to yet another endpoint.

@kanki6315 I think you've misunderstood; FTL+RTP+WebRTC can provide sub-second latency, but only if the available bandwidth is sufficient for the feeds you're pushing. Lightspeed doesn't reduce bandwidth consumption. If you're maxing out bandwidth, you'll drop frames across the board and the only fix is to increase bandwidth or decrease stream quality.

Maybe I did - the way I understood it is that the streamer sends the data to the RTC instance with a single stream. Then, each consumer of the stream has a unique WebRTC connection to the RTC instance which is relaying and repeating the incoming stream to each viewer. This means the streamer is only sending data once no matter how many people are connected to the stream.

Sorry I was super vague haha what I meant is that your bottleneck will be the egress bandwidth of the RTC server but if you had a 10gig nic and you were using this internally then you should be able to support quite a bit of connections!

@kanki6315 I think you've misunderstood; FTL+RTP+WebRTC can provide sub-second latency, but only if the available bandwidth is sufficient for the feeds you're pushing. Lightspeed doesn't reduce bandwidth consumption. If you're maxing out bandwidth, you'll drop frames across the board and the only fix is to increase bandwidth or decrease stream quality.

Maybe I did - the way I understood it is that the streamer sends the data to the RTC instance with a single stream. Then, each consumer of the stream has a unique WebRTC connection to the RTC instance which is relaying and repeating the incoming stream to each viewer. This means the streamer is only sending data once no matter how many people are connected to the stream.

Sorry I was super vague haha what I meant is that your bottleneck will be the egress bandwidth of the RTC server but if you had a 10gig nic and you were using this internally then you should be able to support quite a bit of connections!

@kanki6315 Oh, it seems I misunderstood your original issue. You are correct. Although, if you want to do anything with the independent streams, like composite them into a single feed, you'd need one instance of OBS that takes in all the streams (except I don't think mainline OBS can take in a webrtc stream) and re-streams the final mix to yet another endpoint.

This could be an interesting project in the future!

@kanki6315 Oh, it seems I misunderstood your original issue. You are correct. Although, if you want to do anything with the independent streams, like composite them into a single feed, you'd need one instance of OBS that takes in all the streams (except I don't think mainline OBS can take in a webrtc stream) and re-streams the final mix to yet another endpoint.

This could be an interesting project in the future!

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams? As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

Multiple video & audio feeds from different streamers. The reason why I ask is that I was thinking about using this as a centralised low-latency "cleanfeed" (that remote talent accesses) for some live video production work which sometimes involves multiple distinct feeds. There are closed source, enterprise solutions to this but the investment needed is a little too much for my purposes (and wallet). :D
@woodrowbarlow gets what I mean.

+1 here. The ability to host a single instance of this and have multiple producers each send a production feed to the same instance if multiple broadcasts are ongoing with multiple commentators per producer connecting to each of the clean feeds would literally be our drop in replacement for Mixer. Would also mean for our large scale events where we want to have as many remote camera operators as possible, one instance of this project could allow us to bring in multiple 1080p60 streams with minimal latency for broadcasting purposes.

Lets not forget about bandwidth here though!

True! To explain the request a bit more, bandwidth limitations are actually why this is such a game changer for some of our team! While some of our producers have high upload speeds, others have more limited bandwidth to use. After Mixer shut down, we had to move to more peer-to-peer based solutions as most server based solutions were commercial in nature and being honest, well beyond our budget to use. This means that some of our producers actually use more bandwidth pushing out multiple individual peer-to-peer streams than what they can use to push our broadcasts to their respective platforms, so this will help out even our team that have 2 ISPs to try and workaround this cap. Really love this project, early days but I'm excited about its future!

 May I ask what your company does?

Does this mean multiple video and audio tracks for a single streamer, or is it meant as a suggestion to allow more than one streamer to use the same server with different streams? As for the former, I imagine a livestream with two video tracks where the viewer can change the location and size of the face camera or disable it entirely, and independently change the volume of two or more audio tracks such as game audio, voice, and music.

Multiple video & audio feeds from different streamers. The reason why I ask is that I was thinking about using this as a centralised low-latency "cleanfeed" (that remote talent accesses) for some live video production work which sometimes involves multiple distinct feeds. There are closed source, enterprise solutions to this but the investment needed is a little too much for my purposes (and wallet). :D
@woodrowbarlow gets what I mean.

+1 here. The ability to host a single instance of this and have multiple producers each send a production feed to the same instance if multiple broadcasts are ongoing with multiple commentators per producer connecting to each of the clean feeds would literally be our drop in replacement for Mixer. Would also mean for our large scale events where we want to have as many remote camera operators as possible, one instance of this project could allow us to bring in multiple 1080p60 streams with minimal latency for broadcasting purposes.

Lets not forget about bandwidth here though!

True! To explain the request a bit more, bandwidth limitations are actually why this is such a game changer for some of our team! While some of our producers have high upload speeds, others have more limited bandwidth to use. After Mixer shut down, we had to move to more peer-to-peer based solutions as most server based solutions were commercial in nature and being honest, well beyond our budget to use. This means that some of our producers actually use more bandwidth pushing out multiple individual peer-to-peer streams than what they can use to push our broadcasts to their respective platforms, so this will help out even our team that have 2 ISPs to try and workaround this cap. Really love this project, early days but I'm excited about its future!

 May I ask what your company does?

Both OP and I are part of RaceSpot TV - we are a sim racing broadcaster that primarily does iRacing broadcasts!

Both OP and I are part of RaceSpot TV - we are a sim racing broadcaster that primarily does iRacing broadcasts!

@kanki6315 Oh, it seems I misunderstood your original issue. You are correct. Although, if you want to do anything with the independent streams, like composite them into a single feed, you'd need one instance of OBS that takes in all the streams (except I don't think mainline OBS can take in a webrtc stream) and re-streams the final mix to yet another endpoint.

would this help at all? https://github.com/steveseguin/obsninja

@kanki6315 Oh, it seems I misunderstood your original issue. You are correct. Although, if you want to do anything with the independent streams, like composite them into a single feed, you'd need one instance of OBS that takes in all the streams (except I don't think mainline OBS can take in a webrtc stream) and re-streams the final mix to yet another endpoint.

would this help at all? https://github.com/steveseguin/obsninja

I would like to +1 this feature request and volunteer some time to work on this. Early 2020 I went about setting up my own streaming server and found the landscape to be pretty empty. Your project goes end-to-end, even including a frontend, and is more straightforward and self-contained than anything else out there. This project has a lot of potential, great job!
I've been thinking about what it would take to turn the backend (ingest + webrtc) into a multi-tenant server (can receive multiple streams from multiple origins and send each to a unique webrtc endpoint). It would definitely involve collaboration between ingest and webrtc, in the form of sharing config and communicating events to each other.
In other words, I'm imagining a server that could be configured something like this, where you explicitly define each endpoint:
[server]
# the websocket port
webrtc-port = 8080
# need to have a "pool" of RTP ports that can be handed out in FTL handshakes
# the backend isn't listening to any of these at first, but when a handshake is finalizing,
# the backend chooses one available port from this pool, marks it in-use, and starts
# listening on that port. when a stream disconnects, need to put its port back into
# the pool.
rtp-port-range-start = 65535
rtp-port-range-end = 65555

[streams]

[streams.default]
# "default" is just the stream name used for logging
# path is used to build the websocket URL. so to view this stream, the frontend will
# open a websocket to http(s)://example.com:8080/websocket
path = "websocket"
# this is the channel id used to derive the stream key. the "server" config section would
# probably need a "hmac" config value, pair those together to generate the stream key.
channel = 123456789

[streams.example]
path = "test"
channel = 987654321

With all the communication between "ingest" and "webrtc" (to open/close UDP for RTP ports, and to start/stop accepting requests at certain websocket URLs, all in response to handshakes), it would be a lot easier if the backend were a single binary. I see that Rust's webrtc implementation is not ready for use, which explains why Go handles those parts. But given the simplicity of the FTL handshaking process, it is conceivable that the Go code could do the handshake as well as its current roles.
Would you consider a PR that subsumes the ingest project into the webrtc project, creating a single Go binary for the entire backend? This would be a preliminary step towards multi-tenent, the next step would probably be to add a configuration system.

This would be very nice. Some thoughts here:
Currently my solution for this problem would be to have multiple instances of Lightspeed up and running on different ports. This would - caused by th fact that I found no possibility to change the ports of the three services - lead me to the usage of docker containers which then could handle the NAT. (As discussed here: #2, bring up an instance for each bundle of ports). But this wouldn't be dynamic, so the number of concurrent users/sessions is limited to the number of prepared and started docker containers. Each user will them have an indiviual react-page. Problem here will then be the Number of ports used by webrtc... Which only will exist in the mulit-docker-container-szenario. If this is one binary which handels webrtc, this problem can be solved (because it would now each session using which port).
If the service would have the possibility to handle mulitple connections or a ports range (every one corresponding to an specific range) this would fix this and would provide a basic multi-user-expierence.
Example of the idea:

On startup of all three services, define number of users (by using an parameter or config, like --user=10)
Then React takes port 80 to 90
Then Ingest Takes 8084 to 8094
Then webrtc Takes 8080 to 8090 (Collision of the port Range of Ingest! Eventually change ports of one of thoose to a hight numer, like 9084 and up?)

This would lead to a "pack" of port for each service/user. (80,8084,8080 or 84,8088,8084, for example)
Then it would be possible to grab the induvidual streams with ffmpeg, for example and post-process them.
I'm an infrastructure guy, not an coder - so i could contribute in that part. But this is the reason i could only talk about the concept here. I cannot validate the coding-part ;-)

I would like to +1 this feature request and volunteer some time to work on this. Early 2020 I went about setting up my own streaming server and found the landscape to be pretty empty. Your project goes end-to-end, even including a frontend, and is more straightforward and self-contained than anything else out there. This project has a lot of potential, great job!
I've been thinking about what it would take to turn the backend (ingest + webrtc) into a multi-tenant server (can receive multiple streams from multiple origins and send each to a unique webrtc endpoint). It would definitely involve collaboration between ingest and webrtc, in the form of sharing config and communicating events to each other.
In other words, I'm imagining a server that could be configured something like this, where you explicitly define each endpoint:
[server]
# the websocket port
webrtc-port = 8080
# need to have a "pool" of RTP ports that can be handed out in FTL handshakes
# the backend isn't listening to any of these at first, but when a handshake is finalizing,
# the backend chooses one available port from this pool, marks it in-use, and starts
# listening on that port. when a stream disconnects, need to put its port back into
# the pool.
rtp-port-range-start = 65535
rtp-port-range-end = 65555

[streams]

[streams.default]
# "default" is just the stream name used for logging
# path is used to build the websocket URL. so to view this stream, the frontend will
# open a websocket to http(s)://example.com:8080/websocket
path = "websocket"
# this is the channel id used to derive the stream key. the "server" config section would
# probably need a "hmac" config value, pair those together to generate the stream key.
channel = 123456789

[streams.example]
path = "test"
channel = 987654321

With all the communication between "ingest" and "webrtc" (to open/close UDP for RTP ports, and to start/stop accepting requests at certain websocket URLs, all in response to handshakes), it would be a lot easier if the backend were a single binary. I see that Rust's webrtc implementation is not ready for use, which explains why Go handles those parts. But given the simplicity of the FTL handshaking process, it is conceivable that the Go code could do the handshake as well as its current roles.
Would you consider a PR that subsumes the ingest project into the webrtc project, creating a single Go binary for the entire backend? This would be a preliminary step towards multi-tenent, the next step would probably be to add a configuration system.

This would be very nice. Some thoughts here:
Currently my solution for this problem would be to have multiple instances of Lightspeed up and running on different ports. This would - caused by th fact that I found no possibility to change the ports of the three services - lead me to the usage of docker containers which then could handle the NAT. (As discussed here: #2, bring up an instance for each bundle of ports). But this wouldn't be dynamic, so the number of concurrent users/sessions is limited to the number of prepared and started docker containers. Each user will them have an indiviual react-page. Problem here will then be the Number of ports used by webrtc... Which only will exist in the mulit-docker-container-szenario. If this is one binary which handels webrtc, this problem can be solved (because it would now each session using which port).
If the service would have the possibility to handle mulitple connections or a ports range (every one corresponding to an specific range) this would fix this and would provide a basic multi-user-expierence.
Example of the idea:

On startup of all three services, define number of users (by using an parameter or config, like --user=10)
Then React takes port 80 to 90
Then Ingest Takes 8084 to 8094
Then webrtc Takes 8080 to 8090 (Collision of the port Range of Ingest! Eventually change ports of one of thoose to a hight numer, like 9084 and up?)

This would lead to a "pack" of port for each service/user. (80,8084,8080 or 84,8088,8084, for example)
Then it would be possible to grab the induvidual streams with ffmpeg, for example and post-process them.
I'm an infrastructure guy, not an coder - so i could contribute in that part. But this is the reason i could only talk about the concept here. I cannot validate the coding-part ;-)

I would like to +1 this feature request and volunteer some time to work on this. Early 2020 I went about setting up my own streaming server and found the landscape to be pretty empty. Your project goes end-to-end, even including a frontend, and is more straightforward and self-contained than anything else out there. This project has a lot of potential, great job!
I've been thinking about what it would take to turn the backend (ingest + webrtc) into a multi-tenant server (can receive multiple streams from multiple origins and send each to a unique webrtc endpoint). It would definitely involve collaboration between ingest and webrtc, in the form of sharing config and communicating events to each other.
In other words, I'm imagining a server that could be configured something like this, where you explicitly define each endpoint:
[server]
# the websocket port
webrtc-port = 8080
# need to have a "pool" of RTP ports that can be handed out in FTL handshakes
# the backend isn't listening to any of these at first, but when a handshake is finalizing,
# the backend chooses one available port from this pool, marks it in-use, and starts
# listening on that port. when a stream disconnects, need to put its port back into
# the pool.
rtp-port-range-start = 65535
rtp-port-range-end = 65555

[streams]

[streams.default]
# "default" is just the stream name used for logging
# path is used to build the websocket URL. so to view this stream, the frontend will
# open a websocket to http(s)://example.com:8080/websocket
path = "websocket"
# this is the channel id used to derive the stream key. the "server" config section would
# probably need a "hmac" config value, pair those together to generate the stream key.
channel = 123456789

[streams.example]
path = "test"
channel = 987654321

With all the communication between "ingest" and "webrtc" (to open/close UDP for RTP ports, and to start/stop accepting requests at certain websocket URLs, all in response to handshakes), it would be a lot easier if the backend were a single binary. I see that Rust's webrtc implementation is not ready for use, which explains why Go handles those parts. But given the simplicity of the FTL handshaking process, it is conceivable that the Go code could do the handshake as well as its current roles.
Would you consider a PR that subsumes the ingest project into the webrtc project, creating a single Go binary for the entire backend? This would be a preliminary step towards multi-tenent, the next step would probably be to add a configuration system.

This would be very nice. Some thoughts here:
Currently my solution for this problem would be to have multiple instances of Lightspeed up and running on different ports. This would - caused by th fact that I found no possibility to change the ports of the three services - lead me to the usage of docker containers which then could handle the NAT. (As discussed here: #2, bring up an instance for each bundle of ports). But this wouldn't be dynamic, so the number of concurrent users/sessions is limited to the number of prepared and started docker containers. Each user will them have an indiviual react-page. Problem here will then be the Number of ports used by webrtc... Which only will exist in the mulit-docker-container-szenario. If this is one binary which handels webrtc, this problem can be solved (because it would now each session using which port).
If the service would have the possibility to handle mulitple connections or a ports range (every one corresponding to an specific range) this would fix this and would provide a basic multi-user-expierence.
Example of the idea:

On startup of all three services, define number of users (by using an parameter or config, like --user=10)
Then React takes port 80 to 90
Then Ingest Takes 8084 to 8094
Then webrtc Takes 8080 to 8090 (Collision of the port Range of Ingest! Eventually change ports of one of thoose to a hight numer, like 9084 and up?)

This would lead to a "pack" of port for each service/user. (80,8084,8080 or 84,8088,8084, for example)
Then it would be possible to grab the induvidual streams with ffmpeg, for example and post-process them.
I'm an infrastructure guy, not an coder - so i could contribute in that part. But this is the reason i could only talk about the concept here. I cannot validate the coding-part ;-)

So multi streams would be possible with only one instance of Lightspeed if implemented right. The reason you can’t have multiple instances on one server is due to NAT breaking WebRTC and FTL only using port 8084 meaning you can only have 1 ingest server per interface

I would like to +1 this feature request and volunteer some time to work on this. Early 2020 I went about setting up my own streaming server and found the landscape to be pretty empty. Your project goes end-to-end, even including a frontend, and is more straightforward and self-contained than anything else out there. This project has a lot of potential, great job!
I've been thinking about what it would take to turn the backend (ingest + webrtc) into a multi-tenant server (can receive multiple streams from multiple origins and send each to a unique webrtc endpoint). It would definitely involve collaboration between ingest and webrtc, in the form of sharing config and communicating events to each other.
In other words, I'm imagining a server that could be configured something like this, where you explicitly define each endpoint:
[server]
# the websocket port
webrtc-port = 8080
# need to have a "pool" of RTP ports that can be handed out in FTL handshakes
# the backend isn't listening to any of these at first, but when a handshake is finalizing,
# the backend chooses one available port from this pool, marks it in-use, and starts
# listening on that port. when a stream disconnects, need to put its port back into
# the pool.
rtp-port-range-start = 65535
rtp-port-range-end = 65555

[streams]

[streams.default]
# "default" is just the stream name used for logging
# path is used to build the websocket URL. so to view this stream, the frontend will
# open a websocket to http(s)://example.com:8080/websocket
path = "websocket"
# this is the channel id used to derive the stream key. the "server" config section would
# probably need a "hmac" config value, pair those together to generate the stream key.
channel = 123456789

[streams.example]
path = "test"
channel = 987654321

With all the communication between "ingest" and "webrtc" (to open/close UDP for RTP ports, and to start/stop accepting requests at certain websocket URLs, all in response to handshakes), it would be a lot easier if the backend were a single binary. I see that Rust's webrtc implementation is not ready for use, which explains why Go handles those parts. But given the simplicity of the FTL handshaking process, it is conceivable that the Go code could do the handshake as well as its current roles.
Would you consider a PR that subsumes the ingest project into the webrtc project, creating a single Go binary for the entire backend? This would be a preliminary step towards multi-tenent, the next step would probably be to add a configuration system.

This would be very nice. Some thoughts here:
Currently my solution for this problem would be to have multiple instances of Lightspeed up and running on different ports. This would - caused by th fact that I found no possibility to change the ports of the three services - lead me to the usage of docker containers which then could handle the NAT. (As discussed here: #2, bring up an instance for each bundle of ports). But this wouldn't be dynamic, so the number of concurrent users/sessions is limited to the number of prepared and started docker containers. Each user will them have an indiviual react-page. Problem here will then be the Number of ports used by webrtc... Which only will exist in the mulit-docker-container-szenario. If this is one binary which handels webrtc, this problem can be solved (because it would now each session using which port).
If the service would have the possibility to handle mulitple connections or a ports range (every one corresponding to an specific range) this would fix this and would provide a basic multi-user-expierence.
Example of the idea:

On startup of all three services, define number of users (by using an parameter or config, like --user=10)
Then React takes port 80 to 90
Then Ingest Takes 8084 to 8094
Then webrtc Takes 8080 to 8090 (Collision of the port Range of Ingest! Eventually change ports of one of thoose to a hight numer, like 9084 and up?)

This would lead to a "pack" of port for each service/user. (80,8084,8080 or 84,8088,8084, for example)
Then it would be possible to grab the induvidual streams with ffmpeg, for example and post-process them.
I'm an infrastructure guy, not an coder - so i could contribute in that part. But this is the reason i could only talk about the concept here. I cannot validate the coding-part ;-)

So multi streams would be possible with only one instance of Lightspeed if implemented right. The reason you can’t have multiple instances on one server is due to NAT breaking WebRTC and FTL only using port 8084 meaning you can only have 1 ingest server per interface

I would like to +1 this feature request and volunteer some time to work on this. Early 2020 I went about setting up my own streaming server and found the landscape to be pretty empty. Your project goes end-to-end, even including a frontend, and is more straightforward and self-contained than anything else out there. This project has a lot of potential, great job!
I've been thinking about what it would take to turn the backend (ingest + webrtc) into a multi-tenant server (can receive multiple streams from multiple origins and send each to a unique webrtc endpoint). It would definitely involve collaboration between ingest and webrtc, in the form of sharing config and communicating events to each other.
In other words, I'm imagining a server that could be configured something like this, where you explicitly define each endpoint:
[server]
# the websocket port
webrtc-port = 8080
# need to have a "pool" of RTP ports that can be handed out in FTL handshakes
# the backend isn't listening to any of these at first, but when a handshake is finalizing,
# the backend chooses one available port from this pool, marks it in-use, and starts
# listening on that port. when a stream disconnects, need to put its port back into
# the pool.
rtp-port-range-start = 65535
rtp-port-range-end = 65555

[streams]

[streams.default]
# "default" is just the stream name used for logging
# path is used to build the websocket URL. so to view this stream, the frontend will
# open a websocket to http(s)://example.com:8080/websocket
path = "websocket"
# this is the channel id used to derive the stream key. the "server" config section would
# probably need a "hmac" config value, pair those together to generate the stream key.
channel = 123456789

[streams.example]
path = "test"
channel = 987654321

With all the communication between "ingest" and "webrtc" (to open/close UDP for RTP ports, and to start/stop accepting requests at certain websocket URLs, all in response to handshakes), it would be a lot easier if the backend were a single binary. I see that Rust's webrtc implementation is not ready for use, which explains why Go handles those parts. But given the simplicity of the FTL handshaking process, it is conceivable that the Go code could do the handshake as well as its current roles.
Would you consider a PR that subsumes the ingest project into the webrtc project, creating a single Go binary for the entire backend? This would be a preliminary step towards multi-tenent, the next step would probably be to add a configuration system.

This would be very nice. Some thoughts here:
Currently my solution for this problem would be to have multiple instances of Lightspeed up and running on different ports. This would - caused by th fact that I found no possibility to change the ports of the three services - lead me to the usage of docker containers which then could handle the NAT. (As discussed here: #2, bring up an instance for each bundle of ports). But this wouldn't be dynamic, so the number of concurrent users/sessions is limited to the number of prepared and started docker containers. Each user will them have an indiviual react-page. Problem here will then be the Number of ports used by webrtc... Which only will exist in the mulit-docker-container-szenario. If this is one binary which handels webrtc, this problem can be solved (because it would now each session using which port).
If the service would have the possibility to handle mulitple connections or a ports range (every one corresponding to an specific range) this would fix this and would provide a basic multi-user-expierence.
Example of the idea:

On startup of all three services, define number of users (by using an parameter or config, like --user=10)
Then React takes port 80 to 90
Then Ingest Takes 8084 to 8094
Then webrtc Takes 8080 to 8090 (Collision of the port Range of Ingest! Eventually change ports of one of thoose to a hight numer, like 9084 and up?)

This would lead to a "pack" of port for each service/user. (80,8084,8080 or 84,8088,8084, for example)
Then it would be possible to grab the induvidual streams with ffmpeg, for example and post-process them.
I'm an infrastructure guy, not an coder - so i could contribute in that part. But this is the reason i could only talk about the concept here. I cannot validate the coding-part ;-)

So multi streams would be possible with only one instance of Lightspeed if implemented right. The reason you can’t have multiple instances on one server is due to NAT breaking WebRTC and FTL only using port 8084 meaning you can only have 1 ingest server per interface

And if webrtc/FTL identifing the indiviuald stream by its stream keys (in the inpust side) and then providing different ports on the  output/webrtc side? Then alle stream would come in on 8084.

I would like to +1 this feature request and volunteer some time to work on this. Early 2020 I went about setting up my own streaming server and found the landscape to be pretty empty. Your project goes end-to-end, even including a frontend, and is more straightforward and self-contained than anything else out there. This project has a lot of potential, great job!
I've been thinking about what it would take to turn the backend (ingest + webrtc) into a multi-tenant server (can receive multiple streams from multiple origins and send each to a unique webrtc endpoint). It would definitely involve collaboration between ingest and webrtc, in the form of sharing config and communicating events to each other.
In other words, I'm imagining a server that could be configured something like this, where you explicitly define each endpoint:
[server]
# the websocket port
webrtc-port = 8080
# need to have a "pool" of RTP ports that can be handed out in FTL handshakes
# the backend isn't listening to any of these at first, but when a handshake is finalizing,
# the backend chooses one available port from this pool, marks it in-use, and starts
# listening on that port. when a stream disconnects, need to put its port back into
# the pool.
rtp-port-range-start = 65535
rtp-port-range-end = 65555

[streams]

[streams.default]
# "default" is just the stream name used for logging
# path is used to build the websocket URL. so to view this stream, the frontend will
# open a websocket to http(s)://example.com:8080/websocket
path = "websocket"
# this is the channel id used to derive the stream key. the "server" config section would
# probably need a "hmac" config value, pair those together to generate the stream key.
channel = 123456789

[streams.example]
path = "test"
channel = 987654321

With all the communication between "ingest" and "webrtc" (to open/close UDP for RTP ports, and to start/stop accepting requests at certain websocket URLs, all in response to handshakes), it would be a lot easier if the backend were a single binary. I see that Rust's webrtc implementation is not ready for use, which explains why Go handles those parts. But given the simplicity of the FTL handshaking process, it is conceivable that the Go code could do the handshake as well as its current roles.
Would you consider a PR that subsumes the ingest project into the webrtc project, creating a single Go binary for the entire backend? This would be a preliminary step towards multi-tenent, the next step would probably be to add a configuration system.

This would be very nice. Some thoughts here:
Currently my solution for this problem would be to have multiple instances of Lightspeed up and running on different ports. This would - caused by th fact that I found no possibility to change the ports of the three services - lead me to the usage of docker containers which then could handle the NAT. (As discussed here: #2, bring up an instance for each bundle of ports). But this wouldn't be dynamic, so the number of concurrent users/sessions is limited to the number of prepared and started docker containers. Each user will them have an indiviual react-page. Problem here will then be the Number of ports used by webrtc... Which only will exist in the mulit-docker-container-szenario. If this is one binary which handels webrtc, this problem can be solved (because it would now each session using which port).
If the service would have the possibility to handle mulitple connections or a ports range (every one corresponding to an specific range) this would fix this and would provide a basic multi-user-expierence.
Example of the idea:

On startup of all three services, define number of users (by using an parameter or config, like --user=10)
Then React takes port 80 to 90
Then Ingest Takes 8084 to 8094
Then webrtc Takes 8080 to 8090 (Collision of the port Range of Ingest! Eventually change ports of one of thoose to a hight numer, like 9084 and up?)

This would lead to a "pack" of port for each service/user. (80,8084,8080 or 84,8088,8084, for example)
Then it would be possible to grab the induvidual streams with ffmpeg, for example and post-process them.
I'm an infrastructure guy, not an coder - so i could contribute in that part. But this is the reason i could only talk about the concept here. I cannot validate the coding-part ;-)

So multi streams would be possible with only one instance of Lightspeed if implemented right. The reason you can’t have multiple instances on one server is due to NAT breaking WebRTC and FTL only using port 8084 meaning you can only have 1 ingest server per interface

And if webrtc/FTL identifing the indiviuald stream by its stream keys (in the inpust side) and then providing different ports on the  output/webrtc side? Then alle stream would come in on 8084.

I would like to +1 this feature request and volunteer some time to work on this. Early 2020 I went about setting up my own streaming server and found the landscape to be pretty empty. Your project goes end-to-end, even including a frontend, and is more straightforward and self-contained than anything else out there. This project has a lot of potential, great job!
I've been thinking about what it would take to turn the backend (ingest + webrtc) into a multi-tenant server (can receive multiple streams from multiple origins and send each to a unique webrtc endpoint). It would definitely involve collaboration between ingest and webrtc, in the form of sharing config and communicating events to each other.
In other words, I'm imagining a server that could be configured something like this, where you explicitly define each endpoint:
[server]
# the websocket port
webrtc-port = 8080
# need to have a "pool" of RTP ports that can be handed out in FTL handshakes
# the backend isn't listening to any of these at first, but when a handshake is finalizing,
# the backend chooses one available port from this pool, marks it in-use, and starts
# listening on that port. when a stream disconnects, need to put its port back into
# the pool.
rtp-port-range-start = 65535
rtp-port-range-end = 65555

[streams]

[streams.default]
# "default" is just the stream name used for logging
# path is used to build the websocket URL. so to view this stream, the frontend will
# open a websocket to http(s)://example.com:8080/websocket
path = "websocket"
# this is the channel id used to derive the stream key. the "server" config section would
# probably need a "hmac" config value, pair those together to generate the stream key.
channel = 123456789

[streams.example]
path = "test"
channel = 987654321

With all the communication between "ingest" and "webrtc" (to open/close UDP for RTP ports, and to start/stop accepting requests at certain websocket URLs, all in response to handshakes), it would be a lot easier if the backend were a single binary. I see that Rust's webrtc implementation is not ready for use, which explains why Go handles those parts. But given the simplicity of the FTL handshaking process, it is conceivable that the Go code could do the handshake as well as its current roles.
Would you consider a PR that subsumes the ingest project into the webrtc project, creating a single Go binary for the entire backend? This would be a preliminary step towards multi-tenent, the next step would probably be to add a configuration system.

This would be very nice. Some thoughts here:
Currently my solution for this problem would be to have multiple instances of Lightspeed up and running on different ports. This would - caused by th fact that I found no possibility to change the ports of the three services - lead me to the usage of docker containers which then could handle the NAT. (As discussed here: #2, bring up an instance for each bundle of ports). But this wouldn't be dynamic, so the number of concurrent users/sessions is limited to the number of prepared and started docker containers. Each user will them have an indiviual react-page. Problem here will then be the Number of ports used by webrtc... Which only will exist in the mulit-docker-container-szenario. If this is one binary which handels webrtc, this problem can be solved (because it would now each session using which port).
If the service would have the possibility to handle mulitple connections or a ports range (every one corresponding to an specific range) this would fix this and would provide a basic multi-user-expierence.
Example of the idea:

On startup of all three services, define number of users (by using an parameter or config, like --user=10)
Then React takes port 80 to 90
Then Ingest Takes 8084 to 8094
Then webrtc Takes 8080 to 8090 (Collision of the port Range of Ingest! Eventually change ports of one of thoose to a hight numer, like 9084 and up?)

This would lead to a "pack" of port for each service/user. (80,8084,8080 or 84,8088,8084, for example)
Then it would be possible to grab the induvidual streams with ffmpeg, for example and post-process them.
I'm an infrastructure guy, not an coder - so i could contribute in that part. But this is the reason i could only talk about the concept here. I cannot validate the coding-part ;-)

So multi streams would be possible with only one instance of Lightspeed if implemented right. The reason you can’t have multiple instances on one server is due to NAT breaking WebRTC and FTL only using port 8084 meaning you can only have 1 ingest server per interface

And if webrtc/FTL identifing the indiviuald stream by its stream keys (in the inpust side) and then providing different ports on the output/webrtc side? Then alle stream would come in on 8084.

Correct I just need to workout the WebRTC logic on how to handle multiple video and audio tracks in the most efficient manner

I would like to +1 this feature request and volunteer some time to work on this. Early 2020 I went about setting up my own streaming server and found the landscape to be pretty empty. Your project goes end-to-end, even including a frontend, and is more straightforward and self-contained than anything else out there. This project has a lot of potential, great job!
I've been thinking about what it would take to turn the backend (ingest + webrtc) into a multi-tenant server (can receive multiple streams from multiple origins and send each to a unique webrtc endpoint). It would definitely involve collaboration between ingest and webrtc, in the form of sharing config and communicating events to each other.
In other words, I'm imagining a server that could be configured something like this, where you explicitly define each endpoint:
[server]
# the websocket port
webrtc-port = 8080
# need to have a "pool" of RTP ports that can be handed out in FTL handshakes
# the backend isn't listening to any of these at first, but when a handshake is finalizing,
# the backend chooses one available port from this pool, marks it in-use, and starts
# listening on that port. when a stream disconnects, need to put its port back into
# the pool.
rtp-port-range-start = 65535
rtp-port-range-end = 65555

[streams]

[streams.default]
# "default" is just the stream name used for logging
# path is used to build the websocket URL. so to view this stream, the frontend will
# open a websocket to http(s)://example.com:8080/websocket
path = "websocket"
# this is the channel id used to derive the stream key. the "server" config section would
# probably need a "hmac" config value, pair those together to generate the stream key.
channel = 123456789

[streams.example]
path = "test"
channel = 987654321

With all the communication between "ingest" and "webrtc" (to open/close UDP for RTP ports, and to start/stop accepting requests at certain websocket URLs, all in response to handshakes), it would be a lot easier if the backend were a single binary. I see that Rust's webrtc implementation is not ready for use, which explains why Go handles those parts. But given the simplicity of the FTL handshaking process, it is conceivable that the Go code could do the handshake as well as its current roles.
Would you consider a PR that subsumes the ingest project into the webrtc project, creating a single Go binary for the entire backend? This would be a preliminary step towards multi-tenent, the next step would probably be to add a configuration system.

This would be very nice. Some thoughts here:
Currently my solution for this problem would be to have multiple instances of Lightspeed up and running on different ports. This would - caused by th fact that I found no possibility to change the ports of the three services - lead me to the usage of docker containers which then could handle the NAT. (As discussed here: #2, bring up an instance for each bundle of ports). But this wouldn't be dynamic, so the number of concurrent users/sessions is limited to the number of prepared and started docker containers. Each user will them have an indiviual react-page. Problem here will then be the Number of ports used by webrtc... Which only will exist in the mulit-docker-container-szenario. If this is one binary which handels webrtc, this problem can be solved (because it would now each session using which port).
If the service would have the possibility to handle mulitple connections or a ports range (every one corresponding to an specific range) this would fix this and would provide a basic multi-user-expierence.
Example of the idea:

On startup of all three services, define number of users (by using an parameter or config, like --user=10)
Then React takes port 80 to 90
Then Ingest Takes 8084 to 8094
Then webrtc Takes 8080 to 8090 (Collision of the port Range of Ingest! Eventually change ports of one of thoose to a hight numer, like 9084 and up?)

This would lead to a "pack" of port for each service/user. (80,8084,8080 or 84,8088,8084, for example)
Then it would be possible to grab the induvidual streams with ffmpeg, for example and post-process them.
I'm an infrastructure guy, not an coder - so i could contribute in that part. But this is the reason i could only talk about the concept here. I cannot validate the coding-part ;-)

So multi streams would be possible with only one instance of Lightspeed if implemented right. The reason you can’t have multiple instances on one server is due to NAT breaking WebRTC and FTL only using port 8084 meaning you can only have 1 ingest server per interface

And if webrtc/FTL identifing the indiviuald stream by its stream keys (in the inpust side) and then providing different ports on the output/webrtc side? Then alle stream would come in on 8084.

Correct I just need to workout the WebRTC logic on how to handle multiple video and audio tracks in the most efficient manner

I would like to +1 this feature request and volunteer some time to work on this. Early 2020 I went about setting up my own streaming server and found the landscape to be pretty empty. Your project goes end-to-end, even including a frontend, and is more straightforward and self-contained than anything else out there. This project has a lot of potential, great job!
I've been thinking about what it would take to turn the backend (ingest + webrtc) into a multi-tenant server (can receive multiple streams from multiple origins and send each to a unique webrtc endpoint). It would definitely involve collaboration between ingest and webrtc, in the form of sharing config and communicating events to each other.
In other words, I'm imagining a server that could be configured something like this, where you explicitly define each endpoint:
[server]
# the websocket port
webrtc-port = 8080
# need to have a "pool" of RTP ports that can be handed out in FTL handshakes
# the backend isn't listening to any of these at first, but when a handshake is finalizing,
# the backend chooses one available port from this pool, marks it in-use, and starts
# listening on that port. when a stream disconnects, need to put its port back into
# the pool.
rtp-port-range-start = 65535
rtp-port-range-end = 65555

[streams]

[streams.default]
# "default" is just the stream name used for logging
# path is used to build the websocket URL. so to view this stream, the frontend will
# open a websocket to http(s)://example.com:8080/websocket
path = "websocket"
# this is the channel id used to derive the stream key. the "server" config section would
# probably need a "hmac" config value, pair those together to generate the stream key.
channel = 123456789

[streams.example]
path = "test"
channel = 987654321

With all the communication between "ingest" and "webrtc" (to open/close UDP for RTP ports, and to start/stop accepting requests at certain websocket URLs, all in response to handshakes), it would be a lot easier if the backend were a single binary. I see that Rust's webrtc implementation is not ready for use, which explains why Go handles those parts. But given the simplicity of the FTL handshaking process, it is conceivable that the Go code could do the handshake as well as its current roles.
Would you consider a PR that subsumes the ingest project into the webrtc project, creating a single Go binary for the entire backend? This would be a preliminary step towards multi-tenent, the next step would probably be to add a configuration system.

This would be very nice. Some thoughts here:
Currently my solution for this problem would be to have multiple instances of Lightspeed up and running on different ports. This would - caused by th fact that I found no possibility to change the ports of the three services - lead me to the usage of docker containers which then could handle the NAT. (As discussed here: #2, bring up an instance for each bundle of ports). But this wouldn't be dynamic, so the number of concurrent users/sessions is limited to the number of prepared and started docker containers. Each user will them have an indiviual react-page. Problem here will then be the Number of ports used by webrtc... Which only will exist in the mulit-docker-container-szenario. If this is one binary which handels webrtc, this problem can be solved (because it would now each session using which port).
If the service would have the possibility to handle mulitple connections or a ports range (every one corresponding to an specific range) this would fix this and would provide a basic multi-user-expierence.
Example of the idea:

On startup of all three services, define number of users (by using an parameter or config, like --user=10)
Then React takes port 80 to 90
Then Ingest Takes 8084 to 8094
Then webrtc Takes 8080 to 8090 (Collision of the port Range of Ingest! Eventually change ports of one of thoose to a hight numer, like 9084 and up?)

This would lead to a "pack" of port for each service/user. (80,8084,8080 or 84,8088,8084, for example)
Then it would be possible to grab the induvidual streams with ffmpeg, for example and post-process them.
I'm an infrastructure guy, not an coder - so i could contribute in that part. But this is the reason i could only talk about the concept here. I cannot validate the coding-part ;-)

So multi streams would be possible with only one instance of Lightspeed if implemented right. The reason you can’t have multiple instances on one server is due to NAT breaking WebRTC and FTL only using port 8084 meaning you can only have 1 ingest server per interface

And if webrtc/FTL identifing the indiviuald stream by its stream keys (in the inpust side) and then providing different ports on the output/webrtc side? Then alle stream would come in on 8084.

Correct I just need to workout the WebRTC logic on how to handle multiple video and audio tracks in the most efficient manner

But then again if webrtc is using port 8080 and up, the ingest port 8084 would have to be moved "away" (as mentioned for example 9084 to). This would lead to 1004 possible incoming connections/streams... which will be enough, if i think about bandwith. But should'nt this (the port change) be done better earlier then later, so that the impact to existing installations would be as small as possible?
Also: Nice project overall! I've found nothing compareable and my first thought (after I made my research) was: "Why does this not exist?".

I would like to +1 this feature request and volunteer some time to work on this. Early 2020 I went about setting up my own streaming server and found the landscape to be pretty empty. Your project goes end-to-end, even including a frontend, and is more straightforward and self-contained than anything else out there. This project has a lot of potential, great job!
I've been thinking about what it would take to turn the backend (ingest + webrtc) into a multi-tenant server (can receive multiple streams from multiple origins and send each to a unique webrtc endpoint). It would definitely involve collaboration between ingest and webrtc, in the form of sharing config and communicating events to each other.
In other words, I'm imagining a server that could be configured something like this, where you explicitly define each endpoint:
[server]
# the websocket port
webrtc-port = 8080
# need to have a "pool" of RTP ports that can be handed out in FTL handshakes
# the backend isn't listening to any of these at first, but when a handshake is finalizing,
# the backend chooses one available port from this pool, marks it in-use, and starts
# listening on that port. when a stream disconnects, need to put its port back into
# the pool.
rtp-port-range-start = 65535
rtp-port-range-end = 65555

[streams]

[streams.default]
# "default" is just the stream name used for logging
# path is used to build the websocket URL. so to view this stream, the frontend will
# open a websocket to http(s)://example.com:8080/websocket
path = "websocket"
# this is the channel id used to derive the stream key. the "server" config section would
# probably need a "hmac" config value, pair those together to generate the stream key.
channel = 123456789

[streams.example]
path = "test"
channel = 987654321

With all the communication between "ingest" and "webrtc" (to open/close UDP for RTP ports, and to start/stop accepting requests at certain websocket URLs, all in response to handshakes), it would be a lot easier if the backend were a single binary. I see that Rust's webrtc implementation is not ready for use, which explains why Go handles those parts. But given the simplicity of the FTL handshaking process, it is conceivable that the Go code could do the handshake as well as its current roles.
Would you consider a PR that subsumes the ingest project into the webrtc project, creating a single Go binary for the entire backend? This would be a preliminary step towards multi-tenent, the next step would probably be to add a configuration system.

This would be very nice. Some thoughts here:
Currently my solution for this problem would be to have multiple instances of Lightspeed up and running on different ports. This would - caused by th fact that I found no possibility to change the ports of the three services - lead me to the usage of docker containers which then could handle the NAT. (As discussed here: #2, bring up an instance for each bundle of ports). But this wouldn't be dynamic, so the number of concurrent users/sessions is limited to the number of prepared and started docker containers. Each user will them have an indiviual react-page. Problem here will then be the Number of ports used by webrtc... Which only will exist in the mulit-docker-container-szenario. If this is one binary which handels webrtc, this problem can be solved (because it would now each session using which port).
If the service would have the possibility to handle mulitple connections or a ports range (every one corresponding to an specific range) this would fix this and would provide a basic multi-user-expierence.
Example of the idea:

On startup of all three services, define number of users (by using an parameter or config, like --user=10)
Then React takes port 80 to 90
Then Ingest Takes 8084 to 8094
Then webrtc Takes 8080 to 8090 (Collision of the port Range of Ingest! Eventually change ports of one of thoose to a hight numer, like 9084 and up?)

This would lead to a "pack" of port for each service/user. (80,8084,8080 or 84,8088,8084, for example)
Then it would be possible to grab the induvidual streams with ffmpeg, for example and post-process them.
I'm an infrastructure guy, not an coder - so i could contribute in that part. But this is the reason i could only talk about the concept here. I cannot validate the coding-part ;-)

So multi streams would be possible with only one instance of Lightspeed if implemented right. The reason you can’t have multiple instances on one server is due to NAT breaking WebRTC and FTL only using port 8084 meaning you can only have 1 ingest server per interface

And if webrtc/FTL identifing the indiviuald stream by its stream keys (in the inpust side) and then providing different ports on the output/webrtc side? Then alle stream would come in on 8084.

Correct I just need to workout the WebRTC logic on how to handle multiple video and audio tracks in the most efficient manner

But then again if webrtc is using port 8080 and up, the ingest port 8084 would have to be moved "away" (as mentioned for example 9084 to). This would lead to 1004 possible incoming connections/streams... which will be enough, if i think about bandwith. But should'nt this (the port change) be done better earlier then later, so that the impact to existing installations would be as small as possible?
Also: Nice project overall! I've found nothing compareable and my first thought (after I made my research) was: "Why does this not exist?".

You could negotiate multiple SDP offers over the same web socket so you wouldn’t need more than one. Then only thing you would need are enough UDP ports for WebRTC to use

You could negotiate multiple SDP offers over the same web socket so you wouldn’t need more than one. Then only thing you would need are enough UDP ports for WebRTC to use


QR

[Drive]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 42faa32c-446b-0209-4a24-9a29b4921ea1
Version Independent ID: a5f0fc77-a881-df1e-1f49-aa0e555022e0
Content: Office Add-ins platform overview - Office Add-ins
Content Source: docs/overview/office-add-ins.md
Product: non-product-specific
Technology: add-ins
GitHub Login: @o365devx
Microsoft Alias: o365devx

It looks like more information about this bug got lost in posting it.  Can you provide more details?

Hi @iCGSE,
I'm going to close this issue, as there's the issue description is mostly empty. Please comment on the thread with your intended issue and I'll reopen this.
Thanks!


Fixes for Ansible 2.0

Main Problem ist: I'm not yet sure if I can incorporate the changes in a way to support both, ansible 2.0 and 1.9. Since we're using this deployment for our production system here, and are not able to update 2.0 for a while, this is somewhat... challenging ;-)

@maschmann I tried to make sure it was backwards compatible!
There are a few more changes for things I don't use in my own production I believe, also let me update the changes because | exists is required to prevent erroring out!

Either way you need to get it working for 2.0 now it's the main release ;)
Let me know if I can help!

Hi,
I first had to resolve the folder structure problems for the change from sf 2.8 -> 3.x
Now I'll need to build a test environment for ansible 2 here, since we are not able to use it yet, environment-wise. That's also true for lots of my colleagues, since Ansible 2 has some breaking changes and early adopting is not the common path when using Provisioning in a production environment :-)

I've had a look into the include changes: It is possible to do this in the way you've implemented id, but just checking the included task variable to be not empty seems to be a bad idea, since it breaks if e.g. the  null value handling of ansible changes. Would be better to use a file stat instead?


Auctioneer Production MVP Master Issue

┆Issue Number: ENG-823

### Tasks
- [ ] https://github.com/astriaorg/astria/issues/1534
- [ ] https://github.com/astriaorg/astria/issues/1535
- [ ] https://github.com/astriaorg/astria/issues/1536
- [ ] https://github.com/astriaorg/astria/issues/1538
- [ ] https://github.com/astriaorg/astria/issues/1539
- [ ] https://github.com/astriaorg/astria/issues/1541
- [ ] https://github.com/astriaorg/astria/issues/1553
- [ ] https://github.com/astriaorg/astria/issues/1563
- [ ] https://github.com/astriaorg/astria/issues/1766
- [ ] https://github.com/astriaorg/astria/issues/1777
- [ ] https://github.com/astriaorg/astria/issues/1767
- [ ] https://github.com/astriaorg/astria/issues/1790

This issue is stale because it has been open 45 days with no activity. Remove stale label or this issue
be closed in 7 days.

This issue was closed because it was stale


Install without cocoapods podfile

Is this a bug report?
Yes

Have you read the Installation Instructions?
Yes
Environment
	"base64-js": "^1.3.0",
	"buffer": "^5.1.0",
	"jspack": "^0.0.4",
	"mobx": "^4.2.1",
	"mobx-logger": "^0.7.0",
	"mobx-react": "^5.1.2",
	"prop-types": "^15.6.1",
	"react": "^16.3.1",
	"react-native": "^0.55.4",
	"react-native-ble-plx": "^0.9.0",
	"react-native-camera": "^1.1.4",
	"react-native-communications": "^2.2.1",
	"react-native-device-info": "^0.21.5",
	"react-native-elements": "^0.19.1",
	"react-native-exception-handler": "^2.8.9",
	"react-native-image-resizer": "^1.0.0",
	"react-native-maps": "^0.21.0",
	"react-native-vector-icons": "^4.6.0"

Steps to Reproduce

I've had a working installation on android using all of the listed dependencies, and on ios, everything but react-native-maps .. working for some time. Other dependencies were all added using their "manual installation" method - because I don't trust linking generally.
I've never before used cocoapods and in order to follow your installation instructions, had to install it. I've followed your installation instructions to a T and hoped to get my project building with maps finally on ios.
However now I only get "build failed" and a whole bunch of errors regarding my other dependencies. Some I've managed to work through by running clean, yarn and re-installation (manually) again. However the latest issue I cannot seem to fix. It is the same as this.
The reason I'm posting here, is because this was not an issue before going through your installation instructions. The spaghetti of npm+yarn+xcode is pretty damn hard to deal with at the best of times, adding another layer of spaghetti (cocoapods) seems to be the nail in the coffin.
Is there a way to install your project without using cocoapods, and if so please document it. I've tried instructions posted by users in other issue feeds with no luck.

I've managed to solve all my build issues by converting react-native-device-info and react-native-camera over to cocoapods installs.

@pstanton There are open PRs which will provide the use of react-native link

https://github.com/react-community/react-native-maps/pull/2310
https://github.com/react-community/react-native-maps/pull/2396

@thanhdevapp it took me hours of trial and error. this architecture of multiple dependency management and build systems all conflicting is the worst. react-native-ios is worse than react-native-android but android isn't fantastic either. sorry, can't help.

@pstanton thanks you, so now, can't install on ios right?

You can use version ^0.20.1 in the meantime, it works without cocoapods.
That's what I do until they release a new version.

@JanErikFoss how do I use GoogleMaps instead of AppleMaps for iOS in 0.20.1?

@JanErikFoss ugh... How do we use Google Maps for iOS with ^0.20.1. Docs are a bit fussy about that.

@ProteanDev I don't remember much about this issue, but I don't think you'll be able to use Google Maps with 0.20.1 and without cocoapods. From what I can recall, Google Maps support was the big issue that made cocoapods required.

@JanErikFoss even if I already successfully installed GoogleMaps framework manually?

@JanErikFoss even if I already successfully installed GoogleMaps framework manually?

I really don't know enough to give you an answer.

Did anyone find a solution?

@niranjanbprajapati did you find a solution to the Use of undeclared identifier 'AIRGoogleMapOverlay' error? I am facing the same issue

I add to my podfile this pods install this
react-native-maps dependencies
pod 'react-native-maps', :path => '../node_modules/react-native-maps'
pod 'react-native-google-maps', path: rn_maps_path  # Unomment this line if you want to support GoogleMaps on iOS
pod 'GoogleMaps'  # Uncomment this line if you want to support GoogleMaps on iOS
pod 'Google-Maps-iOS-Utils' # Uncomment this line if you want to support GoogleMaps on iOS

end
post_install do |installer|
installer.pods_project.targets.each do |target|
if target.name == 'react-native-google-maps'
target.build_configurations.each do |config|
config.build_settings['CLANG_ENABLE_MODULES'] = 'No'
end
end
if target.name == "React"
target.remove_from_project
end
end
end
import @import GoogleMaps; and add
[GMSServices provideAPIKey:@"Your api key"]; to AppDelegate.m
and run

refer #2573 for the solution to Use of undeclared identifier 'AIRGoogleMapOverlay' error

I got it working on iOS without Podfile, and I think I will document it here.
tl;dr; There is 1 key step missing, which is to add Framework Search Path to AirMaps.xcodeproj.
The installation guide for both Google and react-native-maps are not very clear. I did quite a number of trial and errors and here is my version.

Install Google Maps iOS SDK first. NOTE: whenever you copy your files to Xcode, use Copy items if needed and Create groups. The instruction in the manual is referencing an old version. NOTE AGAIN: I copied the GoogleMap.bundle from the GoogleMaps.framework in my folder (after first copying the 3 frameworks), not from the GoogleMaps.framework in my Downloads. NOTE ONE MORE TIME: Google steps mention to use @import GoogleMaps; but the react-native-maps mention to use #import <GoogleMaps/GoogleMaps.h> in AppDelegate.m. Both seem to be working, but it might be a caching issue on my side. Do trial and error.
Remember to add the snippet below to your Info.plist; this is/was under step 6 of the google Maps iOS SDK installation manual.

<key>LSApplicationQueriesSchemes</key>
<array>
    <string>googlechromes</string>
    <string>comgooglemaps</string>
</array>

The react-native-maps mentioned a postinstall script. That will solve the bug of AirGoogleMaps dir must be added to your xCode project to support GoogleMaps on IOS. For me, i changed REPLACE_ME_RELATIVE_PATH_TO_GOOGLE_MAPS_INSTALL to ios/GoogleMaps/** with the folder structure as shown below:

Add the Framework Search Path under AirMaps.xcodeproj's Target -> Build Settings -> Search Paths. Base on my folder structure, i added $(SRCROOT)/../../../../ios/GoogleMaps and made it recursive. This solved those <GoogleMaps/GoogleMaps.h> file not found errors.

It will be great if I can get some feedback if this works on your machines. I can make a PR to update the docs and maybe the postinstall script to add the framework.

But I'm guessing pod will be the only supported way to install things. What are the problems faced while using it? Could you, guys, comment?

I had some issues with Cocoapods with other libraries when I first started out with RN. I can't really exactly remember but it's along the same line as the OP's comment.

@Vic-L most of those I've seen were to start without Podfile, link libraries, then add Pods, install and get all sort of problems. :D  If you move to Podfile, you have to move everything to it, otherwise react-native link won't work as expected.

I will like to condemn the way I did to get the library working without cocoapods. It is actually changing the files in the AirMap libraries in the node_modules. This will cause dependency problems from git clones and stuff, which I am facing right now trying to use build with BitRise. :(
I guess i will need to use cocoapods.

I found a workaround which does not require fiddling with the
Framework Search Path that will change the files inside node_modules which is not ideal when working in a team.
After running react-native link react-native-maps, check where the Framework Search Path is pointing to in AirMaps.xcodeproj in your project directory. Place all the google maps files into that directory without any further sub directories. Check that physically the files are in the same location as reflected in the file structure shown in Xcode side bar.
tl;dr; the gist is to choose the correct place to place the google map files based on where AirMaps.xcodeproj is looking at by default

I found a workaround which does not require fiddling with the
Framework Search Path that will change the files inside node_modules which is not ideal when working in a team.
After running react-native link react-native-maps, check where the Framework Search Path is pointing to in AirMaps.xcodeproj in your project directory. Place all the google maps files into that directory without any further sub directories. Check that physically the files are in the same location as reflected in the file structure shown in Xcode side bar.
tl;dr; the gist is to choose the correct place to place the google map files based on where AirMaps.xcodeproj is looking at by default. This should result in a messy arrangement of files.

But where do you find the AirMaps.xcodeproj file/folder? Somewhere in node_modules?


chore(RHTAPWATCH-890): Add Alering Rule for konflux_up metric

Added alerting rule and related promql unit tests
for konflux_up metric.
Jira-Url:https://issues.redhat.com/browse/RHTAPWATCH-890

@yftacherzog If interval is not specified then the check-and-test-prometheus-rules is failing.

@yftacherzog If interval is not specified then the check-and-test-prometheus-rules is failing.

So let's make it a 1m as the rest of the rules we have.

@yftacherzog If interval is not specified then the check-and-test-prometheus-rules is failing.

So let's make it a 1m as the rest of the rules we have.

@yftacherzog, Already updated to 1m

@amisstea @yftacherzog Placed the rules in different alert files. Please check again.


Gas cost of executing pure function

The previous version used to tell me the gas cost after invoking a pure function from the GUI.
The new version doesn't do this.
Also, in the REPL there is no "Details" button next to the execution result, only "Debug".

that should be fixed now


Add explicit EditCommand::InsertNewline

Uses the system newline separator
Example in main with Alt+Enter (according to @fdncred cmd-option-enter or shift-option-enter on macOS to get the same key event)

this is with shift-option-enter on macOS


using AsExpandable() cause AsNoTracking doesn't work.

I'm using EF code first, I worked with detached entities and for updating my entities I used GraphDiff (that works with detached entities), so when I want to load my entities I use AsNoTraking():
 _uow.Repository<WorkCenterCapacity>()
                .FindAllQueryable()
                .Where(/*some criteria*/)
                .GroupBy(x => x.WorkCenter.Code)
                .AsNoTracking()
                .ToDictionary(x => x.Key, x => x.FirstOrDefault());
//do some changes
// update using graphDiff

It worked correctly and I was be able to update my detached entity using graphDiff.
But, recently I used LINQKit to use Predicate in my query so I changed above query to:
 _uow.Repository<WorkCenterCapacity>()
                .FindAllQueryable()
                .Where(workCenterListCriteria) //predicate
                .AsExpandable()  //<----------- this line cause AsNoTracking doesn't work
                .GroupBy(x => x.WorkCenter.Code)
                .AsNoTracking()
                .ToDictionary(x => x.Key, x => x.FirstOrDefault());
//do some changes
// update using graphDiff

but now when graphDiff wants to update the loaded WorkCenterCapacity entity I get following Error:

A first chance exception of type 'System.InvalidOperationException' occurred in RefactorThis.GraphDiff.dll

Additional information: GraphDiff supports detached entities only at this time. Please try AsNoTracking() or detach your entites before calling the UpdateGraph method

So it seems that AsExpandable cause AsNotracking doesn't work.

Try to call AsNoTracking first, then AsExpandable. If i remember correctly, AsNoTracking casts the current query to some Entity Framework internal class, which cannot work since it's wrapped by AsExpandable...

Or you can call Configuration.AutoDetectChangesEnabled = false; in your context constructor, so that tracking is always off.

@axelheer :+1: Thank you, I checked it, the problem solved.