OAK-FFC-4P Dual 4K H.265 Streamer

Streams hardware-accelerated dual 4K H.265 video from the OAK-FFC-4P to a local Linux host over raw TCP.

1. Transmitter (Python Host)

• Hardware Limits: Capped at 4K @ 10 FPS, 35 Mbps CBR. ISP and Encoder memory pools are restricted to 1-2 frames to prevent Myriad X MSS RAM overflow.
• Decoupled I/O: Socket handlers run in isolated threads. OS-level network backpressure on one stream cannot block the other or stall the VPU XLink bridge.
• Socket Tuning: TCP_NODELAY is enabled to kill Nagle's algorithm, pushing NAL units instantly instead of batching them.
• Queue Management: VPU output queues are set to maxSize=2, blocking=False to actively drop old frames and cooperate with the low-latency client buffer.

2. Receiver (GStreamer Client)

⚠️ Execution Order: The Python server must be running and listening before executing the client commands, or the OS will reject the connection.

Run in separate terminals for Port 5000 (CAM_A) and 5001 (CAM_D). This command uses VA-API zero-copy with a minimal buffer and Vsync disabled for absolute lowest latency.

# CAM_A
gst-launch-1.0 tcpclientsrc host=127.0.0.1 port=5000 do-timestamp=true ! \
    queue max-size-buffers=2 max-size-bytes=0 max-size-time=0 ! \
    h265parse config-interval=-1 ! \
    vaapih265dec ! \
    glimagesink sync=false async=false

(For CAM_D, duplicate the command and change port=5000 to port=5001).

3. Pipeline Mitigations

• Zero-Copy VRAM: vaapih265dec to glimagesink keeps the decoded frames strictly in GPU memory via DMA-BUF, bypassing the PCIe bus.
• Compositor Bypass: sync=false async=false prevents the sink from locking to the Wayland/X11 display compositor's Vsync clock, unblocking the thread and eliminating frame-wait latency.
• Decoder Lag: config-interval=-1 paired with a tight VPU keyframe interval forces the hardware decoder to latch onto the stream immediately rather than waiting to build a sequence buffer.