Raspberry Pi como servidor multimedia: hasta el 4K

Una Raspberry Pi 4 lleva meses funcionando en una estantería y sirve una biblioteca real desde un disco USB. El veredicto está dividido, y no coincide con lo que afirman las guías de compra. Todo depende de una única cuestión: ¿qué parte de tu colección necesita una recodificación antes de llegar a una pantalla?

La placa de la que proceden estas cifras

Las interfaces de códec cambian según el fabricante, y en ocasiones entre dos núcleos del mismo fabricante, así que considera lo que sigue como el informe de una configuración concreta:

1. Una Pi 4 modelo B con 4 GB de memoria, con Armbian de 64 bits basado en Debian 13.
2. Arrancada desde un SSD USB, con la ranura de tarjeta vacía.
3. Una biblioteca en un disco externo NTFS: 2276 archivos de películas, 1583 archivos de episodios y 44 documentales.

Un NAS, una caja Rockchip o una Odroid necesitan su propia medición antes de que confíes en cualquiera de estas cifras. Realiza tus propias mediciones en lugar de extrapolar.

El chip tiene un único codificador, y es el H.264

El BCM2711 incorpora codificación y decodificación por hardware de H.264 mediante la interfaz V4L2 M2M. Este chip no dispone de VAAPI, por mucho que una marca en la casilla «transcodificación por hardware» de una tabla comparativa sugiera lo contrario. El HEVC se limita a la decodificación, y ese decodificador sin estado se controla mediante la API V4L2 Request, en su propio nodo, lo que penaliza considerablemente el rendimiento. La misma carga de 30 segundos permite medir la magnitud de esa diferencia:

Origen	Ruta	Ritmo medido
H.264 1080p	decodificación V4L2, codificación V4L2	aproximadamente 2x el tiempo real
HEVC Main 1080p	decodificación por software, codificación V4L2	1,14x
HEVC Main 1080p	decodificación Request, codificación V4L2	1,78x
HEVC Main10	decodificación Request, conversión de mosaico, codificación V4L2	1,59x
4K Dolby Vision	software en todo el proceso	0,05x

Cualquier valor superior a 1,0 significa que un segundo de película necesita menos de un segundo de procesamiento. La fila del H.264 es la más cómoda, con unos 403 MiB de memoria y la placa a 65,2 °C, y colocar el decodificador Request delante del mismo codificador elevó el HEVC de 1,14x a 1,78x, que constituye todo el argumento a favor de la ruta sin estado. La última fila sirve de advertencia: dos segundos de imagen por cada cuarenta segundos de reloj, una diferencia que ningún ajuste conseguirá recuperar.

Qué hace el servidor cuando la placa no alcanza el ritmo

Una sesión que se retrasa continuamente resulta peor que una sesión que se detiene, porque el espectador soporta un minuto de almacenamiento en búfer para llegar a la misma conclusión. Por eso el servidor vigila su propio ritmo: una codificación dispone de 45 segundos de margen y después tiene que mantener 0,6 del tiempo real. Por debajo de esa cifra, la sesión finaliza con playback.transcode.too_slow, y el cliente lo explica en una frase.

El coste que nunca aparece en una comparación

La lectura de un archivo también representa trabajo. Construir el mapa de fotogramas clave de una película HEVC de 3,3 GB en ese disco USB NTFS necesitó 120 segundos, mientras que la solicitud que espera ese mapa dispone de ocho segundos, de modo que abandona y la sesión transcodifica algo que el cliente podría haber reproducido sin cambios. Cuando el mapa ya existe, construido discretamente en segundo plano, la siguiente sesión de esa película se convierte en una copia directa en la que la búsqueda funciona correctamente.

Subtítulos obtenidos de la voz, en el mismo hardware

Treinta segundos de diálogo en inglés necesitaron unos 114 segundos de transcripción, con un máximo de 755,5 MiB sin archivo de intercambio, y el resultado contenía 14 líneas con un 12,96 por ciento de error de palabras respecto al subtítulo de referencia; las palabras resultan aprovechables, aunque la sincronización se relaja en una placa tan modesta, y por eso la generación de subtítulos debería corresponder a la máquina de la casa que disponga de capacidad libre.

Entonces, ¿es suficiente?

Resulta suficiente cuando la mayor parte de tu colección ya se reproduce sin cambios, una situación que se olvida con frecuencia al comparar potencias de transcodificación. Un cliente nativo acepta un MKV con vídeo HEVC y una pista sin pérdida tal como está guardado, y el servidor pasa la velada entregando bytes: una Pi 4 realiza esa tarea durante todo el día en un enlace gigabit, con unos pocos vatios. Las cinco situaciones que provocan una recodificación merecen una lectura antes de comprar cualquier hardware, porque cuatro de ellas dependen de decisiones que puedes modificar.

La configuración deja de ser suficiente con la 4K y a partir del tercer flujo simultáneo que necesita conversión. Tampoco resistirá con la placa más reciente, puesto que el BCM2712 de la Pi 5 eliminó el codificador H.264 por hardware y cada transcodificación recae sobre el procesador.

Preguntas frecuentes