← Volver a proyectos

Proyecto 08 / Caso de estudio

Infraestructura · almacenamiento · producción de vídeo

El material de vídeo hace que la nube deje de ser barata en el segundo terabyte.

Una productora con edición compartida en DaVinci Resolve: varias personas abriendo los mismos proyectos y las mismas secuencias a la vez. Ese entorno tiene un servidor de datos propio, y es el mejor ejemplo que conozco del argumento que recorre todas mis infraestructuras: cuando el volumen es grande y el acceso es continuo, el precio del almacenamiento en la nube deja de ser un gasto razonable y pasa a ser el problema. Esta ficha es más corta que las demás porque no puedo enseñar casi datos; lo que sí puedo es explicar el criterio.

avc1el único vídeo que entra en el editor
mp4aaudio AAC, nunca Opus
1080p · 30techo autoimpuesto de descarga
0cifras del almacén publicadas
RolEl entorno no es mío: aporto las herramientas y el criterio de coste
PlataformaNAS de una productora de vídeo, edición compartida
TecnologíasDaVinci Resolve, almacenamiento de red, códecs H.264 y AAC
01

El reto

Editar vídeo entre varios exige que todo el mundo vea lo mismo al mismo tiempo y a velocidad de red local. El material son horas de grabación en códecs pesados, y un proyecto de Resolve no referencia un archivo: referencia miles. Subir eso a un plan de cloud de consumo no es caro, es directamente inviable, y en cuanto añades el tráfico de salida y las licencias por usuario, la discusión se acaba sola.

02

La solución

Un servidor de datos en la propia red, con el material y los proyectos compartidos accesibles para todas las estaciones de edición. Es la respuesta que casi cualquier productora small da antes de que la nube le salga a cuenta: el almacenamiento se paga una vez y el acceso está a la velocidad del cable del rack, no a la de la subida de la oficina.

03

El aprendizaje

Que el coste real de una infraestructura no es el recibo mensual, es la curva. Hay cargas que deben vivir en la nube y cargas donde la nube es un impuesto. Aprender a distinguirlas es lo que este entorno me enseñó, y es lo que aplico después al decidir qué monto en casa y qué dejo contratado.

Por qué esto está en un portfolio de software

Porque condiciona el software que se escribe para él.

Un entorno de almacenamiento define qué formatos se aceptan, qué herramientas se pueden usar y qué se automatiza. Aquí tengo un ejemplo concreto y verificable.

Lo que aporto yo a ese entorno es software, y su parte más honesta es un descargador de vídeo que escribí para alimentar esas carpetas. Su restricción principal no la inventé: solo acepta vídeo H.264 (avc1) y audio AAC (mp4a), y rechaza expresamente VP9, AV1 y Opus. El motivo está escrito en el propio proyecto: en algunas instalaciones de Resolve esos formatos aparecen como Media Offline, que es la forma elegante que tiene un editor de decirte que el material no existe. Un descargador que baja la mejor calidad disponible es peor que uno que baja una calidad peor y la abre.

Encima se autoimpone un techo de 1080p a 30 fotogramas por segundo, y si el vídeo no tiene esa variante, baja la mejor calidad inferior en lugar de marcar el enlace como fallido. Es la misma lógica que el CRM cuando un enriquecimiento de datos no devuelve nada: la tarea tiene que terminar. Un lote de cien enlaces no se puede parar porque uno venga en 4K y no se pueda abrir.

Y está el argumento de fondo, el que da sentido a tener esta ficha aquí. El cloud se vende por comodidad, y para código, bases de datos pequeñas o picos de trabajo es la opción correcta: es lo que hago con los despliegues de mis servicios. Para material de vídeo es un impuesto, porque el volumen no baja nunca, el acceso es continuo y el tráfico de salida se cobra cada vez que alguien recupera lo suyo. Sé en qué casilla poner cada carga porque he visto los dos extremos: el servidor de inferencia de la ficha anterior y este almacén responden al mismo cálculo, hecho con dos cargas opuestas.

  • El entorno

      NAS en red localedición compartidaDaVinci Resolvevarias estacionesmismo proyecto, varios usuarios
  • Lo que aporto

      H.264 avc1AAC mp4aVP9, AV1 y Opus rechazadostecho 1080p · 30 FPSrepliegue automático de calidad
  • El criterio

      curva de coste, no recibovolumen permanente en casapicos y código en la nubeel tráfico de salida decide
  • Lo que no publico

      modelo del equipodiscos y capacidadconfiguración de redmaterial de clientes

Decisiones

Tres decisiones que sí son mías.

Ninguna sobre el servidor: sobre lo que escribo para que funcione con él.

01

Filtrar el códec antes de descargar, no después

La lista de formatos de un vídeo se inspecta antes de elegir, y si no hay H.264 con AAC se baja la mejor variante que sí funcione. El coste es renunciar a la máxima resolución disponible. El beneficio es que nadie en la sala de edición se encuentra un clip rojo y hay que volver a pedir el material. Detectar el problema en la entrada cuesta segundos; detectarlo cuando el montaje está montado cuesta una tarde.

02

Reintentar hacia abajo en lugar de fallar

Un enlace sin su variante preferida no se marca como error: se descarga la calidad inferior más alta que exista. El lote termina entero. La contrapartida es que el resultado es heterogéneo, clip que viene a 1080p y clip que viene a 720, y eso obliga a revisar antes de montar. Elegí el resultado desigual antes que el lote incompleto, porque un lote incompleto no se puede enseñar.

03

No publicar nada de este entorno

Modelo del equipo, número y tamaño de discos, esquema de copias, protocolos y, por supuesto, el material: nada de eso aparece aquí ni en ningún otro sitio público. Renuncio con ello a la ficha más impresionante de mi portfolio, porque un NAS de una productora con clientes dentro es un activo de otra persona. Me parece la prueba más clara de lo que esta web intenta vender: alguien en quien se puede confiar un entorno que no se puede enseñar.

Límites de esta ficha

Qué se puede comprobar aquí y qué no.

Para que no haya que adivinarlo leyendo entre líneas.

Se puede comprobar: el software que alimenta ese entorno está en mis repositorios, con sus restricciones de códec, su techo de calidad y su lógica de repliegue. Eso es lo que he escrito yo y es lo que sostengo esta ficha.

No se puede comprobar, y no digo que sí: el montaje del servidor, su configuración, su esquema de copias y su operación. Eso es el entorno de producción donde viven los entregables, no una instalación que yo haya construido ni pueda firmar. Lo que de ahí me llevo es el criterio de coste que aplico en mis propias máquinas y las herramientas que escribí para encajar en él.

Si en una conversación hace falta ver el entorno, se enseña en la conversación, con las personas y bajo las condiciones que la productora decida. Un portfolio no es el sitio.

  • avc1códec de vídeo admitido, H.264
  • mp4acódec de audio admitido, AAC
  • 3formatos rechazados a propósito: VP9, AV1 y Opus
  • 1080ptecho autoimpuesto, a 30 fotogramas por segundo
  • 0especificaciones del almacén publicadas

Lo que haría distinto

Escribir el descargador comprobando antes contra el códec que el editor traga, y no descubrirlo por la sala de edición. Y documentar la restricción donde la vaya a leer quien mantenga el código dentro de un año, que es lo que hice al final: hoy el motivo del Media Offline está en el README, no en mi cabeza. Si algún día participo en el diseño de un almacén de estos desde cero, la conversación empieza por la curva de coste del volumen y por el plan de copias, no por el aparato.