Arv-fake-gv-camera no stream on other client

Using Aravis
1

Thank you so much for this project.

I am building Aravis with MSYS2 MinGW64 on a Windows PC, whose network adapter IP address is 192.168.1.101.

I have encountered several issues. I have analyzed and resolved some of them, but I still need your assistance with the rest.

(1) [Resolved] Error when launching arv-fake-gv-camera: Failed to bind broadcast addresses

Failed to bind Global discovery socket: 255.255.255.255:3956
Failed to bind Subnet discovery socket: 192.168.1.255:3956

Root Cause

GVCP and Control Channels

In the GigE Vision protocol, cameras and control hosts (PCs) communicate via GVCP (GigE Vision Control Protocol), which uses UDP port 3956 by default.

The control host sends various commands (DISCOVERY, register read/write, memory read/write, etc.), and the camera responds with acknowledgment packets. The log entry GVCP address = 192.168.1.101:3956 refers to the endpoint where the fake camera listens for control commands.

Discovery Mechanism & Broadcast Addresses

When the control client does not know a camera’s IP address, it cannot send direct GVCP commands. Instead, it transmits DISCOVERY_CMD packets to broadcast addresses:

  • Global broadcast: 255.255.255.255:3956 — broadcasts to all devices on the local network
  • Subnet broadcast: 192.168.1.255:3956 — broadcasts to all devices on a specific subnet

Cameras must listen to these broadcast addresses to receive discovery requests and reply with their metadata (IP, model, manufacturer, etc.). This explains why the fake camera creates two discovery sockets bound to port 3956 on the global and subnet broadcast addresses respectively.

Why This Works on Linux but Fails on Windows

  • Linux: The OS allows calling bind() on broadcast addresses such as 255.255.255.255 or 192.168.1.255. The kernel automatically joins the socket to the corresponding broadcast reception group.
  • Windows: The Winsock stack design prohibits binding sockets directly to specific broadcast addresses. This limitation cannot be bypassed even with administrator or SYSTEM privileges; the bind() call returns error code WSAEADDRNOTAVAIL (10049).

Correct Implementation

Bind the socket to 0.0.0.0:3956 (INADDR_ANY, meaning all network interfaces), then enable broadcast reception via the SO_BROADCAST socket option using setsockopt. This setup receives all UDP packets sent to any global or subnet broadcast address.

Code Modifications

  1. Modify function signature of _create_and_bind_input_socket (Line 455) : Add enable_broadcast parameter; call setsockopt(SO_BROADCAST) after successful binding.
  2. Modify all four invocation points: Pass FALSE as the 7th argument (existing calls do not require broadcast functionality)
  3. Modify arv_gv_fake_camera_start(Lines 524–552) : Windows-only adjustments: Add SO_REUSEADDR to the GVCP socket; rebind discovery socket to 0.0.0.0:3956 + SO_BROADCAST; remove the subnet discovery socket

(2) [Resolved] arv-viewer detects and connects to physical cameras (Hikvision / TP-Link), but no video stream appears

Root Cause

Aravis receives GigE Vision image streams over standard UDP sockets using the GVSP protocol, which uses dynamic high-range ports (50000 and above). The Windows Firewall blocks inbound UDP traffic to these ports by default.

The native Aravis GVCP control channel uses fixed port 3956, which is pre-allowed by Aravis or other SDKs. As a result, device discovery and control functions normally, but the GVSP image data stream is intercepted by the firewall, leading to these symptoms:

  • Entirely black video feed
  • Screenshot attempts throw a no buffer error
  • Log field n_completed_buffers in stream logs remains 0

Fix

Run this command in PowerShell with administrator privileges:

netsh advfirewall firewall add rule name="Aravis GVSP" dir=in action=allow protocol=udp

(3) [Resolved] Log errors loading Hikvision MVS .cti files on arv-viewer startup

Failed to load GenTL: 'C:\Program Files (x86)\Common Files\MVS\Runtime\Win64_x64\MvProducerGEV.cti'
Failed to load GenTL: 'C:\Program Files (x86)\Common Files\MVS\Runtime\Win64_x64\MvProducerU3V.cti'

Why Aravis Searches for MVS CTI Files

Aravis scans for CTI files due to the environment variable GENICAM_GENTL64_PATH=C:\Program Files (x86)\Common Files\MVS\Runtime\Win64_x64, which is set automatically when installing the Hikvision MVS client software.

Failure Reason

MvProducerGEV.cti and MvProducerU3V.cti depend on other MVS dynamic link libraries (e.g., MvCameraControl.dll). These DLLs reside in the MVS installation directory and are not added to the system PATH. On Windows, LoadLibrary (the underlying function of Aravis’s g_module_open) cannot locate them, triggering a “The specified module could not be found” error.

Theoretical Impact

This error does not interfere with camera operation. Logs confirm Aravis successfully discovers cameras via its native GigE Vision GvInterface implementation; GenTL only serves as an alternative access path.

Suppress the Error Message

export PATH="$PATH:/c/Program Files (x86)/Common Files/MVS/Runtime/Win64_x64"

Note: This step is actually unnecessary for core functionality.

(4) [Unresolved] No image captured after the Hikvision MVS client (running on the same PC) connects to arv-fake-gv-camera

Suspected Root Cause: Windows UDP Loopback Limitations

Both arv-fake-gv-camera and the Hikvision MVS client run on the same Windows machine. The fake camera binds to the local NIC IP 192.168.1.101, and the MVS client also uses this same network adapter address.

Per the GigE Vision standard workflow, the MVS client configures the fake camera to transmit GVSP image data to a target IP and port by writing to the GVCP register GevSCDA (Stream Channel Destination Address).

  • Physical camera to PC: The camera sends UDP packets to the PC’s IP; packets travel over physical cabling through the NIC and Windows network stack to the application.
  • Fake camera to local MVS client: The fake camera sends GVSP UDP packets to port(s) on 192.168.1.101 — the exact same IP assigned to its host physical NIC.

Windows handles reflected UDP loopback traffic differently from Linux. Linux routes such packets back to the receiving application via the lo loopback interface, but Windows does not perform loopback routing for UDP packets addressed to the host’s physical NIC IP. The resulting behavior: GVSP UDP packets sent from 192.168.1.101 to 192.168.1.101 are either sent out over the physical network cable or discarded by Windows. The MVS client stream thread never receives any data and reports a no buffer error.

This raises a question: Why does arv-viewer capture streaming video from the fake camera without issues?