QuickTime Player : pourquoi 500Mo + 400Mo = 1,2 Go ?

[Patrick Bernier]

Bonjour à tous,

J'ai ajouté une vidéo de 500mo, une autre vidéo de 400mo avec QuickTime Player. Quand je regarde les propriétés du fichier ainsi obtenu, j'obtiens une vidéo d'1,2 Go,
Savez-vous pourquoi ?

Merci d'avance

 

[JLB21]

Ponjour,

Savez-vous pourquoi ?

Oui. C'est parce que le débit de la vidéo finale est plus élevé que celui des deux vidéos originales. Ou au moins de l'une d'entre elles.

Mais il faudrait nous en dire plus sur les caractéristiques des vidéos que tu as mises bout à bout.

Mets la première vidéo en lecture avec QT et fait Cmd-I, puis fais une capture d'écran de la fenêtre d'information qui s'affiche.
Procède de la même manière avec la deuxième ainsi qu'avec la vidéo finale obtenue, et poste nous les 3 captures d'écran.

Nous serons alors en mesure de te donner une explication très précise.

 

[Patrick Bernier]

Merci de ton aide,
Ca fait quand même une sacrée réduction
Au passage, qu'est-ce que le débit d'une vidéo ? pourquoi est-il ici presque diminué de moitié ? merci

Fichier n°1


Fichier n°2

Fichiers n°1 + n°2

 

[JLB21]

Tout d'abord, les informations de ton post initial sont fausses : c'est en fait 3,65 Go + 7,27 Go -> 6,04 Go… :smuggrin:

La réduction de poids est tout à fait logique car tes deux vidéos de départ ont des débits de l'ordre de 45 Mbps et elles ont été ré-encodées par QuickTime Player avec le même codec (H.264) au débit de 25 Mbps.

Le débit pour une vidéo, c'est la quantité de données transmises pas seconde au cours de la lecture.

Dans ton cas les originaux ayant un débit de 45 Mbps, le poids des données transmises durant la lecture par seconde est de :
45/8 = 5,6 Mo par seconde.
Une vidéo d'1h va donc peser environ 20 Go.
La conversion des Mbps en Mo s'appuise sur le fait qu'il y a 8 Mb (Mégabits) dans 1 Mo.

Dans ton cas, QuickTime dont on ne peut gérer le débit d'encodage, a jugé qu'un débit de 25 Mbps (presque la moitié) suffisait ?

Mais c'est un débit faible, très limite pour de l'UHD. N'as-tu pas constaté de diminution de la qualité ?

 

[Patrick Bernier]

Tout d'abord, les informations de ton post initial sont fausses : c'est en fait 3,65 Go + 7,27 Go -> 6,04 Go… :smuggrin:

oui, toutes mes confuses ! je m'en suis rendu compte trop tard

Dans ton cas, QuickTime dont on ne peut gérer le débit d'encodage, a jugé qu'un débit de 25 Mbps (presque la moitié) suffisait ?

sais-tu pourquoi ? ça dépend de la résolution de l'écran de la machine utilisée pour coller les 2 vidéos ? ou de la qualité des 2 vidéos, QT estime que dégrader la qualité ne sera pas visible ? mais alors selon quelles règles, critères ?

Mais c'est un débit faible, très limite pour de l'UHD. N'as-tu pas constaté de diminution de la qualité ?

franchement... en regardant attentivement des morceaux de scènes, je ne vois rien... pas de pixelisation notamment, mais peut être y aurait il une différence visible sur un autre écran par exemple ?

 

[JLB21]

sais-tu pourquoi ?

Non, je ne sais pas comment et qu'est-ce qui présideau choix du débit de sortie choisi par QuickTime. J'imagine que l'application fait une analyse rapide de la complexité de la vidéo ?

je ne vois rien... pas de pixelisation notamment

Tant mieux. En général, les applications d'Apple pour la vidéo font de l'excellent boulot. Mais il faut regarder en détail, en plein écran, dans les passages un peu compliqués, comme des feuilles d'arbre agitées par le vent ou des feuillages touffus.

Ce qui compte c'est que je sois parvenu à t'expliquer le pourquoi du comment.
A savoir que le poids d'une vidéo est proportionnel à sa durée et à son débit.
Et que pour une définition donnée (ou dimension si tu préfères), plus le débit est faible, plus la vidéo est compressée.
Et si trop compressée, on va des artéfacts de lecture jusqu'à la bouillie de pixels.
Plus le débit est élevé, mais aussi le poids, plus la qualité est élevée.
C'est la même chose pour les photos, le TIFF est beaucoup plus lourd que le jpg…

 

