「完善」增加h264硬件编码失败的兜底策略

[beargolden]

Problem

In containerized deployment (e.g., Docker on https://www.compshare.cn/), the system attempts to use NVIDIA NVENC (h264_nvenc) for H.264 video encoding. However, due to permission restrictions, av.CodecContext.create('h264_nvenc') raises an OSError (e.g., PermissionError: [Errno 1] Operation not permitted).

The current exception handling only catches _AVError and _AVCodecError, which do not include OSError in newer versions of PyAV (≥10.0). As a result, the fallback to software encoder (libx264) is never triggered, causing WebRTC video transmission to fail completely.

This issue manifests as:

av.error.PermissionError: [Errno 1] Operation not permitted: 'avcodec_open2(h264_nvenc)'

and repeated /webrtc/offer requests from the client.

Solution

Update the exception handling in patched_encode_frame to catch OSError, ValueError, and generic Exception to ensure robust fallback to libx264 when any hardware encoder fails - especially in headless or container environments without NVIDIA NVENC access.

This change maintains full backward compatibility while significantly improving deployment reliability.

Changes

• Modified src/handlers/client/rtc_client/client_handler_rtc.py:
  Replaced narrow exception catch (_AVError, _AVCodecError) with broader (OSError, ValueError, Exception)
  Ensures fallback logic is always triggered on encoder creation/encoding failure

• Removed reliance on _AVError or _AVCodecError

Testing

• Tested in Docker container without NVIDIA NVENC access → successfully falls back to libx264
• Verified end-to-end pipeline: ASR → LLM → TTS → MuseTalk → WebRTC video/audio
• Confirmed stable 20 FPS video output using CPU encoding
• Validated multi-turn dialogue (10+ rounds) with mixed languages (zh/en/ja)
• No regression in environments with working NVENC