5

Manual entry of NDI source IPs

Our campus network security admins say the will never enable multicast DNS (mDNS) on our network. So we cannot use mDNS to locate NDI sources on our network. We would like to be able to manually specify the IP address of NDI sources. NewTek NDI Access Manager allows you to manually specify remote sources, and those sources are then available to the NewTek NDI Source Monitor, but not Wirecast. We would like something similar for Wirecast.

18replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Certainly make the feature request and we'll investigate implementation. Fill out the form and describe as above.


    Wirecast Feature Request Form

    Reply Like 1
  • I'd also ask them if they can potentially just put your switching equipment and anything that uses NDI on it's own subnet to alleviate whatever perceived net security concerns they have but also make it you can use NDI the way it was designed to be used.

    Some of this just sounds lazy on their end, disabling external mDNS access is a no brainer, but proper firewall rules and only allowing internal mDNS usage should alleviate any "security concerns" on their (or more honestly the campus as a whole)'s end.

    (otherwise the other hackish way of getting around this, especially if you and your ndi devices are in the same room, would be to just put them all on their own router behind NAT and then the router connecting to the campus network, but you run the risk at some schools of violating acceptable use by doing that and not clearing it with someone first)

    Reply Like
  • Christopher Darbro Our application is mobile - the NDI sources would run all over campus and use whatever network jack is provided by the facility/client, so the logistics of constantly reconfiguring the switching equipment is a non-starter for us. And frankly, I don't want our NDI sources to be discoverable. 🙂 I want to tell Wirecast, "Use the NDI source(s) at this IP" and not have to go through all of the broadcast and discovery nonsense.

    Reply Like
  • Makes sense, though if they are dedicated campus owned mobile devices, the campus network should be able to put them and your other equipment on their own subnet/vlan so that you can use mdns cleanly if you wanted and not expose your NDI sources to anyone else.

    I'm only continuing to offer these up as solutions though just because I realize depending on telestreams dev resources/prioritization, in addition to how much newtek has or hasn't opened that capability in their SDK outside of their own apps, can mean it's possible you might not see this solution added to WC soon. (Unless 50 people jumped on board all of a sudden) So if you're looking for a faster solution, what I mentioned might be the way to go. 

    Additionally, I'm always a big proponent of having production networks vlan'd off of the main network in corporate or campus environments. I've set that up here and other places solely so that if someone in a workplace or on campus has some random malware or misconfiguration that causes network issues, hogs bandwidth, etc, that the live production network isnt affected by it, and always has guaranteed upload and links and internal bandwidth that can't be effected by any shenanigans happening elsewhere on the corporate/campus networks.

    Reply Like
  • Reply Like
  • Hi CraigS

     

    Christopher Darbro said:
    I'm always a big proponent of having production networks vlan'd off of the main network in corporate or campus environments.
    CraigS said:
     I'd agree. It's better reliability all around.

     

    But, there is another category of solution where manual IP for NDI might be desirable. As internet services globally get better, the time will come when NDI over public internet will be a possibility. However, mDNS over the internet just doesn't make sense.

    I agree with Brandon Utech 's initial request. It makes sense in the long term to allow manual details to be specified for NDI sources. If not to solve his use case, it will help with the internet source use case.

    GK

    Reply Like
  • Greg Kuhnert Sienna has actually been ahead of the game on this particular use case (ndi over public networks) for a while, check out https://ndi.cloud sometime, I've used it take red carpet camera feeds from new york to a switcher/control room in los angeles, its a great tool.

    Reply Like 1
  • Christopher Darbro 

    Yes. Its a nice cloud product, that contains a feature that could be easily embedded within Wirecast. Specify the remote IP. If it traverses a upnp gateway, open a temporary port map / firewall rule - and it just works on the wirecast side. Yes, there may be a need to open firewall rules on the far end - but thats not a wirecast problem.

    GK

    Reply Like
  • Greg Kuhnert said:
    As internet services globally get better, the time will come when NDI over public internet will be a possibility.

    In addition to SiennaTV's solution...

    Stream NDI over Internet

    So this is being tackled with various approaches.

    Reply Like
  • CraigS said:
    In addition to SiennaTV's solution...

    Stream NDI over Internet

    So this is being tackled with various approaches.

    All of this is good. But I think there is still a good story to tell for Wirecast to natively handle some of this in house. Being able to configure an IP address in a GUI and use it is about a day's coding. Being able to do uPNP firewall configuration would take a bit longer. But all possible. Assuming Brandon Utech  filled in the form as you suggested - lets hope it makes it into a development funnel.

    GK

    Reply Like
  • Greg Kuhnert said:
    Being able to configure an IP address in a GUI and use it is about a day's coding.

     I'm sure you included this information in your feature request.
    If there's overtime...? 😉

    Reply Like
  • Just following up on this. Is this something in the process of working?

    Reply Like
  • Ganbayar Gansukh if you feel out the previously posted feature request form for this feature, we'll send you a case number. You can use the case number in an email and point to this thread and ask for a status update.

    Often the developers don't want to make public that status of certain features but they may tell you privately if you have a case number.

    Reply Like
  • CraigS That would be great. I'd like to be included. Case number would be great.

    Reply Like
  • Ganbayar Gansukh Fill out the form in my first post up top.

    Reply Like
  • Thank you. Done.

    Reply Like
  • Ganbayar Gansukh You're welcome of course.

    Reply Like
  • My tests indicate that specifying extra IP addresses when creating the discovery service does not work for HX devices like PTZ cameras.  My tests also indicate that not having enough bandwidth to stream NDI sources results in dropped connections. Non-HX devices use a great deal of bandwidth so the notion of streaming NDI over the WAN is dubious.

     

    The claim that "being able to configure an IP address in a GUI and use it is about a day's coding" is false but even if it were true, I'm not sure it makes sense to expose this feature given our support obligations.  Are you aware of any other products that have this feature?  I only found that ffmpeg does.

     

    I recently found that there's an existing workaround which may help. The folks at PTZOptics have created a browser-based tool that edits a global JSON file that NDI uses to add extra IP addresses for source discovery.

     

    https://ptzoptics.com/json/

     

    I have not tried this tool and can not promise that it will work for you.  Try it at your own risk.  If you do try it, please let us know how it works for you.  The nice thing about this approach is that it solves the problem for all NDI apps on your machine, not just Wirecast.

    Reply Like
Vote5 Follow
  • 5 Votes
  • 3 wk agoLast active
  • 18Replies
  • 312Views
  • 6 Following