Hi everyone!

As some people on the forum already use the teradek cube I'd like to get some insight.

We are looking for a point to point solution and the teradek cube comes to my mind.

However I haven't used anything like that before. I need the transmitter which sends the video signal over a public internet service. So far so good. At the production-point I have the PC running vMix. Do I need the Encoder to receive the video-signal or is it possible to catch the video via the Stream-Input integrated in vMix?

Thanks in advance for your replies.

Fenki

Alright - thank's for the clarification. So it looks like I need the whole set of Encoder and Decoder. We'll arrange some things and will have a look if the budget has room for a Cube. If I need help setting it up I'll gladly come back to you.

Hey Freeze,

Yes it can. I forgot about RTSP. Only used it once!

Maxi

Hi Fenki - There's two basic ways to send from a Cube to vMix - either requires just the one encoder at the camera end:

1. RTSP - you open a 'Stream' input in vMix and provide the address of your Cube, ex 'rtsp://cube-220-12345.local/stream1'. In this mode you are 'pulling' from the Cube into vMix.

2. RTMP (Flash) - you enter the address of a Flash media server into the Cube, ex 'rtmp://myserver.com:1935/appname/streamname', and the Cube 'pushes' to that server once you start streaming on the Cube. In vMix you'd enter the same address for a 'Flash/RTMP' input, and vMix would 'pull' the stream from that intermediate server. It's a two-hop process.

Option 1 is preferred in general - generally less overhead, less complicated, less latency. etc, so go with that if you can. On a local network (Cube and vMix on same subnet) it's probably a no-brainer. Problem would be if the Cube is outside the local subnet. Either technique would need to poke through a firewall somewhere. With RTSP the Cube would have to be accessable from the Internet, and you'd need Dynamic DNS enabled on the Cube's subnet. I think Cube supports Dynamic DNS, though I haven't tried it and don't have one open right now to double-check. The larger problem would probably be configuring port forwarding, especially if you're going through a cellular device that may or may not allow for inbound connections. Worth checking out anyway...

Option 2 would require similar firewall and dynamic DNS work as well, but it'd be on the vMix side, and it's more likely that your production location would be on a traditional network where you have access to the router. The bad side of this is the extra software needed to serve as the intermediary streaming server. This isn't as convoluted as it sounds - you can use Wowza in a limited demo mode for a period, and it's robust and easy to install and use, especially the new version that added an admin GUI. With careful settings it adds about a second to latency, and it wouldn't drag a suitable machine down much. You could instead probably use an Internet-based service like UStream as the intermediary, but the latency would probably be much worse to name just one potential issue. This technique can also work for things like an iPhone/Pad roaming camera - the Wowza iOS app is pretty cool.

In general, Cube works really well with vMix, with automatic re-connections of RTSP now supported with several supporting versions of vMix having gone by. Here's a link to an event ( http://new.livestream.co...tational/videos/47989690 ) that used Cubes for the start and finish cameras at 7 and 10 mbits respectively at 1080i60. The start camera was a consumer HDMI camcorder, while the finish was a low-end prosumer SDI camera. There were two other $100 RTSP fixed cameras (low-end security cameras basically), but there's no comparison for the optics and compression quality of the full rigs. The actual video seen in vMix was much better - LiveStream only supports up to 720p so there was some loss in publishing.

The Cubes are beautiful devices for ease / performance / stability, and there's not a better way I can think of if your camera layout exceeds cable length constraints.

david