Une fois, j'ai coupé une quarante-deuxième réponse d'une interview, je l'ai déposée dans une platine et j'ai regardé l'orateur commencer une phrase à mi-parcours sept secondes avant le peu que je voulais. J'avais bien réglé le départ. La tondeuse m'avait ignoré, du moins c'était. Ce n'était pas le cas : il avait fait la seule chose qu'une coupe rapide puisse faire, qui est de commencer à l'image clé la plus proche avant le point que je demandais. Une fois que vous le savez, le comportement cesse d'être un bug et devient un choix avec deux options, et choisir la bonne prend une seconde.
tl;dr : Une version rapide copie le flux vidéo existant plutôt que de le ré-encoder, et une copie ne peut commencer qu'à une image clé. Demandez à commencer à 0:07 sur un fichier dont les images clés sont espacées de dix secondes et la coupe commence à 0:00, car c'est le dernier point à partir duquel le décodeur peut commencer. La fin atterrit là où vous avez demandé, seul le début dérive et il dérive en arrière. La solution lorsque vous avez besoin de la trame exacte est de ré-encoder, ce qui est plus lent et coûte un peu de qualité. le taille-bordure Offre les deux et les valeurs par défaut à la Fast One.
Pourquoi la coupe commence-t-elle plus tôt que ce que vous avez demandé ?
Parce que presque aucune image dans une vidéo est une image complète.
La compression vidéo fonctionne en stockant une image pleine, puis en décrivant les modifications. Une image clé, correctement une image IDR dans H.264, contient une image entière et ne dépend de rien. Les images après avoir retenu les différences : ce bloc a déplacé quatre pixels vers la gauche, cette région est inchangée, ces pixels sont légèrement plus sombres. Une trame à mi-chemin de cette séquence n'a aucun sens en soi, la façon dont un différentiel n'a pas de sens sans le fichier auquel il s'applique.
Ainsi, lorsque vous demandez à commencer à 0:07 et que l'outil copie le flux sans le décoder, il n'y a rien à 0:07 à copier. Il existe une description de la façon dont 0:07 diffère de quelque chose de plus tôt. Les seuls endroits où un joueur peut commencer sont les images clés, et le seul sûr est la dernière image clé à votre point de départ ou avant.
L'alternative est de décoder la vidéo jusqu'à 0:07, de jeter ce qui précède et de compresser ce qui reste dans un nouveau fichier qui commence par une nouvelle image clé. C'est exact, et c'est le chemin lent, car il fait un travail réel sur chaque image plutôt que de copier des octets.
À quelle distance se trouvent les images clés, vraiment ?
Plus loin que la plupart des gens ne le supposent, et l'écart est ce qui décide à quel point une coupe rapide semble erronée.
Je l'ai mesuré plutôt que de deviner. Encodage trente secondes de séquences de test avec x264 à ses valeurs par défaut, puis répertorier les images clés :
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
Une image clé toutes les dix secondes. C'est la valeur par défaut de X264 de 250 images entre les images clés, à 25 images par seconde. Sur un fichier encodé avec ces valeurs par défaut, une version rapide peut commencer jusqu'à dix secondes avant le point que vous avez choisi.
La plupart des images que vous traitez sont plus amicales, car la plupart d'entre elles ont été conçues pour le streaming, où les joueurs ont besoin de points d'entrée fréquents pour changer de qualité. Voici la gamme à connaître :
| Source | Ecart d'images clés typique | Le pire dérive sur une coupe rapide |
|---|---|---|
| Enregistrement téléphonique | 1 à 2 secondes | à peine perceptible |
| Vidéo en streaming, HLS ou Dash | 2 à 6 secondes | Remarquable sur un court clip |
| Par défaut x264 ou FFmpeg | 10 secondes à 25 ips | Ruine un raccourci |
| Enregistreur d'écran, faible mouvement | 10 secondes ou plus | Ruine un raccourci |
Le modèle : tout ce qui est encodé pour un lecteur a des images clés proches, et tout ce qui est encodé une fois pour le stockage n'en a pas.
Que fait la dérive vers le fichier ?
Il déplace le début et laisse le bout tranquille, ce qui vaut la peine d'être précis car il est facile de supposer que l'ensemble des diapositives de la fenêtre.
Demander le même clip pour 0:07 à 0:15, une fenêtre de huit secondes, avec une copie de flux :
| demandé | Images clés dans la source | Résultat | Ce qui s'est |
|---|---|---|---|
| 7s à 15s | 0, 10, 20 | 0 à 15.08s | Démarrer est tombé à l'image clé à 0 |
| 12 à 20 ans | 0, 10, 20 | 10s à 20.08s | Démarrer est tombé à l'image clé à 10 |
| 7s à 15s | tous les 2 s | 6s à 15,08s | Démarrer Retomber en arrière une image clé |
La fin est juste dans les trois. J'ai vérifié cela en hachant des trames plutôt qu'en faisant confiance à la durée : la dernière trame de la sortie est octet-identique à la trame source à 15,04 secondes, qui est la trame après celle que j'ai demandée et le bon endroit pour arrêter. Ce qui a changé, c'est là où ça commence.
C'est pourquoi le fichier est plus long que la fenêtre que vous avez sélectionnée. Une coupe que vous pensiez avoir duré à huit secondes arrive comme quinze, non pas parce que quelque chose de dépassé, mais parce que sept secondes de présure sont arrivées. Sur un clip où les images clés sont espacées de deux secondes, la même coupe arrive à neuf secondes et personne ne le remarque.
Quand faut-il ré-encoder à la place ?
Trois cas, et en dehors d'eux, le chemin rapide est le meilleur outil.
Vous avez besoin d'un cadre spécifique. Couper un mot, sur un geste, au moment où une balle frappe une batte. La précision des images clés n'est pas suffisante et aucun soin apporté au curseur ne sera utile, car la limite est dans le fichier plutôt que dans l'interface.
Le clip est court. Une introduction de sept secondes sur une coupe de trente secondes est une nuisance. Sur une coupe de quatre secondes, c'est le tout.
Vous coupez dans un fichier avec des images clés clairsemées. Les enregistrements d'écran et tout ce qui est exporté une fois pour l'archive, comme le montrent les mesures ci-dessus.
Le coût est réel mais plus petit que les gens ne le craignent. Un ré-encodage décode chaque image de la fenêtre et la comprime à nouveau, il prend donc du temps proportionnel à la longueur de la coupe plutôt qu'à la taille du fichier, et il perd une génération de qualité. À un facteur à taux constant de 23, ce que le taille-douce utilise pour son mode précis, cette perte est presque invisible sur un seul passage. Il s'agit d'un deuxième passage sur des images qui ont déjà été compressées une fois, ce qui est le même Perte de génération qui régit la compression Généralement.
Comment trouvez-vous les images clés dans votre propre fichier ?
Une commande, et il vous indique à l'avance si le chemin rapide fera l'affaire.
# 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 les écarts sont d'une ou deux secondes, coupez rapidement et arrêtez d'y penser. S'ils sont dix et que votre coupe compte, ré-encodez.
Il y a une deuxième utilisation pour cela. Si vous produisez des images, d'autres personnes seront coupées, l'encodage avec un intervalle d'images clés plus court leur facilite grandement la vie, à un faible coût de la taille des fichiers. Une image clé est une image complète, donc plus d'entre eux signifient plus d'octets, c'est pourquoi les encodeurs les espacent lorsque personne ne demande quoi que ce soit d'autre.
La taille perd-elle de sa qualité ?
Le chemin rapide ne le fait pas, au sens strict. Rien n'est décodé, donc rien n'est recompressé : les trames de la sortie sont les mêmes trames compressées que celles qui étaient dans l'entrée, octet pour octet, dans un nouveau conteneur. Coupez un fichier dix fois de cette façon et le dixième est de qualité identique au premier.
Le chemin précis fait, une fois. La fenêtre est décodée et compressée à nouveau, ce qui permet de détecter une génération de perte. Sur une source bien codée à un objectif de qualité raisonnable, c'est difficile à voir, et la règle sensée est de faire la coupe dont vous avez besoin en une seule passe de l'original plutôt que de couper une garniture.
Aucun des deux chemins ne met à l'échelle, ne nettement ni n'améliore quoi que ce soit. Une tondeuse supprime le temps, qui est le travail complet.
Pourquoi mon clip coupé ne commence-t-il pas à jouer immédiatement ?
En raison de l'endroit où l'indice atterrit, et c'est le même drapeau qui compte lors de la compression.
Un MP4 contient une table décrivant le lieu où commence chaque image. Écrit dans l'ordre évident, ce tableau se termine à la fin du fichier, car l'encodeur ne connaît son contenu que lorsqu'il a terminé. Joué à partir d'un disque, très bien. Servi sur HTTP, un lecteur ne peut pas démarrer tant que le fichier n'est pas arrivé.
La tondeuse passe -movflags +faststart, qui effectue une deuxième passe rapide et déplace cette table vers l'avant. La coupe commence alors à jouer pendant qu'elle télécharge, ce que vous voulez lorsque le fichier est entré dans une application de chat, un CMS ou une diapositive qui le tire d'une URL.
Qu'advient-il de l'audio ?
L'audio est coupé sur ses propres limites d'image, et celles-ci sont beaucoup plus courtes que les intervalles d'images clés, de sorte que l'audio peut commencer plus près de votre marque que l'image.
Cette incompatibilité est la source de l'autre défaut de coupe classique : un clip dont le son est légèrement en avance sur l'image, ou qui commence par un fragment de mot. Le correctif est dans les arguments plutôt que dans l'édition, et le tailleur passe : -avoid_negative_ts make_zero Rebase les horodatages des deux flux afin que la sortie commence à zéro avec les flux toujours alignés les uns par rapport aux autres. Sans cela, une copie de flux peut émettre des horodatages négatifs pour les images entre l'image clé et votre point de coupe, et les joueurs ne sont pas d'accord sur ce qu'il faut faire avec ceux-ci. Certains sautent, certains s'arrêtent, certains jouent le son tôt.
Si vous ne voulez que le son, coupez d'abord la vidéo, puis Extraction de l'audio est le mauvais ordre. Extrayez d'abord et coupez l'audio, car les coupes audio sont précises et bon marché.
Est-il préférable de couper dans l'application photo du téléphone ?
Pour un clip personnel rapide, c'est bien et c'est juste là. Pour tout ce que vous publierez, non, et la raison n'est pas évidente.
Les éditeurs de téléphones ré-encodent généralement à l'exportation, et ils le font avec des paramètres choisis pour la vitesse et pour une taille de fichier prévisible plutôt que pour la fidélité. Vous payez une génération de pertes sur chaque version. Pire, certains d'entre eux coupent de manière non destructive, stockant vos points d'entrée et de sortie en tant que métadonnées à côté de l'original, qui ressemble à une coupe sur le téléphone et n'est pas du tout une coupe une fois que le fichier l'a quitté : le destinataire obtient le clip complet ou une liste de modifications que son lecteur ignore.
Une coupe en mode copie évite les deux problèmes. Le fichier que vous obtenez est le fichier que tout le monde obtient et les images qu'il contient n'ont jamais été décodées.
La vidéo laisse-t-elle ma machine ?
non . La coupe traverse FFMPEG compilé dans WebAssembly Dans l'onglet du navigateur : le fichier est lu du disque dans la mémoire de la page, coupé et renvoyé en téléchargement. Le panneau réseau de devtools reste vide de la vidéo pendant que cela se produit.
Pour les images, cela compte plus que pour la plupart des types de fichiers. Un clip est généralement la chose la plus importante et la plus personnelle que quiconque modifie, et la disposition normale d'un coupe-bordure en ligne gratuit est que vous téléchargez vos images sur un étranger et que vous faites confiance à la politique de rétention sur une page que vous n'avez pas lue. Ici, aucune copie n'existe à conserver.
Les limites sont les tabulations plutôt qu'un plan : une seule coupe est plafonnée à trente minutes, et toute la source doit tenir dans la mémoire du navigateur. Au-delà de cela, un outil de bureau est à la fois plus rapide et plus fiable, et il vaut mieux que vous le remettre à un onglet qui manque de mémoire à la minute neuf.
Quand un éditeur de bureau est-il le bon outil ?
Lorsque vous faites plus que supprimer le temps. Rejoindre plusieurs clips, ajouter des titres, de la couleur, de la musique ou une coupe sur un signal que vous devez voir au niveau de l'échantillon. C'est une chronologie d'édition, pas une tondeuse, et la bonne réponse est un véritable éditeur.
Dans le navigateur, la ligne de division est presque aussi propre. Retirer un étirement d'un clip est une garniture. Unir les pièces est le éditeur de vidéos. Le résultat est réduit compresseur, et la modification du conteneur ou du codec est le convertisseur, qui est un Fonctionnement différent de la compression Même si les deux deviennent constamment confus.
Pourquoi l'aperçu et le fichier exporté sont-ils en désaccord ?
Parce qu'une interface de TRIM collecte le même nombre à partir de trois endroits qui ne sont pas d'accord sur ce qu'est un nombre, et les obtenir sur une valeur est la plupart du travail d'une tondeuse.
Un champ de texte vous donne tout ce que quelqu'un a tapé, ce qui pourrait être 7, 0:07, 00:00:07 ou 7.25. Un curseur donne un flotteur avec plus de précision que tout le monde ne le souhaite. Un élément vidéo currentTime Donne un autre flotteur, qui n'est pas nécessairement l'horodatage d'une trame : les navigateurs sont autorisés à signaler une position entre les images, et ils le font.
Si ces trois atterrissent sur des secondes légèrement différentes, l'aperçu montre une chose et l'exportation en produit une autre, qui est le bogue spécifique qui fait qu'un tondeuse se sent cassé même lorsque la coupe est correcte. L'analyseur accepte ici les trois formes de code temporel, les résout à droite afin que la dernière partie soit toujours quelques secondes quelle que soit la longueur, et donne une seule valeur à la fois à l'aperçu et à l'exportation. Un champ à moitié typé ne renvoie rien plutôt que de lancer, de sorte que l'entrée n'explose pas sur chaque frappe pendant que vous tapez 0:0.
Les conseils pratiques : tapez le code temporel plutôt que de faire glisser, lorsque la seconde exacte compte. Un curseur est pour trouver le moment, un champ est pour le nommer.
Comment découper une section du milieu ?
Deux coupes et une jointure, et aucune tondeuse ne le fait en une seule étape, ce qui surprend assez souvent les gens.
Retirer le milieu d'un clip signifie conserver la pièce avant votre sélection et la pièce après, qui est deux fenêtres séparées, puis les remettre ensemble. Le coupe-bordure produit ici une fenêtre par course, la séquence est donc : rogner du début au début de la mauvaise section, rogner de la fin de la section défectueuse, puis joindre les deux dans le éditeur de vidéos.
Deux choses à regarder quand vous faites cela. La jointure fonctionne proprement lorsque les deux pièces partagent un codec, une résolution et une fréquence d'images, ce qu'elles proviendront si les deux proviennent du même fichier source via des ajustements en mode copie. Et la couture atterrit sur une limite d'images clés des deux côtés, de sorte que la deuxième pièce commence légèrement plus tôt que vous ne marquiez, exactement comme décrit ci-dessus. Si le point de coupe est important, utilisez le mode précis pour la deuxième pièce.
L'autre option est d'arrêter avant de commencer : si ce que vous voulez, c'est un surbrillance plutôt qu'une reddaction, deux clips distincts sont souvent plus utiles qu'un clip avec un écart cousu.
