Ok here is my scenario..
I run an old pc that uses vmix to stream a list input mix a logo over the video stream, another title that shows what is currently playing, anotheer title shows the current server time and another title show what is next and what time it will start..

Works fantastic have been doing it for over 2 years now 24/7 and am very very happy with it... Through the roku network and my website I can get up to 5,000 simultaneous viewers and over 25,000 a day...

So I need to add a new feature...

A friend of mine has a long time running web radio show (trashtalking radio), he recently upon my advice added video to his stream and is using vmix to stream it to two places, FB live and another video streaming service..

What I need to do is have him stream it to my vmix setup in my house.. what I have accomplished so far is a script that watches for a file to exist, when he is ready to broadcast he goes to my website, logs in, and clicks a broadcast button, the webserver creates a textfile saying trashtalking is online. My vmix pc at my home scans for that text file ever 5 seconds, when it finds it the vmix computer runs a script to create an input..

And that is where I am stuck... how can one vmix stream to another vmix? I need his raw feed to be overlayed with my titles and then restreamed to my server...
Can this be done at all?
Also this would be a great way to get 8 or more cameras into a live mix..
For instance as it is now I 2 hardware 4 channel video mixers, two of them have 4 cameras connected to them each one is manned and mixed down to one video source and then connected to the vmix computer and the two streams are mixed down to one stream titles overlayed and sent out to the server and recorded...
It would be so nice to replace the hardware mixers with more vmixes....

I found a program called video transport that does the job well. (Someone posted about it in another thread) I got it from https://www.medialooks.com/video-transport/faq.

For single output single input it works free but puts up a ton of beg screens. It is very expensive with a monthly renewal fee for more then that and to get rid of the beg screens.

I posted it as a suggestion to a new feature here. Just seems pretty easy to add a stream and compatible input to the interface...

Think about the possibilities it would create, unlimited cameras alone is awesome enough I think, no longer dependant on the most expensive hardware, you could use 4 cheap off the shelf computers to mix as many cameras as you want..

But my main use is that it would allow other producers of content to gain easy broadcast paths to my 24/7 channels.. (Which I use vmix to do)

Isn't there a considerable delay in vmix call?
No one else believes it wouldn't be easier to just be able to use rtmp to accomplish this?
a simple rtmp input is basically what I was looking for. Reason for me is that the person connecting to my vmix will be at a remote location. He has limited knowledge of techinal nature as he is a performer. If I could simply have him hit a webpage which would launch the settings on my end through the api it would work. If it more complicated then that for him then it will not work..

So basically, he simply turns on a stream (say stream 2) and streams to me. then goes to the webpage and logs in.. that launches the input on my vmix, making it active and keeping my overlays..
As it stands now I use vmix to stream a channel from lists 24/7.. I want him to interupt the list and stream his content. when he is done with his weekly show he simply logs out of the website which launches a call to the api to put it back to list and active..

As I said, that freeware solution is nice. and it does work. I was looking for a cleaner way and not to have to run another program on each machine..

So I was suggesting an rmtp input capability within vmix..

vMix call leverages WebRTC, Web Real-time Communications. It was designed from that start for bidirectional real-time communication, like video conferencing. So they paid attention to latency.

RTMP was not built for the kind of bidirectional communications where latency matters. OTOH, you may be able to manually tune an RTMP stream to short GOP and small buffers. WebRTC offers no such tuning. It doesn't need it.

If you had the bandwidth you might be able to encode in MJPEG over RTMP. That would remove the GOP size a factor in the link. Would be closest to a local NDI link, but at a lower bitrate.

From webcams we know that 720p30 uncompressed 16 bpp is around 440 mbps. It just fits across a USB 2 link.

Selecting MJPEG encoding can deliver 10:1 compression, so the stream would be around 45 mbps.

If you tinkered with the MJPEG compression quality and had a fat pipe you could try an interesting experiment. That's more than a little esoteric, but it would be fun to try.