34 réponses à ce sujet

[Mikélé]

Bonjour à tou(te)s,

je suis décidément toujours bien ennuyé avec ce "fichu" format AVCHD. Peut-être qu'un jour la puissance de nos machines permettra de l'éditer en natif, sans conversion dans un format intermédiaire (AIC ou ProRes), mais ce jour là ne me semble pas vraiment proche... J'espère me tromper !

En effet, malgré une puissance respectable, mon iMac 2010 "top" (core i7 quad HyperThreading (8 "coeurs" apparents) à 2.93 GHz, 12 Go de RAM, Radeon 5750 1Go) ne le permet toujours pas ! J'ai en effet testé un petit logiciel dont je n'avais jusqu'à présent jamais entendu parler, ClipWrap, qui promet de "ré-emballer" un clip .m2ts ou .MTS (AVCHD ou MPEG2 HD) en .mov standard, tout à fait lisible sur Mac et Windows via QuickTime ! Rien que cela, et cela en un rien de temps, identique à celui d'une copie Finder !

Alléché par une telle perspective, j'ai fait l'acquisition dudit logiciel ($50) et je dois bien reconnaître que la promesse semble tenue ! Mes clips AVCHD, AVCHD lite et JVC TOD se retrouvent dupliqués en .mov de qualité identique, de taille quasi identique et s'affichent dans toute leur splendeur et sans le moindre souci avec QuickTime Player ! (QTX d'ailleurs bien meilleur que QT7 en rendu pour les films entrelacés). Les TOD se présentent même en tant que clips XDCAM-EX !

Je dois le reconnaître : je suis bluffé !

Et vous, vous l'avez essayé de votre côté ?
En cherchant sur le forum, j'ai vu qu'Hervé y avait brièvement fait référence en mars dernier mais je n'ai pas bien compris le lien entre le logiciel de capture "développeur" DVHSCap et ClipWrap...

Et puis si quelqu'un a une idée de "comment ça marche ?", je suis preneur... Car faire reconnaître par QT comme du H264 "standard" cette horreur qu'est l'AVCHD, cela m'impressionne vraiment !

Mais bon, mon objectif avoué était surtout de gagner énormément en stockage (entre 6 et 8 fois tout de même !) et éventuellement d'importer sans conversion mes clips ainsi ré-emballés dans iMovie. Et là, cela n'est pas concluant pour l'instant car iMovie (9.0.2/'11) me les "optimise" en les convertissant en AIC... Tout ça pour ça !

Mais je me suis alors dit, peut être que FCP permettrait la chose ?
Il semble qui oui, mais malheureusement, l'édition devient extrêmement laborieuse, même sur une telle machine. Logique somme toute.

D'où une autre idée : tant qu'à passer par un format intermédiaire, pourquoi ne pas utiliser le ProRes au lieu de l'AIC ? car à côté du ré-emballage, ClipWrap propose aussi la conversion dans tous les types de formats intermédiaire connus, peu ou prou (voir capture ci-dessous)



Alors je sais qu'Antoine a déjà donné son avis sur le sujet : les gains ne sont pas suffisants pour un usage grand-public, sans parler de la nécessité d'avoir FCP... mais bon, j'ai FCP, depuis 2009 une version plus légère du codec ProRes (ProRes LT) est maintenant disponible et les apports ne sont pas négligeables : présence de Time Code, couleur 10 bits, débit raisonnable d'environ 80 Mbps, etc... Tout ça c'est sur le papier mais même à l'affichage, le ProRes LT me semble qualitativement meilleur que l'AIC et les débits sont très proches.

Car vous l'avez compris, je souhaite avoir tout le temps mes vidéos des 20 dernières années à portée de main et en format éditable (si, si !), d'où mon intérêt pour iMovie et sa mise en œuvre géniale et simplissime du concept. Mais je souhaite également, lorsque j'en ai besoin, avoir la possibilité d'aller plus loin avec FCP, toujours en utilisant ces mêmes clips.

Alors, si vous étiez à ma place, que feriez vous ?

Bon dimanche !

PS : Mon rêve : peut-être que FCS 4 apportera l'édition AVCHD et H.264 native grâce à une "percée technologique" et l'usage intensif des apports "sous le capot" de Snow Leopard (Grand Central Dispatch, Open CL) ? Mais je rêve...

Modifié par Mikélé, 23 janvier 2011 - 12:35.

[adesir]

Salut,

