Facebook est avant tout un réseau social. Mais, comme tout le monde le sait, l’entreprise est bien décidée à laisser son empreinte sur le monde, numérique et réel, et diversifie ses activités pour se donner les moyens d’y arriver. Malgré cela, personne ne pouvait vraiment s’attendre à ce que la firme de Mark Zuckerberg invente carrément une unité de temps baptisée « flick ».
C’est par l’intermédiaire de TechCrunch qu’on apprend que les équipes d’Oculus — qui appartient à Facebook — ont inventé le flick. Et le plus impressionnant dans tout cela, c’est que cette unité pourrait être beaucoup plus pratique qu’on ne pourrait le croire de prime abord. Car non, il ne s’agit pas de mesurer le temps qui passe entre deux posts Facebook publiés par un internaute. C’est bien plus pertinent.
1/705600000, ça fait combien ?
Le flick vaut 1/705 600 000 seconde. Évidemment, si on s’arrête là, on aurait du mal à comprendre l’intérêt de cette unité de temps. Mais, comme on peut le lire sur la page GitHub dédiée, ce chiffre peut être divisé par 8 ; 16 ; 24 ; 25 ; 30 ; 44,1 ; 60 ; 90 ; 120… On obtient à chaque fois un nombre entier, sans décimale. Et là, vous commencez peut-être à comprendre.
Vous avez déjà dû croiser les nombres listés ci-dessus sur des contenus multimédias, car on les utilise fréquemment pour parler de nombre d’images par secondes, de fréquences ou encore d’encodage : 24 images par seconde au cinéma, un écran 120 Hz ou un fichier audio à 44,1 KHz.
Flick pour décimer les décimales
Quand on calcule les fractions que l’on peut voir dans toutes ces mesures, on obtient inévitablement des résultats avec une suite de chiffres interminables derrière la virgule. Par exemple, les 24 images par seconde que l’on croise beaucoup dans les films, se traduisent par la fraction 1/24 qui équivaut à 0,04166666666 — la suite de 6 se répétant à l’infini. Pour plus de simplicité, on arrondit à 0,04167, ce qui n’est fatalement pas tout à fait exact d’un point de vue purement mathématique. Or nos machines et systèmes informatiques n’aiment pas ce genre d’imprécisions.
C’est là qu’intervient le flick. Car cette fraction 1/24 se traduit par 29 400 000 flicks tous ronds. Un framerate à 60 FPS ? La fraction 1/60 donne 11 176 000 flicks. 120 FPS font 5 880 000 flicks. Et ainsi de suite. Ces nombres assez longs ne sont pas faciles à retenir pour le cerveau humain, mais pour une machine ils sont parfaits, puisqu’ils sont entiers.
Harmonisation
Et le flick réussit à transformer presque tous les standards utilisés en nombre entier. Le but affiché est évidemment d’utiliser cette unité de temps à toutes les sauces afin d’harmoniser le tout.
Le format et le code du flick sont consultables et téléchargeables sur GitHub.
Rejoignez-nous de 17 à 19h, un jeudi sur deux, pour l’émission UNLOCK produite par Frandroid et Numerama ! Actus tech, interviews, astuces et analyses… On se retrouve en direct sur Twitch ou en rediffusion sur YouTube !
Ce que je voulais seulement dire c'est que l'unité manipule en fiat des nombres trop gros : rapidement on ne travaille plus sur des entiers (même en 64 bits) et on revient au problème de départ : traiter les nombres rationnels. Pas besoin de nouvelle unité, la seconde suffit, et les nombres rationnels existent déjà (même en Javascript, il suffit d'un tableau de 2 "number" comme [0,0] même pour continuer à avoir un résultat correct en cas de dépassement de capacité (en interne les "number" sont des flottants IEEE double standards, sur 64 bits qu'on n'est pas obligé de "normaliser à chaque changement d'échelle sur l'exposant binaire, ce qui permet des calculs rapides; les bibliothèques manipulant les rationnels existent déjà; pour écrire un codec audio/vidéo, il suffira de deux entiers 64 bits même pour faire des calculs intermédiaires avec des valeurs dans un intervalle entier de 32 bits; toutes les unités multiples ou sous-multiples évoquées par Facebook sont représentées exactement, sans aucun choix arbitraire d'un "PPCM magique") Les codecs ont bien d'autres choses à calculer que seulement le temps, et rien que la compensation de mouvement ou la compression prédictive (MPEG par exemple) nécessite de prendre en charge un nombre extrêmmeent élevé de sous-multiples possibles liant le temps à d''autres unités de mesure (taille des trames d'image o ude son, plusieurs temps de référence, temps réseau, marges d'erreur admissibles dans les transformées DCT ou FFT, approximations linéaires des courbes gamma (mêlant des segments linéaires et exponentiels et des discontinuités des dérivées...). La transformée de Facebook aurait un intérêt seulement si tout ce qu'on fait était un totalement linéaire, mais ce n'est pas vrai (courbes gaussiennes, exponentielles, logarithmiques, seuils, et d'autres données imprévisibles comme les erreurs de transmission et les délais réseau...)
Je suis d'accord avec toi et je pense que ta conclusion est exactement ce qui est marqué dans l'article. Le but n'est pas que les gens utilisent cette unité, donc on s'en fout de savoir s'ils vont facilement manipuler les millions. Cette unité a été créée pour avoir des résultats plus précis en langage machine. Donc ce sont juste les ordis / serveurs qui vont l'utiliser... (et en effet, seulement en interne facebook pour le moment)
Je pense que le NTSC, avec ses framerate multiples de 1000/1001, n'y ait pas pour rien :)
Le GitHub est un peu farfelus, il parle en premier : A flick (frame-tick) is a very small unit of time. It is 1/705600000 of a second, exactly. Puis après il donne la correspondance fps => flicks... donc fréquence ou unité de temps :p les deux mon capitaine ! 24 fps frame: 29400000 flicks 25 fps frame: 28224000 flicks 30 fps frame: 23520000 flicks 48 fps frame: 14700000 flicks 50 fps frame: 14112000 flicks 60 fps frame: 11760000 flicks
Encore un truc inutile : il ont juste utilisé un PPCM sujr un choix limité, et le prochain standard technique va tomber sur une unité qui ne tombera pas juste. Bref on revient aux secondes. "Pratique" vous dites ? pourquoi les machines ne peuvent-elles pas stocker non pas un entier mais deux (fraction) ou 3 (partie entière, et deux entiers par la fraction de l'unité). Et puis je ne suis pas convaincu que beaucoup de monde manipule facilement les millions ou les milliards. Bref on aura vite les "kiloficks", "mégaflicks", "gigaflicks" (pour compter en jours ou en semaines) sans compter la difficulté pour compter les années (de longueurs variables) et même les jours civils (qui ne sont pas exactement 24 heures), et on aura alors aussi les "kibiflicks", "mébiflicks", "gibiflicks"... Quant à l'orthographe : "flick", "flic", "flik", "flique".. Beacuoup vont hésiter. En gros c'est juste une unité tehnique interne à Facebook pour ses algos, qui n'en ont en fait pas besoin (tout dépend de la façon de représenter les nombres en interne)
<i>Enfin, le filck se prononce sept cent cinq millions six cent mille milliardièmes de seconde, et j'en suis presque sûr ;-).</i> Non. Si le flick valait 0,705400000 s on pourrait l'énoncer ainsi. Il vaudrait d'ailleurs mieux dire sept mille cinquante-quatre dix-millièmes de seconde dans ce cas. J'ai fait la même erreur que toi dans un premier temps.
Omar, votre formulation du flick comme un sept-cent-cinq millions quatre-cents millième (sans s, surtout) de seconde était finalement la bonne et c'est moi qui me trompais. Pour mieux comprendre il faudrait l'écrire (sept-cent-cinq millions quatre-cents mille)ième mais là ce serait une erreur de français.
Ah okay my bad !
Oui j'avais bien compris merci... :D Quand je disais "j'allais répondre", c'était j'allais répondre à "Demba GUISSE" et "ton commentaire était parfait", c'était le tien (Reggie) ^^
Non non c'est bien l'inverse de la fréquence, soit donc des secondes, qui est actuellement exprimé avec des chiffres à virgules (44.1 kHz ça veut dire 1 sur 44100e de secondes soit 2.2675737... *10^-5 secondes) ce qui n'est pas précis. A la place, avoir 16 000 flicks, ca serait mieux :)
J'allais répondre mais ton commentaire est parfait. C'est justement l'inverse qu'on recherche. Ce sont bien des nombres à virgule, mais ils cherchent justement à les remplacer par des nombres entiers.
Ça permet donc d'avoir des frames exactes ainsi que des secondes exactes (?) Et cette simple étape intermédiaire doit soulager d'une charge de calculs compliqués pour les processeurs (?) En tout cas ça ne semble pas fait pour le langage commun, mais dans les milieux liés à ces fréquences cela pourrait très vite devenir la norme idéale.
Bah si, toujours blâmer frandroid !
Le flick c'est chic !
C'est même plus qu'une unité de temps, si on parle d'images, etc. C'est une traduction d'une fraction pour la rendre plus facile à comprendre pour un système informatique.
Pas gentil de parler de tes parents comme ça !
[…] flick, c’est chic […]
Au 36 Quai des Orfèvres ils parlent déjà de superflicks. ?
oui ils expliquent pourquoi. C'est pour permettre un precision a 1/1000 de frame que tu vienne de 24 fps ou 120 fps, tout en restant entier.
oui, mais si tu n'es pas limite a un device / support qui demande exactement du 25 fps si tu lui balances du 24, alors avec cette unite ca devient trivial de determiner la date de debut d'afficage d'une frame, et la duree d'affichage de la frame.
Je suppose de toutes façons qu'on va rapidement arriver à parler de kiloflicks, méga flicks, etc.. Donc certes on aurait quand même pu enlever 3 zéros, mais finalement c'est pas si grave
Mais qui sont ils ?
oui, mais si tu n'es pas limite a un device / support qui demande exactement du 25 fps si tu lui balances du 24, alors avec cette unite ca devient trivial de determiner la date de debut d'affichage d'une frame, et la duree d'affichage de la frame. Ca me rend dingue la facon dont les videos sont charcutees pour pouvoir etre affichees sur tel ou tel device. Tu passes du temps a produire une video, tout ca pour qu'au moment de la diffusion, ca soit croppe, rallonge de 4%, qu'on enleve des frames par ci par la, voire qu'on rajoute des frames pour boucher les trous..
Pas du tout. Imagine que tu aies une vidéo source en 24 fps et que tu veuilles la diffuser sur un support à 25 fps : soit tu accélères la vidéo, soit tu ajoutes une frame. Et la façon la plus simple est d'en copier une => c'est ça qui donne une impression de "blocage"
ah j'ai compris ! flick ça veut dire "facebook like", c'est quand ils se sont rendus compte qu'il y avait 705600000 de likes par seconde sur facebook
Tout ça pour être flické au final...
l'article n'explique pas vraiment a quoi ca peut servir mais j'ai une idee Imagine que tu aies deux sources videos avec deux framerates differents, disons 24 et 30 que tu souhaites les afficher dans un oculus rift a 120fps, alors peut etre que ca permet de faciliter l'affichage et d'eviter le stutter / judder. Je vois tout le temps ca sur Youtube..
C'est pour ça qu'il existe les nombres à virgules fixes.
Ça fait cher le like...
les dinos sont toujours en vie !
Ça permet surtout à Facebook de mettre des chiffres ronds sur le temps passé sur Facebook par les utilisateurs : - temps nécessaire pour refuser les trois demandes d'amis que vous ne connaissez pas : 200000 flicks - temps nécessaire pour faire défiler les 6 news inintéressantes quotidiennes de vos amis: 250000 flicks - temps nécessaire pour uploader la photo de juniorette, 18 mois, qui gobe un escargot : 350000000 flicks - temps nécessaire pour un ado pour cliquer sur J'aime : 2000 flicks Ensuite, le flicks sert de base de monétisation pour les annonceurs : 1 flick = 1$
Un sujet plutôt passionnant, et bien expliqué, merci pour l'article.
Petite erreur dans l'article : 1/60 donne 11 760 000 flicks et non pas 11 176 000. Sinon ils expliquent dans leur spec pourquoi ils n'ont pas enlevé 3 zéros de partout ? parce que si on essaye toutes les fréquences d'exemple indiquées on a toujours un résultat en entiers supérieur à 1000, avec 3 zéros à la fin, donc 1/705600 ça serait passé aussi. Sinon l'idée est intéressante, finalement c'est comme de réaliser des équations en intégrant une variable Pi au lieu de sa valeur, puisque la plupart des données qu'on manipule autour sont "juste" des nombres décimaux.
Bonjour, ce n'est pas le flick qui est divisible par 8, 16, 44,1 etc ... mais le diviseur (705600000). Ensuite, en fin d'article il y confusion en FPS et durée d'un frame, comme il y souvent confusion entre fréquence et période. 60 ou 120 FPS ça dure toujours 1 seconde, donc 60 ou 120 FPS dure toujours 705600000 flick. Par contre la durée d'un frame n'est pas la même. 1 Frame à 60 FPS ou 1 Frame à 120 FPS valent bien un multiple entier du flick. Enfin, le filck se prononce sept cent cinq millions six cent mille milliardièmes de seconde, et j'en suis presque sûr ;-).
si il existe toujours des decimales, car meme si 44.1 peut etre ramené a un entier en multipliant par une puissance de 10, comment faire avec 0.1666666666.. par exemple ?
Ça fait combien de flicks?
En soit les calculs sur des flottants en informatique on évite autant qu'on peu... Une addition entière c'est un cycle processeur tandis qu'une addition flottante c'est 3 cycles sur du x86. J'aurai tendance à dire que chaque projet "qui manipule des images" a sa propre manière de les discrétiser pour éviter de manipuler des flottants. À voir si l'unité de Facebook percera.
On te dit que le résultat de la division est un entier, pas que le diviseur est un entier. Même si ici il l'est puisque l'unité est le hz et pas le khz. À partir du moment où le résultat de la division par 44,1 est un multiple de 1000, il n'y a rien de faux.
Perso, j'appelle ça de la branlette intellectuelle!!! Marc, quand tu nous tiens!!
L'article ne présente pas 44,1 comme un nombre entier, vous avez mal lu. Il indique que quand on divise le flick par 44,1 alors on obtient un nombre entier.
Je crois que tu n'as pas compris l'intérêt :) C'est pas le 44,1kHz qui pose probleme, qui est d'ailleurs 44100Hz, mais le temps en secondes que prend cette fréquence, soit 1/44100 secondes. C'est pas un chiffre que tu utilisera dans la vie de tous les jours, ce sont les logiciels qui utilisent ça. Ce résultat vaut ici 0.00002267573 et des poussieres, ce qui n'est pas précis, et en multipliant ça par 44100 on ne retombe pas sur exactement 1 seconde. Or, si on dit que c'est égal à 16000 flicks, ou encore 16 000/705 600 000e de secondes, on tombe bien sur un chiffre rond qui correspond à 44100 battements par seconde. Meme raisonnement pour 24/25/60/120 fps (toujours une fraction de 1/24 , 1/25e etc de seconde qui ne sont pas ronds) et tous les autres chiffres cités.
On ne va pas vous blâmer pour si peu. L'article est de qualité et la blague "photo" sympa. ;-)
Si c'est pour avoir une unité qui nous balance 10 chiffres ..... Je préfère rester au système actuelle ^^ Mais bon je faisais juste la précision que dans l'article, il présentait un nombre à virgule comme étant un nombre entier ^^
Oui chef :-*
Le but est justement de se débarasser des nombres à virgule. 44,1kHz vaut 16 millions de flick..
Houla oui. Mille pardons pour ça, je corrige.
Je suis là pour troller, pas pour réfléchir. Trump est mon mentor la terre est plate et le réchauffement climatique c'est faux. OK ?
En divisant 705 600 000 par 44.1 on arrive à 16 000 000
Essaie toi même avant de râler :) 705 600 000 / 44.1 = 16 000 000
44.1kHz = 44100Hz, donc nombre entier
Certes, mais dans l'article c'est écrit 44.1 Donc....
"44,1 [...] on obtient à chaque fois un nombre entier" Ah ouais... Bien les gars !
"Quand t’as compris comment marcher le flick" Waouh, vous réinventez la langue française, vous ! :-D
Sinon, il y a les nombres à virgules fixes en programmation. Elles ne donneront peut-être une valeur précise, mais elles permettent d'utiliser des entier, et de définir la précision que l'on veut atteindre pour son application.
Facebook vient de découvrir le fixed-point, l'entier, et les valeurs machines...Et maintenant veut se l'approprier. A quand un brevet ?
44.10 khz est un nombre décimal ......
Ce contenu est bloqué car vous n'avez pas accepté les cookies et autres traceurs. Ce contenu est fourni par Disqus.
Pour pouvoir le visualiser, vous devez accepter l'usage étant opéré par Disqus avec vos données qui pourront être utilisées pour les finalités suivantes : vous permettre de visualiser et de partager des contenus avec des médias sociaux, favoriser le développement et l'amélioration des produits d'Humanoid et de ses partenaires, vous afficher des publicités personnalisées par rapport à votre profil et activité, vous définir un profil publicitaire personnalisé, mesurer la performance des publicités et du contenu de ce site et mesurer l'audience de ce site (en savoir plus)
En cliquant sur « J’accepte tout », vous consentez aux finalités susmentionnées pour l’ensemble des cookies et autres traceurs déposés par Humanoid et ses partenaires.
Vous gardez la possibilité de retirer votre consentement à tout moment. Pour plus d’informations, nous vous invitons à prendre connaissance de notre Politique cookies.
Gérer mes choix