Results 1 to 4 of 4

Thread: NDIhx on linux, using the sdk provided binaries

  1. #1
    Registered User
    Join Date
    Sep 2020
    Location
    earth
    Posts
    4

    NDIhx on linux, using the sdk provided binaries

    hello everyone


    my setup:

    Spark Plus 4k
    hardware 1.1.20012
    firmware 1.43.0138
    NDI 4.5.0
    (it has an hdmi input signal that is listed at 1920x1080 on its web admin page)

    Newtork settings:
    NDI connection "default" (not multicast)
    Etherenet: fixed IP, the spark has no internet access by design for security reasons.

    this is plugged into a gigabyte switch.

    in the same switch is plugged a linux computer:

    Linux xxx 5.8.7-arch1-1 #1 SMP PREEMPT Sat, 05 Sep 2020 12:31:32 +0000 x86_64 GNU/Linux
    info: CPU Name: Intel(R) Core(TM) i7-8550U
    info: Physical Cores: 4, Logical Cores: 8
    info: Physical Memory: 15908MB Total

    distro is an archlinux, up-to-date.

    =====
    note : on same network switch i have a windows10 pc, the ndi virtual input on that pc does see the spark 4k so I am assuming the spark is correctly configured, and is in fact sending stuff on the network.
    back to the linux pc
    =====

    installed sdk 4.5.3:

    /usr/lib # ll libndi*
    0 lrwxrwxrwx 1 root root 13 Sep 10 05:56 libndi.so -> ./libndi.so.4
    0 lrwxrwxrwx 1 root root 15 Sep 10 05:52 libndi.so.4 -> libndi.so.4.5.3
    4.5M -rwxr-xr-x 1 root root 4.5M Sep 10 05:52 libndi.so.4.5.3
    /bin # ll ndi-*
    640K -rwxr-xr-x 1 root root 640K Sep 10 05:52 ndi-directory-service
    3.6M -rwxr-xr-x 1 root root 3.6M Sep 10 05:52 ndi-record

    =====

    installed ndiHX driver:

    /usr/lib
    2.9M -rwxr-xr-x 1 root root 2.9M Sep 10 01:38 libndihx.so
    13M -rwxr-xr-x 1 root root 13M Oct 25 2018 libavcodec-ndi.so.58
    60K -rwxr-xr-x 1 root root 57K Oct 25 2018 libavdevice-ndi.so.58
    2.3M -rwxr-xr-x 1 root root 2.3M Oct 25 2018 libavfilter-ndi.so.7
    2.3M -rwxr-xr-x 1 root root 2.3M Oct 25 2018 libavformat-ndi.so.58
    404K -rwxr-xr-x 1 root root 403K Oct 25 2018 libavutil-ndi.so.56
    2.9M -rwxr-xr-x 1 root root 2.9M Dec 22 2018 libndihx.so
    116K -rwxr-xr-x 1 root root 115K Oct 25 2018 libswresample-ndi.so.3
    512K -rwxr-xr-x 1 root root 511K Oct 25 2018 libswscale-ndi.so.5

    ======

    pc can ping the spark just fine

    /bin # ping 192.168.1.101 -c3
    PING 192.168.1.101 (192.168.1.101) 56(84) bytes of data.
    64 bytes from 192.168.1.101: icmp_seq=1 ttl=64 time=0.295 ms
    64 bytes from 192.168.1.101: icmp_seq=2 ttl=64 time=0.415 ms
    64 bytes from 192.168.1.101: icmp_seq=3 ttl=64 time=0.319 ms

    --- 192.168.1.101 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2020ms
    rtt min/avg/max/mdev = 0.295/0.343/0.415/0.051 ms

    there is no firewalling anywhere between the spark and the pc.

    =====

    /bin # ndi-directory-service
    NDI Discovery Service v4.5.3.0
    Copyright (C)2014-2020, NewTek, inc.

    0:00:39 [---------------------------------------|] 0 Sources, 0 Listeners.

    Exiting. Thank you for using me.

    =====
    So i know from the windows10 pc that the spark is working just fine.
    When I try to discover the spark using the sdk provided by newtek binary, said binary does not in fact see the ndiHX stream from the spark plug.



    up until now i was stating facts, and behavior I can reproduce.

    now I am starting with speculations and questions:

    first thing i notice is that ndi-directory-service is not linked to the ndi librairies as far as i can tell:

    /bin % objdump -p ndi-directory-service|grep NEEDED
    NEEDED libm.so.6
    NEEDED libpthread.so.0
    NEEDED libc.so.6
    NEEDED ld-linux-x86-64.so.2

    /bin # ldd -v ndi-directory-service
    linux-vdso.so.1 (0x00007ffff13bb000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f2533a01000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f25339df000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f2533816000)
    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f2533b77000)

    Version information:
    ./ndi-directory-service:
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /usr/lib64/ld-linux-x86-64.so.2
    libm.so.6 (GLIBC_2.2.5) => /usr/lib/libm.so.6
    libpthread.so.0 (GLIBC_2.3.3) => /usr/lib/libpthread.so.0
    libpthread.so.0 (GLIBC_2.12) => /usr/lib/libpthread.so.0
    libpthread.so.0 (GLIBC_2.3.2) => /usr/lib/libpthread.so.0
    libpthread.so.0 (GLIBC_2.2.5) => /usr/lib/libpthread.so.0
    libc.so.6 (GLIBC_2.14) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_2.8) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_2.9) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_2.7) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_2.3) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_2.3.2) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_2.17) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /usr/lib/libc.so.6
    /usr/lib/libm.so.6:
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /usr/lib64/ld-linux-x86-64.so.2
    libc.so.6 (GLIBC_2.4) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_PRIVATE) => /usr/lib/libc.so.6
    /usr/lib/libpthread.so.0:
    ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /usr/lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /usr/lib64/ld-linux-x86-64.so.2
    libc.so.6 (GLIBC_2.14) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_2.32) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_2.3.2) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_2.4) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /usr/lib/libc.so.6
    libc.so.6 (GLIBC_PRIVATE) => /usr/lib/libc.so.6
    /usr/lib/libc.so.6:
    ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /usr/lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /usr/lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /usr/lib64/ld-linux-x86-64.so.2




    So i'm gonna assume it does not have linked ndihx librairy which explains why it cannot pickup the sender that is my spark 4k.

    questions:

    Q1/ are my assumptions right about ndi-directory-service ? it cannot see the ndiHX stuff ?
    ==>if so i highly recommend to newtek thatthe demo binaries, even if they are demos, work flawlessly with the hardware you sell, it is imo the very minimum your customers are expecting. I strongly advise youupdate your sdk binaries so that they do.
    Q1.1/is there any plans on updating demo binaries so they can interact with ndihx ?

    Q2/ will newtek release a linux equivalent of windows ndi virtual input for linux?
    ==>a daemon of some kind that can take an ndihx stream from the network, and expose it localy as an ndi stream (non hx)
    it does not need to be a graphical app, a cmd line app will be just fine:
    example.bin --inputdev="input device name" --inputchannel="input channel name" \
    --outputdevice="output device name" --outputchan="output channel name"
    you can restrict this by having the daemon output only on 127.0.0.1

    that way non hx varients of linux ndi applications can access ndihx stuff.

    Q3/ am icompletely wrong in my previous two questions, and missed something in setting ndi and/or ndihx on my linux computer and that why the ndi compliant application i'm trying to use cannot see the spark? if so, please point me in the right direction..


    thank you for reading



    thank you for reading looking forward to your answers

  2. #2
    Registered User
    Join Date
    Sep 2020
    Location
    earth
    Posts
    4
    so i got a feedback from newtk by mail :
    There might be some misunderstandings about what the ndi-directory-service application is. This application is typically used in network environments where the advertising/discovery method used by NDI is not ideal. NDI sources and receivers need to be configured to use the IP of the machine where the ndi-directory-service is running, but I do not think that this is the problem in your case.

    A real test to see if Spark Plus is discoverable from your Linux machine is to try the NDIlib_Find example that is included in the NDI SDK. This example will run for about a minute, or until you hit CTRL-C, and print the list of NDI sources that it sees on your network whenever a change occurs.


    compiled and run the

    % ./NDIlib_Find
    No change to the sources found.
    No change to the sources found.
    No change to the sources found.
    No change to the sources found.
    No change to the sources found.
    No change to the sources found.
    No change to the sources found.
    No change to the sources found.
    No change to the sources found.
    No change to the sources found.
    No change to the sources found.

    nothing more...

  3. #3
    Registered User
    Join Date
    Sep 2020
    Location
    earth
    Posts
    4
    after a second exchange with the newtek sdk support:

    i was asked to check that the avahi daemon was installed/running.

    mine was not. after a systemctl start avahi-daemon.service

    % ./NDIlib_Find
    Network sources (1 found).
    1. SPARKDEVICE (sparkchannel)

    so everything seems to be working on the part of drivers/libriries.

    i can go up one layer and start harrassing obs devs now

    my thanks to the newtek sdk support.

  4. #4
    Registered User
    Join Date
    Sep 2020
    Location
    earth
    Posts
    4
    i will add this, humbly: the avahi-daemon.service requirement should be documented in the readme.txt of the ndihx drivers, in my humble opinion. (it may be obvious to some, but it may not be so for everybody ^_^ )

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •