Journal En évoquant Facebook

Posté par Philip Marlowe le 24 janvier 2018 à 19:35. Licence CC By‑SA.

Étiquettes : aucune

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 = 2³ × 3² × 5² × 7²
192 000 = 2⁹ × 3 × 5³
Donc leur plus petit commun multiple est 2⁹ × 3² × 5³ × 7² = 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 ®om (site web personnel) le 24 janvier 2018 à 20:56. É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 Philip Marlowe le 24 janvier 2018 à 22:29. Évalué à 7. Dernière modification le 24 janvier 2018 à 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 Philip Marlowe le 24 janvier 2018 à 22:38. Évalué à 4.
    
    Ah j'avais zappé la partie concernant NTSC. Ça m'aura agréablement occupé cinq minutes.
# Tu oublies le NTSC

Posté par vpinon le 24 janvier 2018 à 22:00. Évalué à 6.

Et le grandiose 29.97=30*1000/1001
- [^] # Re: Tu oublies le NTSC
  
  Posté par fcartegnie le 25 janvier 2018 à 10:11. É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 Zenitram (site web personnel) le 25 janvier 2018 à 07:28. É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 Zenitram (site web personnel) le 25 janvier 2018 à 07:56. É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 flagos le 25 janvier 2018 à 08:57. É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 pulkomandy (site web personnel, Mastodon) le 25 janvier 2018 à 09:10. É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 Zenitram (site web personnel) le 25 janvier 2018 à 09:11. Évalué à 9. Dernière modification le 25 janvier 2018 à 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 Philip Marlowe le 25 janvier 2018 à 10:14. Évalué à 3.
  
  Merci pour les corrections.
# virgule flottante 42

Posté par KiKouN le 25 janvier 2018 à 16:30. É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 .Nicolas. le 25 janvier 2018 à 19:38. Évalué à -10.
  
  Personne ne leur a appris que c'était mathématiquement impossible ?
  - [^] # Re: virgule flottante 42
    
    Posté par KiKouN le 26 janvier 2018 à 12:35. É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 .Nicolas. le 26 janvier 2018 à 13:03. Évalué à -7.
      
      J'avais bien compris…
  - [^] # Re: virgule flottante 42
    
    Posté par j_m le 27 janvier 2018 à 08:44. É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 Victor STINNER (site web personnel) le 27 janvier 2018 à 03:34. É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 .Nicolas. le 28 janvier 2018 à 16:50. É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 Victor STINNER (site web personnel) le 27 janvier 2018 à 03:31. É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 / divLe 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 Tonton Th (Mastodon) le 27 janvier 2018 à 11:54. É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/
- [^] # Re: Nanosecondes
  
  Posté par Michaël (site web personnel) le 28 janvier 2018 à 17:47. Évalué à 5. Dernière modification le 28 janvier 2018 à 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 .Nicolas. le 28 janvier 2018 à 22:48. Évalué à -2. Dernière modification le 28 janvier 2018 à 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 Jehan (site web personnel, Mastodon) le 29 janvier 2018 à 15:33. Évalué à 6. Dernière modification le 29 janvier 2018 à 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 VictorAche le 31 janvier 2018 à 16:41. Évalué à 2. Dernière modification le 31 janvier 2018 à 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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.