fix(whep): re-enable RTX retransmission, keep FEC disabled

[srperens]

Summary

Re-enables do-retransmission on whepserversink in the WHEP output block, while keeping do-fec disabled.

Background

PR #216 disabled both FEC and RTX because a 10 Mbit/s stream transmitted ~21 Mbit/s. That doubling came from FEC, which sends proactive redundancy packets constantly regardless of loss. RTX was disabled in the same sweep without being the culprit — it is reactive and costs nothing while no packets are lost; it only resends the exact packets the client NACKs.

Problem

Without RTX, client NACKs go unanswered, so every burst loss escalates to PLI → forced keyframe, leaving the picture broken until the keyframe arrives. Diagnosed on a live viewer session (packet capture on the sender + client-side media stats):

• The sender emitted every RTP packet (zero sequence gaps at the NIC) — loss happened downstream, in bursts correlating with large frames sent at line rate
• Client stats showed fps collapsing from 50 to 3–9 at every loss burst, with nack_count rising uselessly and pli_count incrementing ~1:1 with bursts

Fix verification (live viewer on a lossy path)

Metric	RTX off	RTX on
fps through loss bursts	drops to 3–9	holds 44–50
PLI per loss burst	~1:1	~1:5
RTX bandwidth on clean paths	—	0

Packet capture confirms the RTX stream (separate SSRC, paired payload type) is only active on the flow that actually experiences loss.

Note: RTX repairs loss; it does not create bandwidth. On paths in sustained capacity congestion the underlying fix is lower bitrate / VBV-capped frame sizes, which is follow-up work.

🤖 Generated with Claude Code