For RTMP camera publishing specifically, here is a concrete Red5-side hardening plan based on your current config.
Current baseline in /conf/red5.properties:
- rtmp.ping_interval=1000
- rtmp.max_inactivity=60000
- rtmp.tcp_keepalive=false
- rtmp.receive_buffer_size=262144
- rtmp.max_read_buffer_size=262144
- rtmp.backlog=32
- rtmp.executor.queue_capacity=64
- rtmp.max_packet_size=3145728
Given your logs (inactivity timeout and chunk stream desynchronized), do this in phases:
- Phase 1 (safe, low risk)
- rtmp.max_inactivity=180000 (from 60s to 180s)
- rtmp.ping_interval=5000 (from 1s to 5s)
- rtmp.tcp_keepalive=true
- rtmp.backlog=128 (from 32)
- rtmp.executor.queue_capacity=256 (from 64)
- rtmp.scheduler.pool_size=16 (from 8)
- rtmp.executor.max_pool_size=64 (from 32)
- Phase 2 (if drops still occur)
- rtmp.max_inactivity=300000
- rtmp.receive_buffer_size=524288
- rtmp.max_read_buffer_size=524288
- rtmp.max_packet_size=8388608 (8 MB)
- rtmp.max_handling_time=4000 (from 2000)
- Keep unchanged for now
- rtmp.max_handshake_time=7000 (unless you see legit camera handshakes timing out)
- rtmp.encoder_drop_live_future=false (don’t change for this issue)
Important limitation:
- chunk stream desynchronized means malformed/corrupted RTMP chunks arrived. No safe server setting can “decode through” corrupted chunk boundaries; server will close by design. These changes only reduce false positives and improve tolerance/recovery around stalls and burst conditions.