[Patrick Bernier]

Merci JLB21 pour ta réponse,
En photo, l'oeil humain ne peut voir aucune différence entre un .raw et un .jpg
L'intérêt du .raw est de garder toutes les couches colorimétriques, et de pouvoir apporter les corrections utiles,
Mais en vidéo, le format reste ici le même... Je ne comprends toujours pas pourquoi QT "compresse" la vidéo, il y a bien de la donnée qui disparait (ici, près de 50% !), est-elle (vraiment) inutile à la lecture, est-elle pour autant utile pour des modifications de la vidéo elle-même (par exemple, accéléré/ralenti, colorimétrie,...), est-ce l'image qui a été compressée ou bien que le son par exemple,... grand mystère, surtout qu'à la base, on ne demande à QT que d'ajouter un fichier à un autre.
Si je reprends la comparaison en photo, un .raw de 20Mo pourrait donner un jpg de 4Mo par exemple, selon la complexité de la photo, Sur n'importe quel écran, le jpg s'affichera correctement, c'est en retouche seulement qu'il montrera ses limites,
:oops:

 

[JLB21]

Si je reprends la comparaison en photo, un .raw de 20Mo pourrait donner un jpg de 4Mo par exemple, selon la complexité de la photo, Sur n'importe quel écran, le jpg s'affichera correctement, c'est en retouche seulement qu'il montrera ses limites,

C'est exactement la même chose en vidéo où le raw existe (caméras professionnelles), mais avec des poids faramineux. D'où la sortie de formats raw moins volumineux, comme celui d'Apple.
Le format d'enregistrement des vidéos grand public est essentiellement en 4.2.0- 8 bits. Mais dès qu'on monte en gamme, l'enregistrement peut monter en 4.4.4 10 bits.

Exemple avec enregistrement ProRes, le 4444 XQ (l'un des rares codecs qui propose une couche alpha de transparence).

Dans le cas qui nous intéresse, QT X a effectué un ré-encodage vraisemblablement parce que les deux vidéos ne sont pas exactement de même nature/origine.
Si tu veux mettre bout à bout de clips issus de la même caméra avec les mêmes réglages d'enregistrement, QT X ne ré-encode pas : C'est quasi immédiat, les deux fichiers ne font plus qu'un.
Peu nombreuses sont les applications susceptibles de joindre deux fichiers sans ré-encodage.
Mais dans tous les cas, si les vidéos ne sont pas rigoureusement identiques, il y ré-encodage.

 

[Patrick Bernier]

Dans le cas qui nous intéresse, QT X a effectué un ré-encodage vraisemblablement parce que les deux vidéos ne sont pas exactement de même nature/origine.
Si tu veux mettre bout à bout de clips issus de la même caméra avec les mêmes réglages d'enregistrement, QT X ne ré-encode pas : C'est quasi immédiat, les deux fichiers ne font plus qu'un.
Peu nombreuses sont les applications susceptibles de joindre deux fichiers sans ré-encodage.
Mais dans tous les cas, si les vidéos ne sont pas rigoureusement identiques, il y ré-encodage.

Non justement, les 2 fichiers viennent du même smartphone, avec les mêmes réglages,
d'où mon étonnement ...

 

[JLB21]

Les deux fichiers n'ont pas exactement le même débit.
Les smartphones enregistrent la plupart du temps en fréquence d'images variable ou (et) encodent avec un débit variable (VBR).
Il est donc logique qu'il y ait eu ré-encodage.

 

[Patrick Bernier]

Je suis perplexe,...

Le 1er fichier est à 45,20 Mb/s, le 2ème est à 45,51 Mb/s
Certes les débits sont différents, mais la différence n'est pas énorme,
Et pourtant, QT a compressé de 45%.

J'aurais compris si il y avait eu de gros écarts de débits entre les 2 fichiers, QT se serait aligné sur le plus bas par exemple, pour homogénéiser l'ensemble, mais là, il sabre de moitié, alors que les 2 fichiers ont quasiment les mêmes débits,

 

[JLB21]

Il y a une autre chose qui peut jouer : si les GOP de l'une ou l'autre des vidéos étaient incomplets. Dans ce cas, pas d'autre solution que le ré-encodage.
Essaie de faire la même chose avec Shutter Encoder ou MP4 Joiner pour voir…

Pour le débit, je ne sais pas te répondre.

 

[Patrick Bernier]

Merci JLB21, je vais faire le test et te dirai ce qu'il en est,

Bonne journée