Journal En évoquant Facebook

Posté par . Licence CC by-sa.
Tags : aucun
16
24
jan.
2018

Facebook a inventé une unité de mesure de temps, le flick (je me retiens de faire un jeu de mots facile à propos de son activité principale). Le flick est 1/705 600 000 de seconde. Quel intérêt ? Celui de représenter toutes les périodes de framerates usuels en nombres entiers de flicks. Le fichier flicks.h liste les framerates considérés de 1/24 à 1/192 000, soit :

//! 1/24 fps frame: 29400000 flicks
//! 1/25 fps frame: 28224000 flicks
//! 1/30 fps frame: 23520000 flicks
//! 1/48 fps frame: 14700000 flicks
//! 1/50 fps frame: 14112000 flicks
//! 1/60 fps frame: 11760000 flicks
//! 1/90 fps frame: 7840000 flicks
//! 1/100 fps frame: 7056000 flicks
//! 1/120 fps frame: 5880000 flicks
//! 1/8000 fps frame: 88200 flicks
//! 1/16000 fps frame: 44100 flicks
//! 1/22050 fps frame: 32000 flicks
//! 1/24000 fps frame: 29400 flicks
//! 1/32000 fps frame: 22050 flicks
//! 1/44100 fps frame: 16000 flicks
//! 1/48000 fps frame: 14700 flicks
//! 1/88200 fps frame: 8000 flicks
//! 1/96000 fps frame: 7350 flicks
//! 1/192000 fps frame: 3675 flicks

Une petite réflexion rapide montre que de savants calculs ne sont pas nécessaires, il faut trouver le ppmc de 88 200 et 192 000, les autres nombres étant de manière évidente des diviseurs de l'un ou de l'autre.
88 200 = 23 × 32 × 52 × 72
192 000 = 29 × 3 × 53
Donc leur plus petit commun multiple est 29 × 32 × 53 × 72 = 28 224 000
Le rapport entre 705 600 000 et 28 224 000 est de 25.

Chers amis, quel est le framerate caché qui motive un tel apparent gaspillage ?

