webrtc_media_pipeline

WebRTC-side media pipeline over pixelflux (video) and pcmflux (audio).

Owns one display's capture: pixelflux encodes H.264 on its own capture thread, pcmflux encodes Opus on its own audio thread, and both hand zero-copy buffers back into the asyncio loop via call_soon_threadsafe for the transport's produce_data to packetize as RTP. Because RTP senders are live across capture restarts, the pipeline keeps its own monotonic pts clocks (video: 90 kHz wall-clock anchor; audio: an epoch offset over pcmflux's re-zeroing sample clock) so pts never jumps backward.

A running pipeline is the display's media graph; its two captures are started and paused one by one underneath it. start_media_pipeline opens only the captures a consumer asked for, and pause_screen_capture, resume_screen_capture, pause_audio_capture and resume_audio_capture stop and restart each while the pipeline stays running, so a session whose policy starts video or audio off never captures what nobody receives.

Tunables split two ways, mirroring the WebSockets path: rate/quality knobs (bitrate, CRF, framerate, streaming mode, paint-over) apply live through pixelflux's non-blocking update calls, while structural changes (encoder, CPU/GPU, full color, rate-control mode) restart the capture on the live module. Every setter stores its value first so changes made while capture is paused shape the next start.

The pixelflux/pcmflux imports are guarded: plain WebSocket mode and module import must survive their absence, so capture starts raise a clear error instead of the import failing.