Face swap en tiempo real en un PC local: GPU, FPS, webcam y privacidad
El cambio de cara en directo es un presupuesto de tiempo fijo por fotograma. Entender qué etapa se gasta ese presupuesto separa una vista previa usable de una sucesión de diapositivas.
Respuesta rápida: El face swap en tiempo real ejecuta toda la cadena de detección, intercambio y composición en cada fotograma de la webcam, en tu propio equipo. La tasa de fotogramas la marca la etapa más lenta, la aceleración por hardware es lo que lo hace viable, y la mejora facial suele ser el ajuste que más FPS te cuesta.
Una exportación de vídeo puede tardar lo que haga falta. Una vista previa en directo no. A 30 FPS tienes unos 33 milisegundos por fotograma para capturar, encontrar caras, intercambiarlas, repararlas si procede y mostrarlas. Todo lo que sigue se deriva de esa restricción.
Antes de ponerte en directo
Usa tu propia cara o un retrato para el que tengas permiso claro, y sé transparente sobre que la imagen de cámara está alterada. No uses un face swap en directo para suplantación, fraude, saltarte una verificación de identidad o acoso. Consulta la política de uso responsable.
1. Qué le ocurre a cada fotograma de la webcam
La ruta en directo es un bucle, y cada etapa tiene un coste:
- Captura. Se toma un fotograma de la cámara a la resolución y tasa solicitadas.
- Detección y análisis. Se localizan y describen las caras del fotograma, incluido el embedding que decide quién es quién.
- Asignación. Cada cara detectada se empareja con una cara de origen: un origen predeterminado para todas, o la coincidencia más cercana entre tus identidades asignadas.
- Intercambio. El modelo se ejecuta una vez por pareja origen-destino y el resultado se compone sobre el fotograma.
- Reparación opcional. Si la mejora facial está activa y el runtime la admite en directo, se ejecuta una pasada por cara.
- Visualización. El fotograma final se codifica y se envía a la ventana de la aplicación por una conexión loopback local.
De ahí se derivan dos cosas. Primera, la cadena es por cara y no por fotograma: dos personas en cuadro duplican aproximadamente el trabajo. Segunda, la tasa que ves la marca la etapa más lenta, así que buscar una cámara más rápida no ayuda si el cuello de botella es el enhancer.
2. Captura: lo que la aplicación pide y lo que recibe
Deep Face Cam abre la cámara apuntando a 960×540 a 60 FPS con MJPG y después lee lo que el dispositivo entregó realmente. La petición es deliberada: 540p es una resolución de trabajo razonable en directo, y pedir MJPG al abrir importa en Windows, donde una webcam que se queda en un formato sin comprimir puede quedar limitada por ancho de banda a unos pocos fotogramas por segundo.
En Windows la aplicación prueba primero DirectShow, luego Media Foundation y después un respaldo genérico, porque esos backends enumeran las cámaras en distinto orden y no todos los dispositivos funcionan igual con cada uno. En macOS usa AVFoundation con un respaldo genérico.
La aplicación también mide la tasa real de forma empírica en lugar de fiarse del driver, porque el valor informado no es fiable en DirectShow: una cámara que entrega 60 FPS suele declarar 30. Si quieres ver la cifra en vivo, activa Show FPS en el panel de opciones.
3. Execution providers: el ajuste que decide todo lo demás
La inferencia pasa por ONNX Runtime, y el execution provider elegido es el mayor factor individual del rendimiento en directo. El backend detecta lo disponible al arrancar y prefiere, por orden:
| Proveedor | Plataforma | Notas |
|---|---|---|
| CUDA | Windows, GPU NVIDIA | El mejor rendimiento en NVIDIA, pero sensible a la compatibilidad de driver, CUDA y cuDNN. |
| ROCm | Stack de cómputo de AMD | Se prefiere por delante de CoreML y DirectML cuando está presente. |
| CoreML | macOS, Apple silicon | Se usa en lugar de PyTorch MPS; puede repartirse entre CPU, GPU y Neural Engine. |
| DirectML | Windows | Amplia compatibilidad de GPU con NVIDIA, AMD e Intel. |
| CPU | Todas | Máxima compatibilidad, mínima velocidad. Viable para exportar, duro para directo. |
Windows se empaqueta como builds separadas de CPU, DirectML y CUDA a partir de conjuntos de dependencias distintos, así que elegir el instalador correcto forma parte de esta decisión y no es algo que se cambie luego con un interruptor. En Apple silicon la aplicación además escribe archivos de caché CoreML en tu directorio de modelos, por lo que el primer uso de un modelo puede ser más lento que los siguientes.
Conviene recordarlo: la reparación facial en directo se activa cuando el runtime usa CUDA o DirectML. Con otros proveedores la cadena en vivo ejecuta solo el intercambio, mientras que las exportaciones de imagen y vídeo pueden seguir usando cualquier enhancer. Detalles en la guía GFPGAN vs GPEN.
4. Dónde se van tus FPS
Cuando la vista previa va lenta, recorre esta lista en orden. Está ordenada por cuánto tiempo cuesta cada elemento frente a lo fácil que es cambiarlo.
| Factor | Impacto | Primero prueba |
|---|---|---|
| Mejora facial | El mayor. Una restauración completa por cara y fotograma. | Desactívala o baja al modelo de 256. |
| Número de caras | Alto. Intercambio y reparación se ejecutan por cara. | Encuadra para que solo estén las caras necesarias. |
| Execution provider | Alto. Directo solo con CPU es el caso más duro. | Instala la build que corresponde a tu GPU. |
| Resolución de captura | Medio. Afecta al coste de detección y composición. | Mantén la resolución en directo moderada; no es la exportación. |
| Formato de cámara | Medio y a menudo invisible. Un formato sin comprimir puede estrangular al propio dispositivo. | Confirma la tasa real con Show FPS. |
| Otra carga de GPU | Variable. Juegos, codificadores y navegadores compiten por el mismo dispositivo. | Cierra aplicaciones que usen GPU durante la sesión. |
| Límites térmicos | Gradual. Los portátiles reducen frecuencia tras varios minutos. | Juzga los FPS sostenidos, no los primeros treinta segundos. |
Distingue tasa de fotogramas y latencia. Una vista previa puede ir a una tasa cómoda y aun así sentirse retrasada, porque cada fotograma pasa por varias etapas y un búfer. Si lo que molesta es el retardo, reduce trabajo por fotograma y no solo resolución.
Presupuesto por fotograma, resolución de captura y qué anotar
El directo es aritmética antes que ajuste fino. El presupuesto por fotograma lo fija la tasa objetivo, y captura, detección, asignación, intercambio, reparación opcional y visualización tienen que caber dentro.
| Tasa objetivo | Tiempo por fotograma | Queda para detectar, intercambiar y reparar |
|---|---|---|
| 15 FPS | 66.7 ms | ≈ 61 ms |
| 24 FPS | 41.7 ms | ≈ 37 ms |
| 30 FPS | 33.3 ms | ≈ 28 ms |
| 60 FPS | 16.7 ms | ≈ 12 ms |
La tercera columna asume unos 5 ms para captura y visualización. Es una suposición, no una medición en tu equipo: tómala como la forma del problema, no como una especificación.
| Resolución de captura | Píxeles por fotograma | Frente al valor por defecto 960 × 540 |
|---|---|---|
| 640 × 360 | 230,400 | 0.44× |
| 960 × 540 | 518,400 | 1.00× |
| 1280 × 720 | 921,600 | 1.78× |
| 1920 × 1080 | 2,073,600 | 4.00× |
La detección y la composición crecen con los píxeles del fotograma. El intercambio y la reparación crecen con el número de caras. Por eso subir la resolución y añadir una segunda persona te cuestan de dos maneras distintas.
Qué anotar cuando midas
| Campo | Por qué importa |
|---|---|
| Sistema operativo y variante de build | CPU, DirectML y CUDA son builds de Windows distintas; macOS varía por arquitectura. |
| Execution provider | El mayor factor individual, y además decide si hay reparación en directo. |
| GPU y versión de driver | El rendimiento CUDA es sensible a la compatibilidad de driver, CUDA y cuDNN. |
| Resolución de captura | Fija el coste de detección y composición por fotograma. |
| FPS declarados vs medidos | En DirectShow, una cámara que entrega 60 suele declarar 30. |
| Caras en el fotograma | Intercambio y reparación son por cara, así que multiplican el trabajo. |
| Ajuste de mejora | Off / GPEN-256 / GPEN-512 / GFPGAN cambian el coste por cara por diseño. |
| FPS sostenidos tras 5 minutos | Los portátiles limitan por temperatura; los primeros treinta segundos no son la cifra real. |
5. Conseguir un resultado en directo que aguante
El directo perdona menos que un render, porque no puedes volver atrás a arreglar un fotograma. La mayor parte de la calidad viene de lo que preparas antes de empezar:
- Retrato de origen. Nítido, con luz uniforme y cercano al frontal. Las mismas reglas que en vídeo, y aquí pesan más.
- Iluminación. Luz frontal uniforme gana a una ventana brillante a tu espalda. El contraluz es la causa más común de un swap en directo que se rompe.
- Distancia y encuadre. Una cara demasiado pequeña deja menos información a la detección.
- Movimiento. Los giros rápidos y las manos cruzando la cara son los fotogramas que fallan; pruébalos a propósito antes de depender del montaje.
- Espejo. La vista previa puede voltearse en horizontal, lo que cambia cómo se sienten tus movimientos pero no la geometría del resultado.
Con más de una persona ante la cámara, la asignación en directo es una decisión de similitud continua y no un mapeo preanalizado, así que es intrínsecamente menos estable que un vídeo mapeado. La guía multicara explica la diferencia.
6. Qué es una vista previa local y qué no es
Conviene decirlo con claridad, porque es la suposición equivocada más habitual sobre estas herramientas. Deep Face Cam muestra el resultado en su propia ventana de vista previa. No registra un dispositivo de webcam virtual a nivel de sistema, así que Zoom, Discord, OBS y los navegadores no lo ven en su lista de cámaras.
Si necesitas la salida dentro de otra aplicación, ese enrutado tendría que venir de software independiente de captura de pantalla o de ventana, con todas las salvedades de calidad, latencia y plataforma que eso implica. No des por hecho que funciona hasta que hayas probado esa cadena concreta, y recuerda que presentar una imagen de cámara alterada como tu apariencia real en una reunión o en una verificación es exactamente el uso que prohíbe la política de uso responsable.
7. Privacidad: qué se queda en local y qué no
«Local» y «sin conexión» no son la misma afirmación, y la diferencia importa especialmente con una cámara en directo.
- El procesamiento principal es en el equipo. Los fotogramas, el intercambio y la vista previa los gestiona un backend que corre en tu máquina.
- La vista previa viaja por loopback. El backend incluido sirve los fotogramas procesados a la ventana de la aplicación por una conexión local en 127.0.0.1: un canal interno de tu ordenador, no una subida.
- Los modelos se descargan una vez, con confirmación. Los archivos grandes no vienen en el repositorio; se descargan a tu directorio tras confirmar y se verifican contra una suma publicada.
- Sigue habiendo uso de red. Instaladores, descargas de modelos, enlaces de documentación y comprobaciones de actualización usan la red.
- Los archivos generados quedan en disco. Modelos, salidas, temporales y ajustes viven en tu directorio de datos de aplicación por usuario.
La recomendación honesta es la misma para cualquier herramienta que haga esta afirmación: prueba la build exacta que vas a usar, completa la primera descarga de modelos y observa su comportamiento antes de apuntarla a algo sensible. Ver las notas de privacidad.
Resolución de problemas en directo
| Síntoma | Causa probable | Qué comprobar |
|---|---|---|
| La cámara no abre | Otra aplicación retiene el dispositivo, o el backend no encaja. | Cierra otras apps de cámara; en Windows la aplicación va probando DirectShow, Media Foundation y un respaldo genérico. |
| Tasa de captura muy baja | La cámara negoció un formato sin comprimir. | Activa Show FPS y compara con la tasa nominal de la cámara. |
| El enhancer no está disponible en directo | El runtime no es CUDA ni DirectML. | Revisa el proveedor; la mejora sigue funcionando al exportar. |
| La cara se pierde al girar | La detección pierde una cara alejada del frontal. | Mejora luz y encuadre; prueba el rango de movimiento antes de depender de él. |
| Cara equivocada en la persona equivocada | La asignación en directo es por similitud en cada fotograma. | Reduce personas en cuadro o usa el flujo de archivo. |
| Los FPS caen tras unos minutos | Limitación térmica. | Mide FPS sostenidos, no los primeros segundos. |
| La primera ejecución va mucho más lenta | Carga de modelos y, en Apple silicon, generación de caché CoreML. | Calienta una vez y luego mide. |
Preguntas frecuentes
¿Hace falta GPU para el face swap en tiempo real?
Una ruta por CPU puede ejecutar la cadena, pero el directo es donde más importa la aceleración, porque cada fotograma tiene un presupuesto fijo. En Windows existen builds separadas de CPU, DirectML y CUDA por ese motivo; en Apple silicon la aplicación usa el proveedor CoreML.
¿Puedo usarlo como webcam en Zoom, Discord u OBS?
No directamente. La aplicación muestra el resultado en su propia ventana y no registra un dispositivo de cámara virtual del sistema, así que otras aplicaciones no lo verán como entrada de cámara.
¿Por qué mis FPS en directo son menores que los de mi cámara?
Porque la captura es solo la primera etapa. Detección, asignación, intercambio, reparación opcional y visualización deben caber en el mismo presupuesto, y manda la etapa más lenta.
¿Qué resolución debería usar en directo?
Menor que la de exportación. La aplicación apunta a 960×540 por defecto, un punto de trabajo razonable; no hay ventaja en meter 4K por una cadena en tiempo real.
¿El face swap en directo sube mi imagen de cámara?
El procesamiento principal ocurre en tu equipo y la vista previa se mueve por una conexión loopback local. La red sigue usándose para descargas de modelos confirmadas y enlaces, así que revisa el comportamiento de la build que instales.
¿Pueden usarlo dos personas a la vez?
Sí, pero la asignación se decide por similitud en cada fotograma y no a partir de un mapa preanalizado, así que es menos estable que un render mapeado. Trátalo como vista previa.
Configura el directo una vez y luego mídelo
Elige la build que corresponde a tu GPU, activa Show FPS y prueba con el enhancer desactivado antes de decidir qué puede sostener tu equipo.