1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

QuickTime X




Apple a fait quelque chose d'un peu bizarre, dans Léopard, quand il a négligé de porter l'API QuickTime basée sur C en 64 bits. A l'époque, cela ne semblait pas être un enjeu important. La transition de Mac OS X vers le 64 bits s'était déjà étalée sur plusieurs années et plusieurs versions majeures. On pouvait penser que ce n'était pas encore l'heure pour QuickTime de passer en 64 bits.

Tel que cela se présente, mon évaluation de la situation, abrupte, mais pessimiste à l'époque était juste : QuickTime a reçu le "traitement Carbon". Comme Carbon, la vénérable API QuickTime, que nous connaissons et aimons bien, ne sera pas -jamais- de la transition vers le 64 bits.

Pour être clair, QuickTime, la technologie et QuickTime, la marque vont à coup sûr passer en 64 bits. Ce qu'on abandonne avec la version 32 bits, c'est l'API basée sur C, introduite en 1991, et utilisée pendant 18 ans. Son remplaçant dans le monde 64 bits a été opportunément appelé QuickTime X.

Le X de QuickTime X, comme celui de de Mac OS X se prononce "dix". Ce n'est pas le premier de ces étranges parallèles. Comme Mac OS X avant lui, QuickTime X :
• entend se départir clairement de son prédécesseur
• est basé sur une technologie développées sur une autre palteforme
• inclut une compatibilité transparente avec son incarnation antérieure
• promet de meilleurs performances et une architecture plus moderne
• manque des possibilités importantes qu'avait la précédente version.

Prenons les choses l'une après l'autre. D'abord, pourquoi une rupture nette était-elle nécessaire ? Pour le dire simplement, QuickTime est vieux, réellement vieux. L'image vidéo épouvantablement pointilliste, de la taille d'un timbre-poste de la version initiale en 1991 était considérée comme un tour de force technologique.

Vitesse CPU

La vitesse CPU maximum disponible (en MHz)



A cette époque, le Macintosh le plus rapide qu'on pouvait acheter, avait un processeur à 25 MHz. Le graphique ridicule à droite enfonce le clou. Une conception prévoyante ne peut vous mener que jusqu'à un certain point. L'état du monde dans lequel une technologie est née dicte inévitablement son destin. Et cela est particulièrement vrai pour des APIs qui ont vécu longtemps comme QuickTime, avec une forte inclinaison pour une compatibilité rétrograde.

Comme première implantation réussie de la vidéo sur un ordinateur personnel, il est vraiment étonnant que l'API QuickTime ait vécu aussi longtemps. Mais le monde a bougé. Tout comme Mac OS se retrouva englué dans le ghetto du multitâche coopératif et la mémoire non protégée, QuickTime s'est traîné jusqu'en 2009 avec des notions dépassées de concurrence et un sous-système entravé par sa conception.

Quand le temps fut venu d'écrire le code de gestion de la vidéo pour l'iPhone, la dernière version de QuickTime, QuickTime 7 n'était tout simplement pas à la hauteur. Il s'était inefficacement enflé pendant son existence sur les ordinateurs de bureau, il manquait d'un bon support pour un rendu Vidéo accéléré par GPU, indispensable pour utiliser des codecs vidéo modernes sur un portable (même avec un CPU 16 fois plus rapide que celui des Macs disponibles quand QuickTime 1.0 a été livré). Si bien qu'Apple a créé un moteur de rendu vidéo solide, moderne, à même d'utiliser les GPU, qui puisse s'accommoder confortablement des contraintes de mémoire et de CPU de l'iPhone.

Hum... Une API vidéo pour PC vieillissante, qui avait besoin d'être remplacée. Une toute nouvelle bibliothèque vidéo avec de bonnes performances, même sur un matériel (comparativement) anémique. Apple a fait la relation. Mais le tour est toujours en train d'être joué. Heureusement, c'est le fort d'Apple. QuickTime avait déjà vécu lui-même sur trois architectures CPU différentes, et trois systèmes d'exploitation complètement différents.

Le passage à 64 bits est encore un autre point d'inflexion (quoi que moins dramatique), et c'est ce qu'Apple a choisi pour marquer la différence entre le vieux QuickTime 7 et le nouveau QuickTime X. Pour cela, dans Léopard des neiges, Apple a limité toute utilisation de QuickTime par des applications 64 bits au framework Objective C QTKit.

Le nouvel ordre du monde de QTKit

QTKit n'est pas nouveau ; il a commencé en 2005 comme une interface plus intuitive à QuickTime 7 pour les applications Cocoa. Ce niveau supplémentaire d'abstraction est la clé de la transition vers QuickTime X. QTKit cache maintenant derrière les murs de l'architecture orientée objet aussi bien QuickTime 7 que QuickTime X. Les applications utilisent le QTKit comme auparavant, et derrière le rideau, QTKit choisit d'utiliser soit QuickTime 7, soit QuickTime X pour réaliser la requête.

