View Full Version : NDI Connect Pro , use Mpeg-ts as source

05-03-2016, 01:03 PM
As i start to play with Connect pro today.
What type of Networked sources is it capable of ?
I tried have it listen on a UDP Mpeg-Ts stream, but it didn't play with me.
Are there any deeper documentation of what it may , may not function with ?

I like to achieve udp://@:9910 for example as source.

03-15-2017, 09:54 AM
No replies, eh? Looking to do this myself. There has to be a easy way to use MPEG TS as NDI source, no?

03-15-2017, 10:45 AM
I'm no expert on network stuff, but broadly speaking if you can find a network address that will work in VLC, it will work in Connect.

03-15-2017, 01:25 PM
I'm not 100% sure it will work, but if you choose the JVC IP Camera option in Connect Pro, there is a 'Use UDP' checkbox option. JVC cameras do support a MPEG2-TS/UDP output stream, which is what this option was designed for.

03-20-2017, 05:21 AM
on a other thread I have no answer. I hope you can help here.

You write, all network address that will work in VLC, it will work in Connect. I have check it with many variant but it not work. I have write under "Add New Camera" then "Webstream or File" the same Link as in VLC - nothing, only black. Also my JVC Camera (GY-HM850) not work with Connect. Is there a especially syntax or ... ? With a file on my local computer all works fine.

Best regards,

03-20-2017, 06:55 AM
What does the URL that works in VLC look like?

03-20-2017, 07:09 AM
Hi Steve,

rtmp://"IP"/live/20279324live source is a hardware-encoder
rtsp://"IP":554/stream source is the JVC-camera

03-20-2017, 11:25 AM
I can't account for a difference between VLC and Connect in this respect, inasmuch as they basically use the same engine. Maybe someone in CS or another user can help, sorry.

03-21-2017, 05:44 AM
Just some notes on this topic in case it helps.

rtsp and rtmp are protocols where the receiving end 'requests' the stream from a sender - and this tells the sender where they are.
Certainly in rtsp there is also a negotiation on format, quality etc. Generally the stream will start only when it is requested by a receiver - rtsp also acts like a VCR remote control and can pause and resume a stream.

This is somewhat different to a udp:// or rtp:// where the receiver is essentially depending on the sender to already know their IP address (unicast) or to be using a multicast address. Generally in this case you would need to setup the target address (to push to) in the sending device. The stream will be flowing whether anyone is listening or not. In rtsp, rtp and udp its likely the actual streams are pretty similar (udp is more raw, rtp has extra wrappers and rtsp uses rtp).

in udp the 188 byte transport stream packets are basically just filled into larger UDP packets whilst in rtp there is an additional packetisation layer which provides a bit more metadata about the stream.

rtsp is quite a gnarly negotiation protocol which is poorly implemented in many devices and that might lead to problems negotiating a stream. With UDP there can be situations where the sender sends empty packets (to keep the stream running ?) and some receiving libraries can get stuck on these.

In a recent example we have been playing with, we found that FFMPEG had problems receiving a particular stream whilst VLC was ok with it even though they are basically using the same libAV libraries. So there is potentially a little more to it, and that *might* explain different results in different applications.

Finally, another observation is that sometimes VLC can work better using the format
rather than

of course these both assume that a sender is already pushing UDP packets into this (known) local address.