Tecnología HyperStageX
Un motor de medios y un transporte propios, con los números encima de la mesa
MediaCore decodifica sin ocupar la máquina. HSST lleva el vídeo por redes que pierden paquetes. Publicamos las mediciones completas, incluidos los casos donde perdemos.
MediaCore
Motor de mediosMediaCore es una tubería de medios escrita desde cero: demultiplexado, decodificación, codificación y multiplexado, con los fotogramas residentes en GPU. No es un envoltorio de otra biblioteca. Está diseñado para una cosa concreta: sostener vídeo en directo sin que la CPU se convierta en el cuello de botella.
Coste de CPU
H.264 1080p60 · 1.800 fotogramas · media de 5 pasadas
MediaCore · NVDEC
0.43CPU·s
0.18 núcleos · 0.8% del sistema
FFmpeg · cuda
0.78CPU·s
0.36 núcleos · 1.7% del sistema
FFmpeg · CPU
10.32CPU·s
6.09 núcleos · 27.7% del sistema
Frente a la decodificación por software, MediaCore usa 24 veces menos CPU. Pero la cifra que importa es la otra: frente a la propia ruta GPU de FFmpeg, con el mismo NVDEC decodificando por debajo, usa la mitad. Esa diferencia no la explica el hardware, la explica la tubería — y es la que decide cuántos flujos caben en una máquina.
Por qué
Colas acotadas que rechazan
Ninguna cola crece sin límite. Si está llena, se rechaza el fotograma y queda registrado. Una cola infinita absorbe un pico y lo devuelve después convertido en latencia.
Memoria reservada de antemano
Los pools se reservan enteros al arrancar. En el bucle caliente no hay una sola petición de memoria, así que no hay pausas donde el sistema decide entregarla.
Planificador por plazos
Cada etapa declara su periodo y su plazo, y los incumplimientos se cuentan. El fallo temporal es un dato que se lee, no un síntoma que hay que deducir.
Los fotogramas no bajan a RAM
La salida se queda en memoria de GPU, con el formato y los desplazamientos declarados para quien la consume. Sin viajes de ida y vuelta a la memoria del sistema.
Decodificación, resultados completos
Fotogramas por segundo sostenidos, media de 5 pasadas con enfriamiento entre ellas, con la desviación típica de cada medida. Tiempo de decodificación puro en ambos lados, sin contar el arranque del proceso. Están los siete casos medidos, ganemos o perdamos.
| Caso | MediaCore | FFmpeg cuda | FFmpeg CPU | vs FFmpeg cuda | veces el tiempo real |
|---|---|---|---|---|---|
| H.2641080p60 | 913.7±32.4 | 958.5±14.8 | 943.6±125.1 | -4.7% | 15.2× |
| H.2651080p60 | 1992.3±53.6 | 1898.5±72.4 | 830.3±101.3 | +4.9% | 33.2× |
| AV11080p60 | 1413.6±268.3 | 1079.5±76.6 | 244.0±33.8 | +31.0% | 23.6× |
| VP91080p60 | 1561.1±50.4 | 1611.8±27.3 | 962.6±48.0 | -3.1% | 26.0× |
| HEVC Main104K | 471.9±9.7 | 406.4±42.5 | 198.8±13.5 | +16.0% | 7.9× |
| AV14K | 297.1±3.6 | 290.9±8.2 | 191.5±13.9 | +2.1% | 5.0× |
| ProRes 44441080p60 | 207.1±10.9 | — | 516.7±37.7 | 2.5× slower | 3.5× |
Los siete casos decodificaron el 100% de los fotogramas, sin pérdidas en ninguna pasada.
Uso de GPU
Muestreado con nvidia-smi cada 50 ms durante las mismas ejecuciones. NVDEC es el motor de decodificación dedicado; SM son los núcleos de cómputo, los que también componen. La VRAM es el incremento sobre el reposo.
H.264 1080p60
| NVDEC medio | SM medio | VRAM | |
|---|---|---|---|
| MediaCore | 97.0% | 3.8% | +344 MiB |
| FFmpeg cuda | 94.5% | 5.6% | +271 MiB |
| FFmpeg CPU | — | — | — |
HEVC Main10 4K
| NVDEC medio | SM medio | VRAM | |
|---|---|---|---|
| MediaCore | 63.6% | 17.4% | +1412 MiB |
| FFmpeg cuda | 68.2% | 21.0% | +1041 MiB |
| FFmpeg CPU | — | — | — |
El techo es el chip, no el software
En H.264 los dos motores saturan NVDEC al 94-97%, con picos del 99%. Ninguno puede ir más rápido que el silicio, y por eso la diferencia de fotogramas es pequeña: lo que se compara ahí es la orquestación, no la decodificación.
Decodificar no toca los shaders
Con los núcleos de cómputo al 3,8% en 1080p, la decodificación deja la GPU prácticamente libre. Ese margen es el que HyperStageX usa para componer en Vulkan sobre la misma tarjeta, y es la razón real de decodificar por hardware.
Guarda lo que FFmpeg tira
MediaCore retiene los fotogramas decodificados en GPU, listos para el compositor. FFmpeg, en esta prueba, los descarta. Comparar la memoria de los dos sin más no mide eficiencia: mide qué hace cada uno con el resultado.
VRAM según el presupuesto de retención
MediaCore permite fijar cuántos fotogramas mantiene en GPU. Igualado a un presupuesto comparable al de FFmpeg, la lectura se invierte — y sigue haciendo más trabajo, porque conserva los fotogramas en lugar de descartarlos.
| Configuración | H.264 1080p60 | HEVC Main10 4K |
|---|---|---|
| MediaCore 20/32por defecto | +344 MiB | +1412 MiB |
| MediaCore 8/8 | +212 MiB | +569 MiB |
| MediaCore 4/4 | +193 MiB | +529 MiB |
| FFmpeg cudadescarta los fotogramas | +271 MiB | +1041 MiB |
Ajustado a 8/8 superficies, MediaCore ocupa un 29% menos de VRAM en 1080p y un 49% menos en 4K que FFmpeg, sin pérdida medible de caudal — 520 fps frente a 492 del valor por defecto en 4K.
El valor por defecto sigue siendo 20/32 a propósito. El pool grande no da más caudal medio, da margen en el peor caso: al reducirlo, el mínimo de la ejecución cae de 932 a 833 fps en 1080p. En directo ese margen es justo lo que se busca, así que las cifras ajustadas describen lo que el motor puede hacer cuando la VRAM es el límite, no lo que viene de fábrica.
Dónde perdemos
MediaCore pierde en H.264 (−4,7%) y en VP9 (−3,1%), y en ProRes es 2,5 veces más lento que libprores — el único códec que hemos escrito nosotros y el peor resultado del conjunto. Lo publicamos porque una comparativa que gana en todas las filas significa que alguien eligió las filas.
Requiere GPU NVIDIA
H.264, H.265, AV1 y VP9 se decodifican por NVDEC. No hay decodificador por software para esos formatos, así que sin una GPU NVIDIA compatible MediaCore no los abre. ProRes sí es software nativo. FFmpeg funciona en cualquier CPU y por eso sigue estando dentro de HyperStageX: los dos motores conviven y el usuario elige.
Máquina y método
- CPU
- Intel Core Ultra 9 185H — 16P / 22L
- GPU
- NVIDIA RTX 4060 Laptop — 8 GB — driver 591.44
- RAM
- 31.4 GB
- OS
- Windows 11 build 26200
- FFmpeg
- n7.1.2 (BtbN win64-shared)
- 2026-08-08
Es un portátil, y conviene decirlo: la refrigeración limita los resultados y una estación de trabajo daría cifras distintas. Una tanda anterior cronometraba FFmpeg desde fuera del proceso y a MediaCore desde dentro, lo que cargaba a FFmpeg unos 339 ms de arranque por pasada e inflaba nuestra ventaja. Esas cifras están retiradas; las de esta página son de la medición corregida.
HSST
Transporte seguroHyperStage Secure Transport lleva vídeo sobre UDP por redes que pierden paquetes. Recupera lo perdido, cifra la carga, y si un camino se cae usa el otro. La especificación del protocolo está escrita para que cualquiera pueda implementar un extremo compatible sin leer nuestro código.
Especificación abierta
1.140 líneas con el formato de cada cabecera bit a bit, escritas para implementar un par compatible sin acceso al código fuente.
AES-256-GCM sobre OpenSSL
Cifrado de la carga con cabeceras autenticadas, protección contra repetición con ventana deslizante, y rotación de claves cada 300 segundos derivadas por HKDF.
Recuperación de pérdidas doble
Retransmisión selectiva con NAK, más corrección hacia delante Reed-Solomon que se adapta a la pérdida observada en vez de ir fijada por configuración.
Dos caminos, conmutación sola
Multitrayecto con máquina de estados de conmutación por salud del enlace. Si una ruta se degrada, el tráfico pasa a la otra sin intervención.
Corrección acelerada por GPU
El cálculo de paridad Reed-Solomon puede ejecutarse en CUDA, liberando la CPU en enlaces con pérdida alta donde la corrección deja de ser barata.
API en C, sin dependencias
C11 puro. No arrastra nada del resto del producto: ni FFmpeg, ni C++, ni bibliotecas gráficas. OpenSSL y CUDA son opcionales.
Sobre las cifras de HSST: todavía no publicamos números de latencia ni comparativas contra SRT, RTMP o NDI, porque las mediciones que tenemos son de retardo dentro del proceso y no de extremo a extremo con relojes sincronizados. Cuando existan medidas comparables, se publican aquí igual que las de MediaCore. Y el cifrado, aunque está construido sobre bibliotecas estándar, no ha pasado todavía una revisión externa independiente: hasta que lo haga, no lo presentamos como garantía de seguridad.
SDK para integradores
Estamos preparando MediaCore y HSST para que otras empresas puedan integrarlos en sus propios productos, sin regalías. Si te interesa, escríbenos y te avisamos cuando esté — y nos dices qué plataformas necesitas, que es lo que determina el orden en que salen.
Tu código sigue siendo tuyo
Integrar MediaCore o HSST no te obliga a publicar tu código fuente, ni a abrir tu producto, ni a heredar ninguna cláusula de copyleft. Es la diferencia con las bibliotecas bajo GPL.
Solo pedimos que se diga
La única obligación es indicar que tu producto usa MediaCore o HSST, en los créditos o en los avisos de terceros. Nada más, y sin regalías por nuestra parte.
Las patentes de los códecs, aparte
Las licencias de patente de H.264, H.265 y demás corren por cuenta de quien integra, igual que con FFmpeg o con los SDK de NVIDIA. No cobramos por el motor y tampoco podemos concederte derechos de patente que no son nuestros: son de terceros y se licencian por separado.
El SDK y su licencia todavía se están preparando. Lo de arriba es la intención con la que se está redactando, no el texto final: no tomes decisiones de arquitectura basándote en ello sin escribirnos antes.