Ir al contenido

Compresión de vídeo para desarrolladores y QA

Un flujo de trabajo práctico para reducir el tamaño de las grabaciones de repro en MOV, MP4, WebM y GIF, de modo que la evidencia siga siendo legible y quepa en los tickets, pull requests y solicitudes de soporte.

Grabaste el error en treinta segundos. Subir el repro tardó más, falló dos veces y GitHub te dijo que el archivo era demasiado grande. O bien, QA adjuntó un MOV que nunca se cargó en línea, así que nadie lo vio.

Una grabación de pantalla suele ser la forma más rápida de explicar una regresión, pero solo cuando los revisores pueden abrirla rápidamente, leer la interfaz y reproducir el camino exacto del error.

Tamaños de archivo de grabación de pantalla frente a los límites del gestor de incidencias

Los gestores de incidencias y los repositorios de PR limitan el tamaño de los adjuntos. Un MOV o MP4 a resolución completa procedente de QuickTime, CleanShot u OBS suele tener decenas o cientos de megabytes antes de recortar cualquier cosa.

Recorta primero y luego comprime hasta el límite real del gestor, dejando suficiente margen para la subida. Conserva el texto de la interfaz antes de perseguir el número más pequeño. Usa un preajuste de Tamaño de archivo objetivo cuando importe un límite estricto. Convierte a un GIF pequeño solo cuando un bucle corto y silencioso explique el problema mejor que el vídeo.

Formatos de vídeo, GIF y captura de pantalla para informes de errores

La evidencia de los errores tiene varias formas, y cada una exige una opción de entrega distinta:

  • Vídeo: MOV, MP4, WebM, M4V, MKV y más, procedentes de grabadoras de pantalla y herramientas de demostración.
  • GIF: pequeños fallos de la interfaz, estados al pasar el cursor y regresiones de carga que se leen mejor como un bucle.
  • Imágenes: capturas de pantalla en PNG y JPEG cuando un fotograma estático es suficiente para el informe.

La misma cola y los mismos preajustes, ya sea que QA lo haya registrado o que estés adjuntando la prueba a tu propio PR.

Adjuntar vídeos de repro a incidencias y pull requests

Los clips antes y después aceleran la revisión. Un MP4 compacto que muestra el error y luego la corrección ofrece contexto a los revisores sin necesidad de hacer checkout de la rama. La aprobación de QA funciona igual: los adjuntos ligeros son más fáciles de buscar, reabrir y compartir meses después.

Suelta un lote de grabaciones tras una pasada de prueba, o copia un archivo y obtén una versión más ligera en tu portapapeles lista para pegar en la incidencia.

Crear una carpeta de captura repetible

Usa una carpeta predecible por ticket o ejecución de prueba: source, redacted y attachment. Conserva la captura original, aplica la redacción aprobada en una copia y crea el adjunto más pequeño a partir de esa copia revisada. Un archivo en attachment debería ser seguro para colocar en el gestor con nombre sin necesidad de otra decisión subjetiva.

Incluye el ID del ticket y la plataforma en el nombre del archivo, como GC-142-windows-actual.mp4. Evita nombres de archivo que expongan nombres de clientes, direcciones de correo electrónico o nombres de host internos.

Límites de adjuntos del gestor de incidencias en la práctica

GitHub, Jira, Linear y la mayoría de los repositorios de PR limitan los adjuntos en línea entre 10 y 100 MB, dependiendo del plan y el tipo de archivo. Un MOV de treinta segundos a resolución Retina completa puede superar ese límite sin parecer “grande” en el disco. Consulta los límites de tamaño de adjuntos por correo electrónico para ver el mismo cálculo cuando pegues clips de repro en hilos de correo electrónico con PMs y soporte.

Los preajustes de Tamaño de archivo objetivo se ajustan a un límite conocido. Para regresiones de la interfaz donde un bucle GIF es suficiente, exporta un bucle pequeño en lugar de un MP4 completo. La compresión con pérdida frente a compresión sin pérdida importa menos para los repros en movimiento que para las capturas de pantalla PNG con texto fino; conserva los preajustes de captura de pantalla de forma conservadora para que los lectores de los tickets puedan seguir leyendo las etiquetas.

La supervisión de carpetas en el directorio de grabaciones significa que cada nueva captura es ligera antes de que alguien la adjunte. Esto es especialmente útil durante las semanas de regresión, cuando todo el equipo está soltando archivos MOV en la misma bandeja de entrada.

Lista de verificación previa para una evidencia útil del error

La compresión no puede rescatar una grabación desenfocada. Antes de adjuntar el archivo, verifica que la evidencia en sí sea correcta:

  1. Empieza en un estado reconocible y muestra la acción exacta que desencadena el problema.
  2. Recorta el inicio de sesión, la configuración, los reintentos y el tiempo inactivo, a menos que uno de ellos forme parte del error.
  3. Mantén el puntero visible y agranda la ventana de la aplicación antes de grabar controles pequeños.
  4. Avanza por la copia comprimida al 100 % y confirma que las etiquetas, el texto de la consola y los mensajes de error siguen siendo legibles.
  5. Elimina las notificaciones no relacionadas, los tokens, los registros de clientes y las pestañas del navegador.
  6. Indica el entorno, la compilación, el resultado esperado y el resultado real en el texto de la incidencia; el vídeo debe apoyar el informe, no sustituirlo.

Usa H.264 MP4 cuando importe la reproducción amplia en navegadores. Un GIF es útil para un bucle silencioso muy corto, pero su paleta de colores limitada y su compresión débil lo convierten en una opción deficiente por defecto para evidencias más largas. Conserva la grabación original hasta que se cierre la incidencia, por si un revisor necesita un fotograma más nítido.

Los límites difieren lo suficiente como para que los equipos deban comprobar el destino, en lugar de memorizar un único número. GitHub documenta 10 MB de subida de vídeo en repositorios gratuitos y 100 MB en repositorios de pago , mientras que Jira Cloud establece por defecto 1 GB por archivo y permite a los administradores cambiar el valor . El objetivo práctico puede seguir siendo mucho más pequeño porque los revisores necesitan una reproducción rápida, no solo una subida exitosa.

Cuándo GetCompress encaja en los flujos de trabajo de informes de errores

Los controles de exportación de una grabadora son suficientes para un clip ocasional, y el gestor de incidencias sigue siendo el lugar para los pasos, el entorno y el comportamiento esperado. GetCompress es la mejor opción cuando los desarrolladores y QA preparan repetidamente evidencias en MOV, MP4, WebM, capturas de pantalla y GIF para diferentes límites de gestores. El tamaño de vídeo objetivo, los preajustes reutilizables, las colas por lotes y la supervisión de carpetas eliminan el trabajo de reexportación mientras las capturas permanecen locales. No sustituye a la grabadora de pantalla, al ticket ni al proceso de redacción aprobado.