Un motor de medios y un transporte propios, con los números encima de la mesa
MediaCore es nuestro motor de medios en GPU, MediaPrep la capa de conversión que decide cuándo usarlo, y HSST transporta vídeo por redes que pierden paquetes. Publicamos las mediciones completas, incluidos los casos en los que MediaCore no va por delante.
MediaCore
Motor de mediosMediaCore es un pipeline de medios escrito desde cero: demux, decodificación, codificación y mux, con los fotogramas residentes en la GPU. Es un motor especializado, no universal: en el portátil medido destaca en AV1 1080p, HEVC 4K Main10 y ProRes 4444, y queda prácticamente empatado con FFmpeg CUDA en el resto de casos medidos.
Dónde destaca
Tres resultados medidos con una ventaja clara. Cada uno conserva su alcance: la cifra de ProRes mide una carga distinta de la tabla de decodificación de abajo.
AV1 1080p60
1,561.52fps
26.03× tiempo real
+64.09%
frente a FFmpeg CUDA
HEVC 4K Main10
489.70fps
8.16× tiempo real
+13.98%
frente a FFmpeg CUDA
ProRes 4444 equivalente
739.44fps
12.32× tiempo real
+188.42%
frente a FFmpeg haciendo la composición alfa + conversión P010 equivalentes
El resultado de ProRes se mide por separado y no forma parte de la tabla de decodificación. Frente al decode nativo de ProRes de FFmpeg a null, que hace menos trabajo, MediaCore también midió +54.35% aun realizando la composición alfa y la conversión P010. La cifra de +188.42% se aplica solo a esta carga de ProRes, no a todos los códecs.
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.
Rendimiento de decodificación en GPU en un portátil RTX 4060
Fotogramas por segundo solo de decodificación: media ± desviación estándar de cinco ejecuciones medidas por caso. Se muestran los seis casos medidos, incluidos aquellos en los que MediaCore queda ligeramente por detrás.
| Caso | MediaCore | FFmpeg CUDA | Diferencia MediaCore |
|---|---|---|---|
| H.264 1080p601,800 fotogramas | 990.37±12.22 | 998.58±4.79 | 0.82% más lento que FFmpeg CUDA — prácticamente empatado |
| H.265 1080p601,800 fotogramas | 2,005.54±86.66 | 2,013.57±19.09 | 0.40% más lento que FFmpeg CUDA — prácticamente empatado |
| AV1 1080p601,800 fotogramas | 1,561.52±44.52 | 951.60±52.00 | 64.09% más rápido que FFmpeg CUDA — por delante |
| VP9 1080p601,800 fotogramas | 1,621.14±21.52 | 1,599.07±46.16 | 1.38% más rápido que FFmpeg CUDA — prácticamente empatado |
| HEVC 4K Main10300 fotogramas | 489.70±16.01 | 429.63±13.31 | 13.98% más rápido que FFmpeg CUDA — por delante |
| AV1 4K300 fotogramas | 299.55±3.56 | 305.11±4.08 | 1.82% más lento que FFmpeg CUDA — prácticamente empatado |
Todas las ejecuciones medidas decodificaron el número de fotogramas esperado.
Máquina y método
- CPU
- Intel Core Ultra 9 185H
- GPU
- NVIDIA GeForce RTX 4060 Laptop GPU — 8,188 MiB
- Driver
- 591.44
- FFmpeg
- n7.1.2-5-g8f77695e65-20251028
- Opciones FFmpeg
-hwaccel cuda -hwaccel_output_format cuda- Fecha
- 2026-09-11
Compilaciones Release, cinco ejecuciones medidas por códec tras un calentamiento descartado, rotando el orden de los códecs y alternando qué motor corría primero. Tiempo de pared solo de decodificación, sin contar el arranque del proceso en ninguno de los dos motores. FFmpeg usó las opciones de arriba, manteniendo su salida en la GPU igual que MediaCore. Todas las ejecuciones medidas decodificaron el número de fotogramas esperado.
ProRes 4444: 8 rondas emparejadas de 300/300 fotogramas, con orden rotativo y una carga equivalente de composición alfa + P010 en ambos motores.
Es un portátil, y estas cifras describen solo esta máquina: la refrigeración, la GPU y el driver condicionan el resultado. No deben extrapolarse a otras GPU.
Dónde no va por delante
En estos casos MediaCore y FFmpeg CUDA están prácticamente empatados: sus intervalos de ±1 desviación estándar se solapan, así que ninguno cuenta como victoria ni como derrota, apunte el signo hacia donde apunte. Publicamos también las filas negativas, porque una comparación que gana todas las filas significa que alguien eligió las filas.
- H.264 1080p60 0.82% más lento que FFmpeg CUDA
- H.265 1080p60 0.40% más lento que FFmpeg CUDA
- VP9 1080p60 1.38% más rápido que FFmpeg CUDA
- AV1 4K 1.82% más lento que FFmpeg CUDA
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. FFmpeg funciona en cualquier CPU y por eso sigue estando dentro de HyperStageX: los dos motores conviven y el usuario elige.
MediaPrep
Capa de conversiónMediaPrep es la capa de conversión que va delante de MediaCore. Usa MediaCore solo para el subconjunto probado y cambia automáticamente a la ruta completa de FFmpeg cuando el archivo necesita normalización, en lugar de descartar en silencio el audio o un paso de conversión.
Cómo se enruta un archivo
- 1
Analiza la fuente
MediaPrep inspecciona el archivo antes de elegir ruta.
- 2
Ruta MediaCore
Solo H.264, H.265/HEVC, AV1 y VP9 de 8 bits SDR, frecuencia constante (CFR), progresivos, píxel cuadrado, sin alfa y con AAC o sin audio.
- 3
Ruta FFmpeg completa
HDR/10 bits, alfa, frecuencia variable (VFR), entrelazado, anamórfico, audio no AAC, Hap y códecs no verificados pasan aquí automáticamente.
- 4
Valida y después reemplaza
Ambas rutas verifican códec, formato de píxel, rango de color, CFR, recuento de fotogramas y ausencia de B-frames antes de reemplazar atómicamente el archivo final.
Una prueba de validación
Una conversión AV1 de prueba completó 1,800/1,800 fotogramas a 491.96 fps de codificación. La salida fue H.264 High, yuv420p, BT.709 rango limitado, CFR 60 fps y cero B-frames, y comparada con esa fuente midió un PSNR medio de 52.220 dB a CQ 18. Es un resultado de ese archivo de prueba, no una garantía universal de calidad ni de velocidad de conversión.
Estabilidad y seguridad
Lo verificado hasta ahora, expresado como lo que se ha probado y no como una garantía.
La vida útil de los fotogramas en GPU tiene un propietario explícito, lo que impide que una liberación tardía de un fotograma de NVDEC haga referencia a un backend ya destruido.
Las rutas inseguras o que se sobrescribirían a sí mismas se rechazan antes de analizar el archivo o crear directorios.
Los casos de conversión no admitidos pasan a la canalización completa de FFmpeg en lugar de descartar en silencio el audio o la normalización.
Las salidas se validan antes del reemplazo atómico, conservando el archivo verificado anterior si falla la codificación, la validación o la confirmación.
MediaPrep 1.1.0 incluye en el paquete portable verificado la CLI de MediaCore correspondiente y los runtimes necesarios.
Los tests de MediaCore, los tests de enrutado de MediaPrep y la compilación Release de HyperStageX pasaron en la máquina de desarrollo medida.
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.