Las computadoras de placa única Raspberry Pi son dispositivos notables y hacen cosas notables con cámaras y video. Sin embargo, puede haber bastante latencia involucrada en estas tareas, dependiendo de la placa que se use y de qué se esté haciendo exactamente. Hay que tener todo configurado justo así para alcanzar el máximo rendimiento.

El desarrollador MattKC se enfrentó a este problema en un proyecto personal y hace poco tuvo algo parecido a una revelación.

¿De dónde salía el retardo?

El asunto apareció durante su trabajo clonando el mando del Wii U. La idea era recibir el flujo de video desde la consola Wii U y mostrarlo usando una Raspberry Pi Zero 2W. Tuvo problemas de latencia: había tres cuadros extraños de retardo en la tubería de video que simplemente no se iban.

Ni siquiera funcionó sustituir cuadros de relleno dentro del flujo e ignorarlos al momento de la salida. La latencia seguía ahí. Con el tiempo, MattKC se dio cuenta de que el retardo no tenía que ver con una cantidad determinada de cuadros, sino con tiempo. Unos 50 milisegundos, para ser exactos.

La distinción no es menor. A 60 cuadros por segundo, cada cuadro dura 16,7 milisegundos, así que 50 milisegundos equivalen casi exactamente a tres cuadros. Esa coincidencia aritmética es la que hacía ver el problema como si fuera de cuadros y no de reloj, y es la razón por la que rellenar la tubería con imágenes falsas nunca lo resolvió.

¿Por qué el primer cuadro decide el retardo de todos?

Al profundizar apareció un problema en la forma en que los cuadros entraban y salían del decodificador. El primer cuadro tomaba alrededor de 50 milisegundos en decodificarse, mientras que los siguientes tardaban muchísimo menos, tan poco como 5 milisegundos. Es decir, una diferencia de diez veces entre el arranque y el régimen permanente.

El problema es que el código de MattKC no estaba escrito para tomar los cuadros apenas quedaban listos, así que el retraso inicial se arrastraba hacia adelante durante toda la sesión. El video explica en mayor detalle cómo consultar el decodificador de forma regular ayudó a resolverlo.

El resultado final fue una Raspberry Pi Zero 2W capaz de procesar y mostrar el flujo de video del Wii U tan rápido como lo hacía el mando original de Nintendo.

El contexto de hardware que conviene tener a mano

La placa que hizo el trabajo no es precisamente potente. La Raspberry Pi Zero 2W monta un procesador de cuatro núcleos Cortex-A53 a 1 GHz y 512 MB de memoria, en un formato de 65 por 30 milímetros y a un precio de lista cercano a los 15 dólares antes de impuestos y envío. Que una placa de esa gama iguale la latencia de un periférico diseñado por Nintendo para esa función específica dice más del cuello de botella del software que de la potencia del silicio.

Para quien replique el montaje en Chile, el detalle importante es que ninguna de las mejoras vino de cambiar la placa por una superior. El diagnóstico de latencia por instrumentación de tiempos, midiendo cuánto tarda cada etapa en lugar de contar cuadros, es transferible a cualquier proyecto de video con cámara en Raspberry Pi, desde monitoreo hasta robótica teleoperada, donde 50 milisegundos de retardo son la diferencia entre un control usable y uno inmanejable.

Si el tema resulta interesante, vale la pena volver a revisar dónde empezó el proyecto del mando del Wii U.