Hi all, I've had my eye on vMix for a while and have passed on the link to some customers of ours who've asked about streaming solutions, and I joined the forum just to reply to this thread (and hi Steadirob, nice to see you here)! :-)
We've had a couple requests recently for recommendations on a product that match the original request from tony marone; a <competing product to vMix, so not mentioned by name since I don't know the forum rules and what's taboo ;-) > doesn't support receiving MPEG Transport Stream and they've asked about using our Cube / Bond or Cube / Link combination in just this type of setup -- bringing in remote feeds from off network (mobile/3G/4G connections) to be mixed at a central location before pushing off to a CDN or streaming service provider.
Just a quick clearing up -- Cube supports RTP in a few different streaming protocols, and also MPEG Transport Stream. Some of these use UDP, some TCP. Summary here:
=== BEGIN boring technical stuff ===RTMP (aka Flash streaming) -- this is a "push" connection where Cube will connect to the CDN and send back audio/video; its configuration is similar to that seen in Adobe Flash Media Live Encoder where you specify a URL (CDN server and port) and stream name. This should work with Flash Media Server, Wowza Media Server, and other products supporting the RTMP streaming protocol. This streaming method is included by default and no special license is required on Cube to use this streaming method. Cube also has a built-in RTMP server that a test client app on the Cube can connect to, but you should be able to pull directly from that -- perhaps directly into vMix since it says it accepts RTMP sources?
RTSP/RTP - this is a "pull" connection where the client/media server/CDN requests the stream from Cube and Cube sends back audio/video. This streaming method is included by default and no special license on Cube is required to use this streaming method. This can be a combination of TCP and UDP-based (RTSP over TCP for control, audio/video sent back to client on UDP ports) or TCP only (aka RTSP Interleaved, in which control, audio and video is all sent from a single outbound client-initiated connection over TCP)
HTTP Live Streaming (aka HLS) -- this is a "pull" connection where Cube acts as a server to provide an HTTP Live stream for the CDN/media server/client to connect to and receive audio/video. This streaming method is included by default and no special license on Cube is required to use this streaming method.
RTP Push (aka "Manual Unicast" in QuickTime Broadcaster terminology) -- this is a "push" connection where you configure Cube with your desired audio/video settings, download an SDP file from Cube and make that available on your CDN or media server. Cube will automatically push audio/video to the CDN/server when powered on without waiting for a request. Any changes made to audio/video settings require you to download a new SDP file from Cube and place it on your CDN/server. This streaming method is unlocked with a free license key available on our forums at
http://forum.teradek.com...topic.php?f=3&t=260. This is UDP-based and doesn't involve the TCP protocol for streaming.
RTSP Announce (aka "Automatic Unicast" in QuickTime Broadcaster terminology) -- this is a "push" connection where Cube will connect to the CDN/server and send back audio/video; no SDP file is required, so settings may be changed on the Cube very easily. This streaming method is unlocked with a free license key available on our forums at
http://forum.teradek.com...wtopic.php?f=3&t=260 . This is a TCP-based protocol.
MPEG Transport Stream -- this is a standards-compliant MPEG Transport Stream with H.264 video compression and MPEG-2 or AAC audio compression. This is a "push" connection where Cube will connect to the CDN/server and send back audio/video on a user-configurable port. This is an optional paid license. This can be UDP-based (for either Unicast stream or Multicast streams) or TCP-based (for communication between Teradek products).
=== END of boring technical stuff ===With our Sputnik server (used with Bond or Link) we can either push out RTMP to a single remote destination, or if the original incoming stream from our products is MPEG Transport Stream then we can push out MPEG Transport Stream (Unicast over UDP or TCP, or Multicast over UDP if Sputnik resides on a local network). We can also accept clients that connect over a TCP socket to pull down MPEG Transport Stream remotely from Sputnik so you can use free players like VLC Media Player to monitor the feed coming through.
If you go direct from Cube you have additional streaming methods; the easiest integration may come from implementing RTP/RTSP as others have recommended but that would require vMix to reach out to the Cube and wouldn't help with tony marone's request, although it may help with the remote ingest that <competing product> can't do even though I see requests on their forums going back at least a year.
Martin, I'd love to have closer integration of our products with vMix so we have an alternative to suggest to Windows-based customers.
Maybe start with the RTMP server functionality built into Cube to see how vMix pulls it in for LAN use since the functionality is already present in both products?
A next step might be RTP/RTSP support so you could work with many of the other security cameras and products using that streaming format, and then perhaps consider MPEG Transport Stream for ingest and output? You could then have your product used to mix multiple cameras and have somebody send out a stream that could be received by inexpensive set top boxes that also accept MPEG Transport Stream.
Lots of possibilities! :-)