Repéré ici, merci Frandroid.

  • # Contraintes

    Posté par (page perso) . Évalué à 10.

    Chers amis, quel est le bitrate caché qui motive un tel apparent gaspillage ?

    This unit of time is the smallest time unit which is LARGER than a nanosecond, and […]

    https://github.com/OculusVR/Flicks/blob/master/README.md

    blog.rom1v.com

    • [^] # Re: Contraintes

      Posté par . Évalué à 7. Dernière modification le 24/01/18 à 22:30.

      Non, c'est faux. La plus petite unité de temps qui satisfasse cette contrainte est 1/987 840 000.
      987 840 000 = 2⁹ × 3² × 5⁴ × 7³

      • [^] # Re: Contraintes

        Posté par . Évalué à 4.

        Ah j'avais zappé la partie concernant NTSC. Ça m'aura agréablement occupé cinq minutes.

  • # Tu oublies le NTSC

    Posté par . Évalué à 6.

    Et le grandiose 29.97=30*1000/1001

    • [^] # Re: Tu oublies le NTSC

      Posté par . Évalué à 2.

      C'est pourtant écrit "~29.97", donc l'unité ne peut être utilisée sans entraîner d'erreur à long terme.

  • # Corrections

    Posté par (page perso) . Évalué à 9.

    Celui de représenter toutes les périodes de bitrates usuels en nombres entiers de flicks.

    bitrates --> framerates
    usuels --> usuels en dehors de la TV US (point de 24000/1001, 30000/1001, 60000/1001…) qui est juste un énorme marché, donc des besoins finalement assez à eux car ils ont choisis ce qui les intéressent…

    • [^] # Re: Corrections

      Posté par (page perso) . Évalué à 9.

      Je m'auto-corrige, je n'avais pas regardé le code source, seulement le journal, et les TV US sont bien prises en compte, 30000/1001 est possible.

    • [^] # Re: Corrections

      Posté par . Évalué à 6.

      usuels --> usuels en dehors de la TV US (point de 24000/1001, 30000/1001, 60000/1001…) qui est juste un énorme marché, donc des besoins finalement assez à eux car ils ont choisis ce qui les intéressent…

      Quand tu parles de TV US, ca concerne uniquement le signal analogique non ? Si c'est le cas, ca doit commencer a être un pas si gros marché que ca et clairement pas l'avenir, non ?

      • [^] # Re: Corrections

        Posté par (page perso) . Évalué à 7.

        Et non, le HDMI conserve plein de machins débiles venus de là, y compris les framerates. Peut-être que le prochain standard dans 60 ans permettra enfin de s'en débarasser.

      • [^] # Re: Corrections

        Posté par (page perso) . Évalué à 9. Dernière modification le 25/01/18 à 09:12.

        Quand tu parles de TV US, ca concerne uniquement le signal analogique non ?

        J'ai en fait été trop limitatif (mais voir quand même mon auto-correction pour le sujet du journal) : TV US et tout ce qui en découle.
        Regarde le frame rate de tes Blu-ray, tu vas avoir un choc ;-)
        (spoiler: 24000/1001 pour la plupart)
        Note que ça ne veut pas dire que je comprend pourquoi ils s'amusent à ça, l'inverse (adapter la vidéo Blu-ray aux TV US) me semblerait plus logique de nos jours vu que c'est tourné en 24 et que c'est largement possible d'adapter si jamais ça ne supporte pas au niveau TV (sachant que le blu-ray, le HDMI, les écran LCD etc supportent 24 en plus du 24000/1001). Un jour on le tuera de 1000/1001, un jour…

    • [^] # Re: Corrections

      Posté par . Évalué à 3.

      Merci pour les corrections.

  • # virgule flottante 42

    Posté par . Évalué à 4.

    L'un des grands intérêts d'une telle mesure est d'éviter les calculs ( et les imprécisions qui viennent avec).

    https://linuxfr.org/users/chrtela2/journaux/le-retour-de-la-vengeance-de-la-virgule-flottante

    Il est plus intéressant de gérer soit-même où la virgule flottante se trouve que de laisser faire le cpu. Surtout en NTSC.

    • [^] # Re: virgule flottante 42

      Posté par . Évalué à -10.

      Personne ne leur a appris que c'était mathématiquement impossible ?

      • [^] # Re: virgule flottante 42

        Posté par . Évalué à 3.

        Il manque un bout de ma phrase .

        L'un des grands intérêts d'une telle mesure est d'éviter les calculs en virgule flottante ( et les imprécisions qui viennent avec).

      • [^] # Re: virgule flottante 42

        Posté par . Évalué à 1.

        Personne ne leur a appris que c'était mathématiquement impossible ?

        Qu'est ce qui est mathématiquement impossible? Pour ce qui est des framerates, ca a l'air d'être réussi.

    • [^] # Re: virgule flottante 42

      Posté par (page perso) . Évalué à 9.

      J'ai notamment écrit la PEP 564 "Add new time functions with nanosecond resolution" pour Python 3.7 car le type float de Python (IEEE 754) perd de la précision quand on manipule des dates avec une précision d'une nanoseconde.
      https://www.python.org/dev/peps/pep-0564/

      Python 3.7 permet maintenant de lire l'heure sous forme d'un nombre de nanosecondes, nombre entier (int), plutôt qu'un nombre de secondes, nombre floattant (float).

      • [^] # Re: virgule flottante 42

        Posté par . Évalué à -7.

        C'est une très bonne chose. Merci pour ton travail.

        Il faut absolument sortir de ce modèle du tout float. Mon message était ironique, visant ceux qui, dans les journaux précédents (plusieurs centaines de commentaires!), prennent un état de fait pour une réalité mathématique.

  • # Nanosecondes

    Posté par (page perso) . Évalué à 10.

    Je bosse sur le projet Python qui manipule des durées dans des tas de format différents : time_t (secondes), timespec (secondes et nanosecondes), timeval (secondes et microsecondes), nombre de millisecondes (pour appeler poll()), etc. J'ai choisi d'utiliser le type C int64_t (appelé _PyTime_t dans pytime.c ci-dessous) avec une unité d'une nanoseconde (note : cette unité ne fait pas partie de l'API publique, c'est censé être interne).

    pytime.c:
    https://github.com/python/cpython/blob/a5293b4ff2c1b5446947b4986f98ecf5d52432d4/Python/pytime.c

    Les systèmes d'exploitation aiment la diversité. Windows fournit QueryPerformanceCounter() : nombre à diviser par QueryPerformanceFrequency() pour obtenir des secondes. En utilisant des nombres flottants, la division est facile à réaliser. Mais en utilisant des nombres entiers (_PyTime_t), euh, c'est plus difficile, surtout pour éviter un integer overflow (dépassement de capacité du type int64_t provoquant des erreurs de calcul). J'ai notamment écrit _PyTime_MulDiv() pour QueryPerformanceCounter() :
    https://github.com/python/cpython/blob/a5293b4ff2c1b5446947b4986f98ecf5d52432d4/Python/pytime.c#L46-L61

    Avec un peu de mathématique, on évite l'integer overflow en pratique :

    (ticks * mul) / div == (ticks / div) * mul + (ticks % div) * mul / div
    Le code gère 4 modes d'arrondi (_PyTime_ROUND_HALF_EVEN, _PyTime_ROUND_CEILING, _PyTime_ROUND_FLOOR, _PyTime_ROUND_UP) car en plus, selon le besoin, il faut arrondir différemment… Depuis 2012, j'ai du corriger 4x les arrondis…
    https://vstinner.github.io/pytime.html
    (cet article date de février 2016, il ne mentionne pas le dernier correctif de 2017)

    En utilisant l'Epoch Unix (1er janvier 1970) comme référence, ce type permet de stocker des dates de l'année 1678 à l'année 2262. Vous me direz que c'est largement suffisant. Sauf que Python fournit le module datetime qui gère des dates de l'année 1 à 9999. Pour ce module, il faut conserver le type time_t (qui peut être en 32-bit ou 64-bit selon la plateforme) pour gérer des dates "extrêmes". Bien sûr, jouer avec de telles dates provoque des soucis sur certaines plateformes comme Windows, AIX ou Solaris.

    Le noyau Linux a un type opaque ktime_t https://lwn.net/Articles/167897/ mais ce type n'est pas (forcément) un entier, et on ne peut pas écrire t1 + t2 ou t2 - t1, contrairement au type _PyTime_t.

    This type, found in , is meant to be used as an opaque structure. And, interestingly, its definition changes depending on the underlying architecture. On 64-bit systems, a ktime_t is really just a 64-bit integer value in nanoseconds. On 32-bit machines, however, it is a two-field structure: one 32-bit value holds the number of seconds, and the other holds nanoseconds.

    Gérer le temps, c'est simple ! Bon, maintenant on va parler des timezones et de changement d'heure d'été …

    • [^] # Re: Nanosecondes

      Posté par (page perso) . Évalué à 5.

      Gérer le temps, c'est simple ! Bon, maintenant on va parler des timezones et de changement d'heure d'été

      Un peu de lecture instructive à ce sujet : http://www.catb.org/esr/time-programming/

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: Nanosecondes

      Posté par . Évalué à 5. Dernière modification le 28/01/18 à 17:48.

      Sauf que Python fournit le module datetime qui gère des dates de l'année 1 à 9999.

      Qui les gère, mais vite fait:

      The papal bull of February 1582 decreed that 10 days should be dropped
      from October 1582 so that 15 October should follow immediately after
      4 October, and from then on the reformed calendar should be used.
      
      This was observed in Italy, Poland, Portugal, and Spain. Other Catholic
      countries followed shortly after, but Protestant countries were
      reluctant to change, and the Greek orthodox countries didn't change
      until the start of the 1900s.

      (Voir https://www.tondering.dk/claus/cal/gregorian.php, notamment la section “When did country X change from the Julian to the Gregorian calendar?” avec mention spéciale pour nos amis suédois!)

      Les calculs fait par Python datetetime ne sont probablement justes que pour l'époque contemporaine.

      • [^] # Re: Nanosecondes

        Posté par . Évalué à -2. Dernière modification le 28/01/18 à 22:49.

        Tant qu'on y est, dans la bizarrerie à tenir en compte tous les 6 mois : seconde intercalaire. Bizarrerie qui vous donnera une minute à 61s, et 23:59:60 est une heure parfaitement valide.

        • [^] # Re: Nanosecondes

          Posté par (page perso) . Évalué à 6. Dernière modification le 29/01/18 à 15:35.

          Ce n'est pas tous les 6 mois malheureusement (sinon ce ne serait pas du tout un problème, car ce serait très facile à prendre en compte si justement y avait une règle). C'est plus ou moins arbitraire dans le sens où c'est annoncé par un organisme d'astronomie. Ils le font en fonction de notre décalage horaire par rapport à la rotation terrestre, mais ça reste assez arbitraire avec décision humaine: par exemple si on est décalé du temps universel de 0,5 sec, cet organisme pourrait décider d'ajouter une seconde rapidement, ou d'attendre que l'écart grandisse un peu plus. Tant qu'il reste sous 0,9 sec, c'est bon. Donc on ne peut pas prévoir ces secondes, qui doivent être annoncées.

          En pratique, ça arrive plutôt toutes les quelques années. C'est pas un truc régulier. Y a d'ailleurs un historique des secondes intercalaires sur le lien que tu donnes, et on voit bien que ce n'est arrivé qu'une seule fois avec 6 mois d'intervalles, lors de la mise en place du système. Ensuite y a eu aussi pas mal de secondes rajoutées à un an d'intervalle (je me demande si la terre était particulièrement lente à ce moment là, ou simplement on avait accumulé un écart de plusieurs secondes — ce pourquoi justement ce système aurait été introduit? — et ils ont essayé de le combler en quelques années).

          Mais dernièrement, ce sont des secondes avec beaucoup d'écart (j'en compte 6 dans les 20 dernières années et avec des intervalles pas du tout réguliers).

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Nanosecondes

            Posté par . Évalué à 2. Dernière modification le 31/01/18 à 16:43.

            Il y'avait bien 10 secondes de décalage à la création, rattrapées sur 5 ans tous les 6 mois edit: en fait non, au temps pour moi, 2 fois la première année mais ensuite les 7 (et pas 8) années suivantes au 31 décembre seulement !

            "The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.