Medialook offered us a chance to try an early beta, and we took it! Watch our crazy unplanned experiment in our YouTube channel. We'll blog about the background later. Edit: here is our promised blog post.

Thanks Ice :)

We didn't use vMix call from the same place, so no direct comparison was made. But besides that we noted much bettter video and quality (e.g. 50 fps vs max 30 fps), it is based on NDI. Meaning supporting everything that NDI provides.

Of course the Medialoooks solution (by them called MNSoI) requires more bandwidth, and means that one has to setup mix-minus audio. But my guess is that the code Martin has developed for vMix Call, could be extended to encompass MNSoI call functionality. In other words, just like setting up vMix call, where mix-minus is taken care of. In the end it is, besides development time, it is also a question of licensing costs and if Medialooks will release SKD's (which is their normal way for them).

ps. I updated my original post with a link to our blog post about this experiment.

It certainly supports video and audio, but I'm not sure if it support alpha channel, commands, timecode or tally. I've not tried, it might, but I was under the impression that is it just video/audio right now. But, they have the ability to add those feature if needed since NDI® does make is available.

I know that the Sienna Cloud for NDI solution does support alpha channel transmission along with time stamping of multiple streams to keep them in sync on the far end.

The great thing is that there is now competition for this kind of solution, so we all will benefit.

Kane Peterson
NewTek

You're right, it doesn't support the alpha in a RGBA source, at least not in the beta - I've tested it.

Thanks guys for all your comments!

We've released a new version adding up to 50 Mbit/s streaming and virtual device output (now you can simply select it as a source in vMix thus saving performance by not encoding to NDI).

New download: https://www.medialooks.com/ndi.

We also changed the name of the app and made the first launch more obvious for the user. "MNSoI" wasn't exactly a planned name – although, it's still there in the name of the virtual device (will fix later).

Perhaps I'm missing something here, but NDI already works on a LAN. Are you trying to do everything wireless?

Kane Peterson
NewTek

Hi

it's not clear what you're trying to do, but it's clear to me that it's a very bad idea:

- to try to use pure NDI on a wireless network that you don't own and that is not dedicated to IP Video
- to expect to do such a thing even with NDI|HX
- to use NDI Over Internet services as a solution instead of building a LAN to physically interconnect devices that share a single location

I also believe 2.5 Mbits is far from enough for NDI (or even H.264) to work well...

Guillaume

this is a bad news.



Sorry for the confusion, i know that the BirdDog is Full NDI, i speak in our regular works i think that the birddog studio is better option, where we can uses cat6 cables or sdi. For us the spark is a good alternative for work in a steadycam but we have two wireless uncompressed sdi.



We have make some UltraTrail, where in the finish of ultra (OB truck plus 3-4 cameras and teradek bolt 2000, our CG, videocall) we receive using the WISP network the start line(vmix 2-4 cameras), teradek bonds in 4-5 positions, fixed cameras,start of the medium marathon(vmix 2 cameras), finish of the trail(vmix 2-4 cameras and teradek bolt 2000) I know the problems very well of all the the wireless video type as you can see, uncompressed (teradek bolt) 4g ( teradek bond/liveu LU500) wireless tcp networks, for this type of work NDI|HX or the solution of Medialook in local networks are great solutions and always we are looking for any way to make better and more easy our work.

Hi Gogo

to use NDI it's mandatory to use NDI compatible solutions.
Check : https://www.newtek.com/ndi/applications/

For example one could receive over internet a NDI feed with Medialook's software and pass it to NDI Monitor.

Guillaume

Thanks for trying out and thanks for describing your use case.

The codec works in CBR mode, but we control it depending on the available bandwidth (adaptive bit rate) – so this setting simply defines the maximum bit rate.

We also don't recommend using anything less than 5 Mbps for HD streams.

But how exactly does the problem look when using our app in a local area network (Richard also mentioned this in an earlier post)?