Le AVCHD peut déjà être monté en natif, mais pas par Final Cut ni iMovie. Ce serait faisable techniquement avec les derniers Mac, si Apple voulait bien utiliser les outils qu'ils proposent aux développeurs ;-)

Certains logiciels s'en sortent plutôt bien sous Windows dans cet exercice et Premiere le propose aussi sur Mac. Nous attendons donc Apple...

Est-ce qu'il n'y aurait pas contradiction entre le passage en ProRes LT et l'utilisation de iMovie pour le catalogage et le montage rapide ?

Sinon, j'avais essayé ClipWrap mais il m'introduisait des décalages audio/vidéo dont je ne voulais pas...

Antoine

[Mikélé]

Salut Antoine

Le AVCHD peut déjà être monté en natif, mais pas par Final Cut ni iMovie. Ce serait faisable techniquement avec les derniers Mac, si Apple voulait bien utiliser les outils qu'ils proposent aux développeurs ;-)

Tout à fait d'accord avec toi, ainsi que sur le blu-ray dont je suis grand amateur !

Certains logiciels s'en sortent plutôt bien sous Windows dans cet exercice et Premiere le propose aussi sur Mac. Nous attendons donc Apple...

Ah bon, lesquels ? Je ne connais que Sony Vegas et encore sa version la plus chère...

Est-ce qu'il n'y aurait pas contradiction entre le passage en ProRes LT et l'utilisation de iMovie pour le catalogage et le montage rapide ?

Le monde est plein de contradictions... Mais en l'occurrence, il s'agit de mes besoins et la solution de l'AIC ne me convient pas vraiment. Et ce n'est pas moi qui ai décidé que l'AVCHD était l'avenir en matière de caméscopes. Car quand on voit ce que l'on peut faire avec du MPEG2 à seulement 35 voire 25 Mbps...

Sinon, j'avais essayé ClipWrap mais il m'introduisait des décalages audio/vidéo dont je ne voulais pas...

Ah oui, avec quelle version ? parce que pour l'instant, c'est le sans-faute en ce qui me concerne.

[uzboxberg]

j'en ai déjà discuté sur MacBi, mais je n'ai toujours pas compris pourquoi ClipWrap pourrait être utile (toi-même tu dis que les clips soi-disant en .mov, sont importés en AIC, ProRes ou autre, moyenant réencodage par iMovie/FCP).
S'il s'agit de lire de l'AVCHD, VLC fait ça très bien. Le but serait de se passer d'un long réencodage...

Modifié par uzboxberg, 23 janvier 2011 - 21:28.

[Mikélé]

Salut Uz,

non justement, FCP ne réencode pas les .mov en question, à la différence de iMovie.
Mais l'édition est pas franchement réactive.
Je vais quand même faire plus de tests.

Mon problème, c'est que pour moi, FCP n'est pas aussi pratique pour gérer tout mon fond vidéo, disons des 20 dernières années. Rappel : je ne suis pas un professionnel qui travaille "au projet" : je monte lorsque j'ai le temps et l'envie de le faire.

Mais comme je n'ai pas consacré beaucoup de temps à son apprentissage, et c'est vraiment le moins que l'on puisse dire, je ne sais pas s'il pourrait m'offrir cette gestion souple et performante qu'iMovie me propose depuis iLife'08. Eh oui, il y en a qui ne regrettent pas iMovie 6 HD !

Si quelqu'un qui l'utilise régulièrement - comme toi ou d'autres ici - pouvait me suggérer un moyen de gérer mon fond vidéo en éditable (par ex. en ProRes LT), cela m'aiderait et je pourrais peut-être alors consacrer un peu plus de temps à l'apprentissage de FCP (édition / montage).

Car, pour faire la comparaison avec la photo, je n'ai jamais accroché à iPhoto, jamais !
Par contre Aperture me convient à merveille, particulièrement depuis la version 3 d'ailleurs, et je pense le maitriser plutôt bien. Un peu nécessaire avec mes 120 000 photos ! (numériques et argentiques)

En vidéo, FCP m'a toujours un peu rebuté, même si j'en saisis la puissance, mais comme iMovie - contrairement à iPhoto - m'a toujours donné satisfaction, je n'étais point tenté d'aller voir ailleurs. C'est juste que depuis 3 ans, ce satané format AVCHD me contrarie énormément. J'avais envisagé le HDV pour son aspect éditable en natif (avec FCP) mais le "côté cassette" m'en a détourné. J'ai même acheté un JVC en MPEG2 sur carte SD (le GZ-HD3)... mais je l'ai retourné au bout d'une semaine tellement son stabilisateur était nul !