Si QuickTime X est si supérieur, pourquoi QTKit ne l'utilise-t-il pas pour tout ? La réponse est que QuickTime X, comme son pendant Mac OS X, a des possibilités très limitées dans sa version initiale. QuickTime X sait lire, capturer, et exporter, mais il manque d'un moyen d'édition vidéo à usage général. Il reconnaît les formats vidéo "modernes" (tout ce qu'on peut jouer sur un iPod, un iPhone, ou l'Apple TV), mais pour les autres codecs vidéo, hé bien, vous pouvez les oublier, ainsi que les greffons, parce que QuickTime X ne les connaît pas non plus.

Pour chacun des cas où QuickTime X n'est pas capable de faire le travail, QuickTime 7 va le faire. Couper, copier, coller des portions d'une vidéo ? QuickTime 7. Extraire une piste d'un film ? QuickTime 7. Jouer un film non reconnu par les mobiles existants d'Apple ? QuickTime 7. Enrichir le jeu de codecs de QuickTime au moyen d'un greffon de quelque sorte que ce soit ? QuickTime 7.

Mais, attendez un peu. Si QTKit est la seule façon pour une application 64 bits d'utiliser QuickTime, si QTKit choisit entre QuickTime 7 et QuickTime X derrière le rideau, que QuickTime 7 est seulement en 32 bits, et que Mac OS X ne supporte pas les processus en mode mixte capables d'exécuter à la fois du code 32 bits et du code 64 bits, alors, comment diable un processus 64 bits peut-il faire quelque chose qui requiert le concourt de QuickTime 7 ?

Pour comprendre, lancez la nouvelle application 64 bits QuickTime Player (que je vais aborder séparément plus tard), et ouvrez un fichier qui a besoin de QuickTime 7. Disons par exemple, un qui utilise le codec vidéo Sorensen. (Vous vous rappelez ? Le bon temps). A coup sûr, ça marche. Mais cherchez "QuickTime" dans le moniteur d'activité, et vous allez voir ceci :

processus 32 bits furtif

Plutôt furtif, le processus 32 bits QTKit

Voilà donc la réponse. Quand une application 64 bits qui utilise QTKit a besoin du service de rendu en 32 bits de QuickTime 7, QTKit fait éclore un processus QTKit server 32 bits séparé pour faire le travail, puis communique le résultat au processus 64 bit qui en est à l'origine. Si vous laissez ouvert Activity Monitor en utilisant l'application QuickTime Player, vous pouvez observer les processus QTKit server aller et venir selon les besoins. Tout ceci est géré de façon transparente par le framework QTKit ; l'application elle même n'a pas besoin d'être au courant de ces opérations.

Oui, cela va être long, très long, avant que QuickTime 7 ne disparaisse complètement de Mac OS X (au moins, Apple a été assez élégant pour ne pas l'appeler QuickTime Classic), mais la voie est claire. Avec chaque nouvelle livraison de Mac OS X, attendez-vous à ce que les possibilités de QuickTime X s'étendent, et que le nombre de choses qui requièrent QuickTime 7 diminue. Dans Mac OS X 10.7, par exemple, j'imagine que QuickTime X va recevoir le support des greffons (plug-ins). Et sans doute, pour Mac OS X 10.8, QuickTime X pourra bénéficier d'un support d'édition complet. Tout cela va se dérouler derrière la façade unificatrice de QTKit, jusqu'à ce que les services de QuickTime 7 ne soient plus du tout nécessaires.

Dites ce que vous voulez faire

En même temps, d'une façon surprenante peut être, beaucoup des limitations actuelles de QuickTime X soulignent en fait ses avantages exclusifs, et renseignent sur l'évolution de l'API QTKit. Bien qu'il n'y ait aucun moyen direct pour un développeur de demander que QTKit utilise le rendu QuickTime X, il y a plusieurs moyen indirects d'influencer la décision. La clé est l'API QTKit, qui repose intensément sur le concept d'intention.

Les versions 1 à 7 de QuickTime utilisent une seule représentation interne pour toutes les ressources média : un objet Movie. Cette représentation inclut une information sur les pistes individuelles qui constituent le film, les tables d'échantillonnage pour chaque piste, et ainsi de suite - tout ce dont QuickTime a besoin pour comprendre et manipuler le média.

Ça paraît bien, jusqu'à ce que vous réalisiez que pour faire quoi que ce soit avec une ressource média, QuickTime nécessite la construction complète de cet objet Movie. Par exemple, considérons la lecture d'un fichier MP3 par QuickTime. QuickTime doit créer sa représentation interne de l'objet Movie du fichier MP3 avant de pouvoir le restituer. Malheureusement, le format MP3 contient rarement une information complète sur la structure des données audio. C'est seulement un flux de paquets. QuickTime doit laborieusement passer en revue et analyser le flux audio dans sa totalité pour créer l'objet Movie.

QuickTime 7 et les versions antérieures rendent le processus moins pénible en procédant à la lecture et à l'analyse en tâche de fond, de façon incrémentale. Vous pouvez constater cela dans de nombreuses application qui s'appuient sur QuickTime Player, sous la forme d'une barre de progression superposée au contrôleur de visualisation. L'image ci-dessous montre le chargement d'un podcast MP3 de 63 Mo dans la version Léopard de QuickTime Player. La portion grisée de la barre remplit lentement la zone pointillée de gauche à droite.

Plus que nécessaire

QuickTime 7 en fait plus que nécessaire.

Bien que la lecture puisse commencer presque immédiatement, (à condition de commencer au début), cela vaut le coup de revenir un peu en arrière, et de considérer ce qui se passe. QuickTime est en train de créer un objet Movie adapté à n'importe quelle opération que QuickTime peut entreprendre ; l'extraction ou l'addition de pistes, l'exportation, et tout ce que vous voulez. Mais si vous voulez seulement jouer le fichier ?

Le problème, c'est que l'API QuickTime 7 manque d'un moyen d'exprimer ce genre d'intention. Il n'y a aucun moyen de dire à QuickTime 7 "Ouvre seulement ce fichier aussi vite que possible pour que je puisse l'entendre ou le visualiser. Ne t'embarrasse pas à lire chaque octet, à l'interpréter et à en définir la structure, pour le cas où je voudrais en éditer ou exporter le contenu. S'il te plaît, ouvre le, seulement pour le relire".

L'API QTKit fournit exactement cette possibilité. En fait, la seule façon d'obtenir un rendu de QuickTime X est d'exprimer explicitement votre intention de ne pas faire ce que QuickTime X ne sait pas gérer. Qui plus est, toute tentative d'effectuer une opération dont vous n'avez pas préalablement exprimé l'intention provoquera une exception de la part de QuickTime X.

Le mécanisme d'intention est aussi la manière dont les nouvelles possibilités de QuickTime X sont rendues visibles, comme la capacité à charger de façon asynchrone des fichiers de films énormes ou distants (autrement dit sur lien internet lent), sans bloquer l'interface utilisateur qui utilise le fil (thread) principal de l'application.

De plus, il y a beaucoup de raisons de faire ce qu'il faut pour pouvoir monter à bord du train QuickTime X. Pour les formats de média qu'il supporte, QuickTime X est moins pénalisant pour le processeur pendant la lecture que QuickTime 7. (C'est indépendant du fait que QuickTime X ne gâche pas son temps à se préparer une représentation interne du film pour éditer ou exporter, quand on ne veut que le relire). QuickTime X dispose aussi de la possibilité de lecture accélérée par les GPU du format H 264, dans sa version de base, uniquement pour les Macs équipés s'un GPU NVIDIA 9400 M (c'est à dire quelques iMacs de 2009, et plusieurs modèles de Mac Books de 2008 et 2009). Et pour finir, QuickTime X inclut aussi un support Color Sync étendu pour la vidéo, qu'on attendait depuis longtemps.

Le facteur X

C'est seulement le début d'un long périple pour QuickTime X, qui n'y est apparemment pas très bien adapté. Un moteur QuickTime sans possibilité d'édition ? Pas de greffons ? Cela semble ridicule de l'avoir proposé, tout simplement. Mais c'est la manière de faire d'Apple depuis quelques années : un progrès régulier, délibérément. Apple affectionne de ne pas proposer des possibilités avant que leur temps ne soit venu.

Aussi impatients que les développeurs puissent être pour un moteur 64 bits complet capable de succéder à QuikTime 7, Apple est lui-même assis au sommet d'une des plus importantes base de code de l'industrie, basée sur QuickTime (et rajoutée au départ à Carbon) : Final Cut Studio. De ce fait, il reste condamné au 32 bits. Dire qu'Apple est "hautement motivé" à étendre les possibilités de QuickTime X serait sous-estimer les choses.

Néanmoins ne vous attendez pas à ce qu'Apple se rue de l'avant inconsidérément. Reproduire les fonctionnalités d'une API vieille de 18 ans, et développée de façon continue ne va pas se faire du jour au lendemain, et cela va demander encore plus longtemps pour que chaque application importante de Mac OS X soit mise à jour pour utiliser exclusivement QTKit. Les transitions, il vous faut les aimer que diable !