Una vez corté una respuesta de cuarenta y dos de una entrevista, la dejé caer en una baraja y observé al orador comenzar a mitad de la oración siete segundos antes de la parte que quería. Había fijado el arranque con cuidado. La recortadora me había ignorado, o eso parecía. No lo había hecho: había hecho lo único que puede hacer un corte rápido, que es comenzar en el fotograma clave más cercano antes del punto que pedí. Una vez que sabes eso, el comportamiento deja de ser un error y se convierte en una opción con dos opciones, y elegir la correcta toma un segundo.
TL;Dr: Un recorte rápido copia la secuencia de video existente en lugar de volver a codificarla, y una copia solo puede comenzar en un fotograma clave. Pida comenzar en 0:07 en un archivo cuyos fotogramas clave están separados y el corte comienza a las 0:00, porque ese es el último punto desde el que puede partir el decodificador. El final aterriza donde usted preguntó; sólo el comienzo se desplaza y se desplaza hacia atrás. La solución cuando necesita el marco exacto es volver a codificar, que es más lento y cuesta un poco de calidad. los recortadora de video Ofrece ambos y los valores predeterminados a los rápidos.
¿Por qué el corte comienza antes de lo que pediste?
Porque casi ningún cuadro en un video es una imagen completa.
La compresión de video funciona almacenando un cuadro completo y luego describiendo los cambios. un fotograma clave, correctamente un marco IDR en H.264, tiene una imagen completa y no depende de nada. Los fotogramas después de que se mantienen diferencias: este bloque se movió cuatro píxeles a la izquierda, esta región no cambia, estos píxeles se oscurecieron ligeramente. Un cuadro a la mitad de esa secuencia no tiene sentido por sí solo, la forma en que una diferencia no tiene sentido sin el archivo al que se aplica.
Entonces, cuando pides comenzar a las 0:07 y la herramienta copia la transmisión sin decodificarla, no hay nada en 0:07 para copiar. Hay una descripción de cómo 0:07 difiere de algo anterior. Los únicos lugares donde un jugador puede comenzar son los fotogramas clave, y el único seguro es el último fotograma clave en o antes de su punto de inicio.
La alternativa es decodificar el video hasta 0:07, tirar lo que vino antes y comprimir lo que queda en un nuevo archivo que comienza con un nuevo fotograma clave. Eso es exacto, y es el camino lento, por la razón de que hace un trabajo real en cada cuadro en lugar de copiar bytes.
¿Qué tan separados están los fotogramas clave, realmente?
Más allá de lo que la mayoría de la gente asume, y la brecha es lo que decide qué tan mal se ve un corte rápido.
Lo medí en lugar de adivinar. Codificación de treinta segundos de material de prueba con x264 en sus valores predeterminados, y luego enumerando los fotogramas clave:
ffmpeg -f lavfi -i "testsrc=duration=30:size=640x360:rate=25" -c:v libx264 clip.mp4
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 clip.mp4 \
| awk -F, '$2 ~ /K/ {print $1}'
# 0.000000
# 10.000000
# 20.000000
Un fotograma clave cada diez segundos. Ese es el valor predeterminado de 250 fotogramas entre fotogramas clave, a 25 fotogramas por segundo. En un archivo codificado con esos valores predeterminados, un recorte rápido puede comenzar hasta diez segundos antes del punto que eligió.
La mayoría de las imágenes que manejas son más amigables, porque la mayor parte de ellas se hicieron para la transmisión, donde los jugadores necesitan puntos de entrada frecuentes para cambiar la calidad. Aquí está el rango que vale la pena conocer:
| Fuente | Brecha típica del fotograma clave | Deriva en el peor de los casos en un corte rápido |
|---|---|---|
| grabación telefónica | 1 a 2 segundos | apenas perceptible |
| Transmisión de video, HLS o DASH | 2 a 6 segundos | Notable en un clip corto |
| Valores predeterminados X264 o FFmpeg | 10 segundos a 25 fps | arruina un atajo |
| Grabador de pantalla, movimiento bajo | 10 segundos o más | arruina un atajo |
El patrón: cualquier cosa codificada para un jugador tiene fotogramas clave cerrados, y cualquier cosa codificada una vez para el almacenamiento no lo hace.
¿Qué le hace la deriva al archivo?
Mueve el comienzo y deja el final solo, lo que vale la pena ser preciso porque es fácil asumir que todas las ventanas se deslizan.
Pidiendo el mismo clip de 0:07 a 0:15, una ventana de ocho segundos, con una copia de stream:
| solicitado | Marcos clave en la fuente | Resultado | que paso |
|---|---|---|---|
| 7s a 15s | 0, 10, 20 | 0s a 15.08s | Comience a caer al fotograma clave en 0 |
| 12 a 20 | 0, 10, 20 | 10 a 20.08s | El comienzo volvió a caer al fotograma clave a las 10 |
| 7s a 15s | cada 2 s | 6s a 15.08s | Comienzo Fall Atrás un fotograma clave |
El final es correcto en los tres. Comprobé que al hashing frames en lugar de confiar en la duración: el último cuadro de la salida es idéntico al marco de origen a 15.04 segundos, que es el marco después de la que pedí y el lugar correcto para detener. Lo que cambió es donde comienza.
Por eso el archivo es más largo que la ventana que seleccionó. Un corte que pensaste que era ocho segundos llega como quince, no porque nada invadió, sino porque aparecieron siete segundos de entrada. En un clip donde los fotogramas clave están separados por dos segundos, el mismo corte llega como nueve segundos y nadie se da cuenta.
¿Cuándo deberías volver a codificar?
Tres casos, y fuera de ellos el camino rápido es la mejor herramienta.
Necesitas un marco específico. Cortar una palabra, en un gesto, en el momento en que una pelota golpea un bate. La precisión del fotograma clave no es suficiente y no te ayudará ninguna cantidad de cuidado con el control deslizante, porque el límite está en el archivo en lugar de en la interfaz.
El clip es corto. Una entrada de siete segundos en un corte de treinta segundos es una molestia. En un corte de cuatro segundos es todo.
Estás cortando un archivo con fotogramas clave escasos. Las grabaciones de pantalla y todo lo exportado una vez para el archivo, como muestran las mediciones anteriores.
El costo es real pero más pequeño de lo que la gente teme. Una re-codificada decodifica cada fotograma de la ventana y la comprime de nuevo, por lo que lleva un tiempo proporcional a la longitud del corte en lugar del tamaño del archivo, y pierde una generación de calidad. Con un factor de velocidad constante de 23, que es lo que usa el recortador para su modo preciso, esa pérdida es casi invisible en una pasada. Es una segunda pasada de las imágenes que ya se ha comprimido una vez, que es la misma Pérdida de generación que rige la compresión Generalmente.
¿Cómo encuentras los fotogramas clave en tu propio archivo?
Un comando, y le indica de antemano si el camino rápido funcionará.
# the first ten keyframe timestamps, in seconds
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 input.mp4 \
| awk -F, '$2 ~ /K/ {print $1}' | head -10
Si los huecos son de uno o dos segundos, recorte rápido y deje de pensar en ello. Si tienen diez años, y su corte importa, vuelva a codificar.
Hay un segundo uso para esto. Si está produciendo imágenes que otras personas cortarán, codificar con un intervalo de fotograma clave más corto hace su vida mucho más fácil, a un costo pequeño en el tamaño del archivo. Un fotograma clave es una imagen completa, por lo que más de ellos significa más bytes, por lo que los codificadores los espacian cuando nadie pide nada más.
¿El recorte pierde calidad?
El camino rápido no lo hace, en sentido estricto. No se decodifica nada, por lo que no se vuelve a comprimir nada: los marcos en la salida son los mismos marcos comprimidos que estaban en la entrada, byte para bytes, en un nuevo contenedor. Recorte un archivo diez veces de esta manera y el décimo es idéntico en calidad al primero.
El camino preciso sí, una vez. La ventana se decodifica y se comprime nuevamente, por lo que capta una generación de pérdida. En una fuente bien codificada en un objetivo de calidad sensata, esto es difícil de ver, y la regla sensata es hacer el corte que necesita en una pasada del original en lugar de recortar un recorte de un recorte.
Ninguno de los caminos sube, agudiza o mejora nada. Una recortadora elimina el tiempo, que es todo el trabajo.
¿Por qué mi clip recortado no comienza a reproducirse de inmediato?
Por dónde aterriza el índice, y es la misma bandera que importa al comprimir.
Un MP4 contiene una tabla que describe dónde comienza cada cuadro. Escrito en el orden obvio, esa tabla termina al final del archivo, porque el codificador solo conoce su contenido cuando ha terminado. Reproducido desde un disco, bien. Servido a través de HTTP, un jugador no puede comenzar hasta que haya llegado todo el archivo.
pasa la recortadora -movflags +faststart, que hace una segunda pasada rápida y mueve esa mesa al frente. Luego, el corte comienza a reproducirse mientras se descarga, que es lo que desea cuando el archivo ingresa a una aplicación de chat, un CMS o una diapositiva que lo extrae de una URL.
¿Qué pasa con el audio?
El audio se corta en sus propios límites de cuadro, y son mucho más cortos que los intervalos de fotogramas clave de video, por lo que el audio puede comenzar más cerca de su marca que la imagen.
Esa descalce es la fuente del otro fallo de recorte clásico: un clip cuyo sonido está ligeramente por delante de la imagen, o que comienza con un fragmento de una palabra. La solución está en los argumentos en lugar de en la edición, y la recortadora la pasa: -avoid_negative_ts make_zero Rebase las marcas de tiempo de ambos flujos para que la salida comience en cero con los flujos aún alineados entre sí. Sin él, una copia de la secuencia puede emitir marcas de tiempo negativas para los fotogramas entre el fotograma clave y su punto de corte, y los jugadores no están de acuerdo sobre qué hacer con ellos. Algunos saltan, algunos detienen, otros reproducen el audio temprano.
Si solo quieres el sonido, cortando el video primero y luego Extrayendo el audio es el orden equivocado. Extraiga primero y corte el audio, porque los cortes de audio son precisos y baratos.
¿Es mejor recortar en la aplicación de fotos del teléfono?
Para un clip personal rápido, está bien y está justo ahí. Para cualquier cosa que publicarás, no, y la razón no es obvia.
Los editores de teléfonos generalmente vuelven a codificar en la exportación, y lo hacen con la configuración seleccionada para la velocidad y el tamaño de archivo predecible en lugar de la fidelidad. Usted paga una generación de pérdida en cada recorte. Peor aún, algunos de ellos recortan de manera no destructiva, almacenando sus puntos de entrada y salida como metadatos junto al original, que parece un ajuste en el teléfono y no es un ajuste en absoluto una vez que el archivo lo deja: el destinatario obtiene el clip completo o una lista de edición que su jugador ignora.
Un recorte en modo copia evita ambos problemas. El archivo que obtienes es el archivo que todos reciben, y los marcos que contiene nunca se decodificaron.
¿El video sale de mi máquina?
prohibido . El corte pasa por FFmpeg compilado en WebAssembly Dentro de la pestaña del navegador: el archivo se lee desde el disco en la memoria de la página, se recorta allí y se devuelve como descarga. El panel de red en DevTools permanece vacío del video mientras esto sucede.
Para las imágenes, eso importa más que para la mayoría de los tipos de archivos. Un clip suele ser lo más grande y personal que cualquier persona edita, y el arreglo normal para una recortadora en línea gratuita es que suba sus imágenes a un extraño y confíe en la política de retención en una página que no leyó. Aquí no existe copia para retener.
Los límites son las pestañas en lugar de un plan: un solo corte tiene un límite de treinta minutos y toda la fuente debe encajar en la memoria del navegador. Más allá de eso, una herramienta de escritorio es más rápida y confiable, y decirlo es mejor que entregarle una pestaña que se queda sin memoria en el minuto nueve.
¿Cuándo es un editor de escritorio la herramienta adecuada?
cuando estás haciendo más que eliminar el tiempo. Al unir varios clips, agregar títulos, color, música o cortar en una forma de onda, debe ver a nivel de muestra. Esa es una línea de tiempo de edición, no una recortadora, y la respuesta correcta es un editor real.
Dentro del navegador, la línea divisoria es casi igual de limpia. Quitar un tramo de un clip es un recorte. Uniendo piezas es el Vídeo Editor. Hacer el resultado más pequeño es el compresor, y cambiar el contenedor o códec es el convertidor, que es un Operación diferente de la compresión Aunque los dos se confundan constantemente.
¿Por qué la vista previa y el archivo exportado no están de acuerdo?
Porque una interfaz de recorte recopila el mismo número de tres lugares que no están de acuerdo con qué número es, y obtenerlo en un valor es la mayor parte del trabajo en una recortadora.
Un campo de texto le da lo que sea que haya escrito alguien, lo que podría ser 7, 0:07, 00:00:07 investigaciones operacionales 7.25. Un control deslizante le da un flotador con más precisión de lo que nadie quiere. Un elemento de vídeo currentTime Da otra flotación, que no es necesariamente la marca de tiempo de un cuadro en absoluto: los navegadores pueden informar una posición entre los cuadros, y lo hacen.
Si esos tres aterrizan en segundos ligeramente diferentes, la vista previa muestra una cosa y la exportación produce otra, que es el error específico que hace que una recortadora se sienta rota incluso cuando el corte es correcto. El analizador acepta aquí las tres formas de código de tiempo, las resuelve alineadas a la derecha, por lo que la última parte siempre tiene segundos, sea cual sea la duración y le da un solo valor tanto a la vista previa como a la exportación. Un campo a medio tipo no devuelve nada en lugar de lanzar, por lo que la entrada no explota en cada tecla mientras escribe 0:0.
El consejo práctico: escriba el código de tiempo en lugar de arrastrarlo, cuando el segundo exacto importa. Un control deslizante es para encontrar el momento, un campo para nombrarlo.
¿Cómo puedo cortar una sección del medio?
Dos cortes y una unión, y ninguna recortadora lo hace en un solo paso, lo que sorprende a las personas razonablemente a menudo.
Quitar la mitad de un clip significa mantener la parte antes de su selección y la parte posterior, que son dos ventanas separadas, y luego volver a juntarlas. La recortadora produce aquí una ventana por ejecución, por lo que la secuencia es: recorte desde el principio hasta el comienzo de la sección defectuosa, recorte desde el final de la sección defectuosa hasta el final, luego une las dos en el Vídeo Editor.
Dos cosas para ver cuando haces eso. La unión funciona limpiamente cuando ambas piezas comparten un códec, una resolución y una velocidad de fotogramas, que se procederán si ambas provienen del mismo archivo fuente a través de ajustes en modo copia. Y la costura aterriza en un límite de fotogramas clave en ambos lados, por lo que la segunda pieza comienza un poco antes de lo que marcó, exactamente como se describió anteriormente. Si el punto de corte es importante, use el modo preciso para la segunda pieza.
La otra opción es detenerse antes de comenzar: si lo que desea es un punto destacado en lugar de una redacción, dos clips separados suelen ser más útiles que un clip con un espacio cosido.