Depuis, tu connais le marché : AVCHD über alles !
Ach ! Sch*iße !

Modifié par Mikélé, 24 janvier 2011 - 00:40.

[Mikélé]

Et puis, quant à VLC, je sais que c'est pas bien de critiquer les softs gratuits , mais bon, pour l'avoir utilisé depuis le tout début... c'est une "bouse", sur Mac tout du moins ! (jamais essayé sur windows ou linux)

Quel dommage d'avoir un si bon moteur gâché par une interface utilisateur aussi consternante !
On pouvait l'admettre au début, maintenant, après tant d'années, c'est simplement honteux.
Et dire que beaucoup ne jurent que par VLC...

Edit : sans aucun troll de ma part, je dois dire que VLC plante souvent chez moi (30 à 40% des lancements), et quand elle ne plante pas, c'est très fréquemment que je me retrouve avec un contrôleur (hideux) seul à l'écran. Le soft semble avoir des problèmes graves d'interface avec Mac OS X !

Alors certes, j'essaie VLC pour des cas plutôt difficiles mais pourquoi l'utiliserais-je pour des fichiers gérés sans problème par QT Player, bien plus "léché" question interface...
(et surtout avec Perian installé)

Modifié par Mikélé, 24 janvier 2011 - 15:05.

[herve]

En cherchant sur le forum, j'ai vu qu'Hervé y avait brièvement fait référence en mars dernier mais je n'ai pas bien compris le lien entre le logiciel de capture "développeur" DVHSCap et ClipWrap...

ce soft est une utilisation du "sdk firewire" fourni gratuitement par Apple: c'est un ensemble de codes qui "filtrent les vidéos pour en extraire le contenu"

Et puis si quelqu'un a une idée de "comment ça marche ?", je suis preneur... Car faire reconnaître par QT comme du H264 "standard" cette horreur qu'est l'AVCHD, cela m'impressionne vraiment !

1- isoler le contenu de l'emballage (cf sdk)
2- réorganiser l'ordre des images, quicktime ne gérant qu'un type de AVC: dont les images sont référencées/ordonnées différemment (cf sdk)
3- convertir l'audio en PCM (cf sdk)
4- convertir en AIC/ProRes/etc

L'utilisation de ce sdk est très ingénieuse, en pratique c'est certainement comme ça que fait apple (tu pourras faire confirmer?). Et toujours dans l'ordre de la supposition, je pense que si Apple ne propose cette fonction que pour les cartes mémoires, c'est sans doute à cause des licenses qu'ils ont acquis (le sdk date quand même, bref apple avait les moyens d'implémenter cette fonction depuis belle lurette )

Et là, cela n'est pas concluant pour l'instant car iMovie (9.0.2/'11) me les "optimise" en les convertissant en AIC... Tout ça pour ça !

j'ai aussi joué à monter du AVCHD juste re-filtré, c'est injouable sur FCE (depuis une source 1080i je suis passé en lecture, du mac mini1,8GHz*2 à 2 images par seconde, à l'iMac 3Ghz*2 à 5 images par seconde). Je ne parle même pas des rendus en continu. Bref j'ai laissé tomber

D'où une autre idée : tant qu'à passer par un format intermédiaire, pourquoi ne pas utiliser le ProRes au lieu de l'AIC ?

tu as FCP? alors utilise le ProRes (ce codec est plus meilleur: plus de précision concernant le canal luminosité et les canaux couleurs aussi ! en bonus, moins de désaturation et meilleur contraste, mais là je chipote ). Autre avantage (ou inconvenient?): l'image étant définie en 4:2:2, le fichier ne sera plus à la merci des foutus automatismes de QuickTime qui foirent systématiquement les sources entelacées en 4:2:0. Inconvénient: la gestion via QuickTime des 422 est assez foireuse (toujours des automatismes ex: ne surtout pas exporter en h264 un 422). Compressor sauve la soft (lui fait du bon boulot avec les 422)

PS: (publicitaire?) je vais mettre moi aussi le rewrap, mais pour le moment que pour les sources progressives (les lumix ou ton pana300/700 ). Ce mode a le grand avantage de la vitesse.
Le seul possible soucis de ce type de code est qu'il est dépendant de la qualité de la source: quand le d'Apple m**doit durant la conversion = la captation avait eu des ratés.
Comme ce type de code ne recrée pas le contenu de la vidéo, pas de possibilité de "réparer" une vidéo pas bonne (cas d'un caméscope Sony Pro qu'avait testé Antoine). PS: heureusement, ce n'est que rarement le cas

à+

Modifié par herve, 24 janvier 2011 - 09:09.

[Mikélé]

Salut Hervé et merci pour tes réponses

2- réorganiser l'ordre des images, quicktime ne gérant qu'un type de AVC: dont les images sont référencées/ordonnées différemment (cf sdk)

Ainsi, c'est principalement une histoire d'ordre des images qui rend l'AVCHD si... spécial !
Intéressant.

j'ai aussi joué à monter du AVCHD juste re-filtré, c'est injouable sur FCE (depuis une source 1080i je suis passé en lecture, du mac mini1,8GHz*2 à 2 images par seconde, à l'iMac 3Ghz*2 à 5 images par seconde). Je ne parle même pas des rendus en continu. Bref j'ai laissé tomber

Pareil pour moi... pour l'instant.
Suite au prochain FCS, peut-être ?

tu as FCP? alors utilise le ProRes (ce codec est plus meilleur: plus de précision concernant le canal luminosité et les canaux couleurs aussi ! en bonus, moins de désaturation et meilleur contraste, mais là je chipote). Autre avantage (ou inconvenient ? ): l'image étant définie en 4:2:2, le fichier ne sera plus à la merci des foutus automatismes de QuickTime qui foirent systématiquement les sources entelacées en 4:2:0. Inconvénient: la gestion via QuickTime des 422 est assez foireuse (toujours des automatismes ex: ne surtout pas exporter en h264 un 422). Compressor sauve la soft (lui fait du bon boulot avec les 422)

C'est aussi la conclusion vers laquelle je penche, suite à mes derniers essais hier soir. Car en plus des avantages sur le papier (4:2:2, timecode, 10 bits, etc...), les chiffres de performance que j'ai collectés sont implacables :

Commentaires / questions :

1) Apple a vraiment optimisé la conversion en ProRes : les 8 coeurs sont à fond en permanence alors que lors d'une conversion AIC par iMovie, c'est plutôt de l'ordre de 50-60%, ce qui est déjà pas mal.

2) Comment se fait-il que les clips en AIC prennent de plus en plus de place ? Car 130 Mbps en AIC, c'est énorme surtout par rapport aux 82 Mbps du ProRes LT ! Le plus surprenant c'est que le ratio taille AIC/taille MTS grimpe avec le temps (*) mais c'est peut-être lié au contenu des clips... Toujours est-il qu'avec le ProRes LT, le débit semble mieux géré autour de son débit cible de 85 Mbps (1080 50i/25p).
(*) Le ratio taille AIC était autour de 5.7x pour mon ancien HF100, 6.3x pour mes premières cartes TM300 et oscille maintenant entre 7.3x et 8x pour mes dernières cartes !

3) Bref, à 37 Go de l'heure et avec un ratio temps-réel de 2.7x, le ProRes LT a gagné des points (en plus de ses avantages techniques). Il me reste maintenant à trouver le moyen "pas trop galère" de capturer les clips MTS avec toutes leurs métadonnées et de partager les clips ProRes LT en résultant entre événements iMovie et projets FCP. Une bonne dose de scripting sera sans doute nécessaire... à suivre !

Edit : Je vais aussi faire des tests en 25p pour voir l'influence de l'entrelacement

Un document instructif : le White Paper ProRes mis à jour en 2009 (angliche)

Modifié par Mikélé, 25 janvier 2011 - 01:41.

[Mikélé]

Bon, ben voila, j'ai finalement converti mes 257 Go de vidéo AVCHD (et AVCHD lite) en 1.12 To de vidéo ProRes 422 LT, tous les clips correctement nommés et référencés dans iMovie avec les bonnes dates et accessibles à la fois dans FCP et dans Aperture ! Presque le Graal pour moi !

Je sais que cela ne concerne probablement pas grand monde - il faut avoir Final Cut Studio - mais au cas où cela intéresserait quelqu'un, je peux poster plus de détails de la procédure que j'applique, qui au demeurant me fait gagner :

• du temps par rapport à l'import AIC standard de iMovie ('08, '09 et '11)
• de la qualité avec le format ProRes 422 LT
• de la taille, et pas qu'un peu !

Je pourrais également ajouter "de la souplesse" car il est enfantin de faire l'ébauche de son projet avec iMovie, en utilisant ses atouts notamment le "scrubbing", les mots clés, etc... sur la totalité de sa vidéothèque (près de 20 ans de "rushes" en ce qui me concerne) et de générer un fichier XML pour Final Cut, que ce dernier reprendra sans coup férir pour créer un projet quasi identique ! Et tout cela en 2 secondes...

Enfin, je peux même importer tous mes clips dans Aperture (par référence, sans duplication de données) et profiter ainsi de la puissance énorme de ses métadonnées, afin de rechercher les clips qui m'intéressent.

Le pied !

Seul bémol, mes fichiers DV issus de mes caméscopes VHS-C, Hi8, Digital8 et miniDV...
et même Super-8 Kodachrome !

Je n'ai pas encore trouvé le moyen de les stocker sans "gâchis" de place afin qu'il soient utilisables dans FCP. En effet, lorsque je veux en faire des .mov sans perte de qualité, MPEG StreamClip m'en double la taille comme s'il faisait des movies QuickTime avec des pistes multiplexées (le DV) dans chaque piste, vidéo et audio ! Mais bon, je créerai probablement un autre sujet... si je ne trouve pas de solution dans les sujets passés.

Dernier point : ce serait bien qu'Apple intègre le ProRes 422 LT (au moins celui là) à Final Cut Express...

Modifié par Mikélé, 01 février 2011 - 00:07.

[herve]

[…DV…] Je n'ai pas encore trouvé le moyen de les stocker sans "gâchis" de place afin qu'il soient utilisables dans FCP. En effet, lorsque je veux en faire des .mov sans perte de qualité, MPEG StreamClip m'en double la taille comme s'il faisait des movies QuickTime avec des pistes multiplexées (le DV) dans chaque piste, vidéo et audio !

les softsFinalCut attendent un audio dissocié de la vidéo
Donc MPSC crée une piste DV pour la vidéo et une piste DV pour l'audio (ce qui produit une taille double à celle d'un DV brut)
Perso j'ai choisit de faire une piste DV video + 1 audio non compressé, ça prend plus de place qu'un DV Brut mais moins que le choix de MPSC (par contre, lui garde une meilleure compatibilité avec la norme DV, alors que moi je limite à la compatibilité QuickTime=emballage dans un mov)
…ce ne sont que des choix perso , ayant pour même but de se conformer aux besoins des softs de montage d'Apple.

Dernier point : ce serait bien qu'Apple intègre le ProRes 422 LT (au moins celui là) à Final Cut Express...

à qui le dis-tu

à+

Modifié par herve, 01 février 2011 - 10:19.

[Mikélé]

les softsFinalCut attendent un audio dissocié de la vidéo
Donc MPSC crée une piste DV pour la vidéo et une piste DV pour l'audio (ce qui produit une taille double à celle d'un DV brut)
Perso j'ai choisit de faire une piste DV video + 1 audio non compressé, ça prend plus de place qu'un DV Brut mais moins que le choix de MPSC (par contre, lui garde une meilleure compatibilité avec la norme DV, alors que moi je limite à la compatibilité QuickTime=emballage dans un mov)
…ce ne sont que des choix perso , ayant pour même but de se conformer aux besoins des softs de montage d'Apple.

Ah, très bien ! Je vais donc pouvoir utiliser MovieConverter pour mes médias DV !
Désolé de ne pas y avoir pensé plus tôt !

Mais on ne pourrait pas avoir seulement la vidéo (démultiplexée) dans la piste vidéo ?

Modifié par Mikélé, 01 février 2011 - 13:28.

[herve]

Mais on ne pourrait pas avoir seulement la vidéo (démultiplexée) dans la piste vidéo ?

désolé, pas pigé

à+

[Mikélé]

Le flux DV contient de la vidéo et de l'audio sous forme multiplexée. Le débit total est d'environ 28.8 Mbps (Mibps ?) et donc une partie de ce débit est consacrée à des informations audio.

Comme la norme DV prévoit "4 pistes au format PCM non compressé, échantillonnées à 32 kHz et codées en 12 bits, ou 2 pistes en 48 kHz et codées sur 16 bits", on a donc un débit de 4*32000*12 = 2*48000*16 = 1.536 Mbps, rien que pour l'audio.

Dans le fichier QT résultant de MC, tel que je le comprends, on aura donc au moins un débit de 28.8+1.536 = 30.336 Mbps.

Je voulais savoir ce qui empêche techniquement de supprimer l'audio de la piste vidéo pour retrouver ce débit nominal de 28.8 Mbps, mais en pistes distinctes (non muxées) dans un movie QT.

J'anticipe ta réponse : "pourquoi s'embêter pour seulement 1.536 Mbps ?"

Soit une heure d'audio en 691.2 Mo, et donc 80 heures en 55.3 Go... tout de même, pour des données en double !

C'est vrai qu'à l'heure de la vidéo HD, "on n'est plus à cela près" mais bon, c'était principalement pour connaître l'obstacle technique, s'il existe.

Modifié par Mikélé, 01 février 2011 - 15:14.

[uzboxberg]

@ Mikélé: je ne comprend pas bien: chez moi MPSC fait exactement l'inverse, i.e. "alléger" la vidéo DV-PAL en démultiplexant; en tout cas il me semble, je vais vérifier ! (je capture le flux DV dans iMovie 6HD par ex., puis je mouline les rushs dans MPSC pour en faire du .mov à donner à FCE, en exportant par QT, fichier Apple DV-PAL; le débit doit être qq chose de 33-35 Mbps, de tête, par rapport à 55 pour le DV). Mais peut-être me trompe-je...

(je rappelle qu'Apple, par mégarde (?), avait inclus la ProRes422 dans FCE 4.0, pour la rétirer avec le MAJ 4.0.1 (les salauds... ) . En même temps, elle est lisible et MPSC peut l'utiliser).

Modifié par uzboxberg, 01 février 2011 - 16:42.

[Mikélé]

Salut Uz !
Non non, le clip .dv capturé par iMovie a un débit réel de 28.8 Mbps et la version .mov produite par MPSC a un débit de 57.6 Mbps, soit exactement le double.
Remarque aussi que lorsque tu ouvres le .dv avec QuickTime Player, il t'annonce froidement un débit de 57.6 Mbps, ce qui est faux mais qui correspond au dédoublage qu'il a semble-t-il fait au chargement de la vidéo du fait du multiplexage. Utilise la formule taille/durée pour calculer le débit réel et tu verras que c'est bien cela...
Tout cela est lié aux "problèmes congénitaux" de QT avec toute vidéo multiplexée (DV, MPEG1, MPEG2, etc...). Et lorsque qu'il les gère, c'est à travers la création "behind the scenes" d'une piste audio séparée qu'il aura été créer en mémoire par démux.

Modifié par Mikélé, 01 février 2011 - 17:13.

[uzboxberg]

et ben, chez moi ce n'est pas pareil, mais l'inverse (je viens de regarder dans mes vieux fichiers DV).
Voici ce que dit MPSC, d'abord du fichier .DV capturé dans iMovie, ensuite du fichier .mov exporté en Apple-DV-PAL.
En réalité, les deux fichiers pèsent le même poids (le .mov est légèrement plus lourd, 41Mo versus 39 Mo).
(Et comme tu dis, QT se trompe beaucoup à ce niveau...).

bonne soirée !
UZ

Fichier(s) joint(s)

•  DV_vs_mov.rtf   1,01 Ko   214 téléchargement(s)

[Mikélé]

Je comprends mieux : en fait même MPSC se trompe sur les .dv car il utilise QT pour les ouvrir.
Utilise plutôt les tailles du Finder et tu verras.
Bonne soirée à toi aussi

[uzboxberg]

ce que j'ai pas compris (d'où mon intervention):

Donc MPSC crée une piste DV pour la vidéo et une piste DV pour l'audio (ce qui produit une taille double à celle d'un DV brut)

la vidéo DV seul a un débit de 28,8 Mbps (muxé ou pas, on est d'accord*), c'est les 1.5 Mbps de l'audio démultiplexée qui te gênent ?

(j'ai utilisé Finder, comme indiqué dans mon post, le poids est presque identique entre DV et .mov, vu que la différence de débit n'est que de 1,5 Mbps, ou d'environ 2,5%: 39,7 Mo pour le DV, 41,8 Mo pour le .mov du fichier de 11 sec).

*c'est rigolo, mais tous les outils indiquent des débits différents; j'ai testé QT/MPSC, VideoSpec, et MediaInfo.

[Mikélé]

c'est les 1.5 Mbps de l'audio démultiplexée qui te gênent ?

Oui, en effet. J'ai du mal à accepter que l'audio (non compressé et à 1.536 Mbps) soit présent à la fois dans la piste vidéo (sous forme muxée) et dans la piste audio (sous forme démuxée/autonome)

Parce qu'au final, sur des dizaines d'heures de vidéo DV, cela fait des des dizaines de gigaoctets de stockage perdus... pour rien ! (cela fait 1.536/28.8 = +5.33%)

Modifié par Mikélé, 01 février 2011 - 22:00.

[uzboxberg]

bon d'accord...