En el desarrollo de plataformas de video en línea, uno de los retos recurrentes es permitir que el usuario pueda desplazarse libremente en la línea de tiempo sin esperar la descarga completa del archivo. Una solución eficiente se encuentra en el estándar HTTP: el código de estado 206 Partial Content. Aquí te detallo cómo implementarlo paso a paso en un proyecto full-stack.

1. Fundamentos del código 206

Cuando el reproductor solicita un rango específico de bytes del archivo de video, el servidor responde con el estado 206 y envía únicamente ese segmento. Por ejemplo, si el usuario arrasrta el control de progreso al 50%, el navegador envía una cabecera Range: bytes=524288-, indicando que necesita datos desde la posición 512 KB hasta el final (o hasta un límite especificado).

2. Configuración del servidor con Express

Usamos Node.js con el módulo fs para leer el archivo de video. El servidor examina la cabecera Range y calcula las posiciones de inicio y fin del fragmento. Las respuestas deben incluir:

• Content-Range: bytes [inicio]-[fin]/[total] – por ejemplo, bytes 524288-1048575/2097152.
• Accept-Ranges: bytes – indica que el servidor soporta solicitudes parciales.
• Content-Length – tamaño exacto del fragmento enviado.

// Ejemplo de controlador en Express
app.get('/video', (req, res) => {
  const videoPath = './sample.mp4';
  const stat = fs.statSync(videoPath);
  const fileSize = stat.size;
  const range = req.headers.range;

  if (!range) {
    // Sin cabecera Range: envía todo el archivo con estado 200
    res.status(200).header('Content-Length', fileSize);
    fs.createReadStream(videoPath).pipe(res);
    return;
  }

  const parts = range.replace(/bytes=/, "").split("-");
  const start = parseInt(parts[0], 10);
  const end = parts[1] ? parseInt(parts[1], 10) : fileSize - 1;
  const chunkSize = (end - start) + 1;

  res.status(206);
  res.header({
    'Content-Range': `bytes ${start}-${end}/${fileSize}`,
    'Accept-Ranges': 'bytes',
    'Content-Length': chunkSize,
    'Content-Type': 'video/mp4'
  });

  const stream = fs.createReadStream(videoPath, { start, end });
  stream.pipe(res);
});

3. Construcción del reproductor frontend

En el cliente, utilizamos el elemento <video> y la API MediaSource para gestionar el buffer de forma dinámica. Escuchamos los eventos progress y seeked. Al detectar un salto de progreso:

1. Pausamos la reproducción actual.
2. Calculamos la posición en bytes equivalente al nuevo tiempo (usando el tamaño total conocido del video).
3. Cancelamos cualquier petición previa (usando AbortController).
4. Enviamos una nueva solicitud con el Range adecuado.
5. Insertamos el fragmento recibido en el buffer mediante SourceBuffer.appendBuffer().

El siguiente fragmento ilustra la lógica:

// Dentro del manejador 'seeked'
const newTime = videoElement.currentTime;
const totalBytes = 2097152; // conocido desde el encabezado inicial
const targetByte = Math.floor((newTime / videoElement.duration) * totalBytes);
// Cancelar petición anterior si existe
if (currentAbortController) {
  currentAbortController.abort();
}
currentAbortController = new AbortController();
fetch(`/video`, {
  headers: { 'Range': `bytes=${targetByte}-` },
  signal: currentAbortController.signal
})
.then(response => response.arrayBuffer())
.then(data => {
  mediaSource.sourceBuffers[0].appendBuffer(data);
});

4. Optimización del tamaño de fragmento con DeepSeek

El tamaño de cada fragmento impacta directamnete en la experiencia. Si es muy pequeño, se generan muchas peticiones; si es muy grande, aumenta la latencia inicial. Gracias al modelo DeepSeek integrado en la plataforma InsCode, implementamos un ajuste dinámico:

• Cuando el ancho de banda supera los 10 Mbps, incrementamos el fragmento a 2 MB.
• Si el usuario hace saltos frecuentes, reducimos el fragmento a 512 KB para minimizar el desperdicio de datos.
• Se guarda un historial de las velocidades de descarga para predecir el tamaño óptimo.

5. Panel de monitoreo en tiempo real

Debajo del reproductor añadimos una interfaz que muestra:

• Rango de bytes actualmente cargado (ej. "524288-1048575 / 2097152").
• Gráfico de línea del rendimiento de red (muestras cada 2 segundos).
• Estado del buffer: cuántos segundos de video están precargados.

Estos datos se obtienen mediante la Performance API (mediciones de performance.getEntriesByType('resource')) y eventos de MediaSource.

Despliegue sin complicaciones

Todo el desarrollo se realizó en la plataforma InsCode. Bastó con pegar las instrucciones de generación de proyecto y obtener un enlace público funcional. No fue necesario configurar Nginx ni CDN. Las pruebas mostraron que la respuesta al arrastrar la línea de tiempo es hasta 3 veces más rápida que la descarga completa, especialmente en archivos grandes. Además, DeepSeek optimizó la estrategia de fragmentación inicial, ahorrando horas de ajuste manual.