Généralement, la taille du int s’adapte à celle du processeur cible, même en C. En 32 bits, il fera 4 octets, en 64, 8. Quand au double, il a toujours fait 64 bits, pour autant que je sache.
Après, (corrigez moi si je me trompe) à moins de devoir être sauvegarder en binaire, ça n’a pas d’incidence d’utiliser des types de données de taille inférieure à celle de ton processeur. Un proco 32 bits, gère les données 32 bits par 32 bits, donc utiliser un short comme compteur de boucle for ne sert à rien.
En pratique non. En pratique rien ne garantit la taille de l’int. C’est un choix fait par le compilateur.
La norme C te garantit que char <= short <= int <= long <= long long
Et que long est >= à la taille des pointeurs.
(On zappe au passage que rien n’empeche de faire un processeurs avec des pointeurs 32bits qui sait faire du calcul en 64bits nativement et vice versa)
En pratique en i686, et x86_64, PPC (et arm je suppose) char=1B, short = 2B, int = 4B, long=taille du pointer, long long = 8B.
Pour ton deuxième point c’est faux aussi. Si ton type de base est 4B, tu as quand même normalement des instruction pour charger/sauvegarde 1B, 2B, en mémoire. Tu fais potentiellement les calculs en 4B dans tes registres, mais ca ne change pas la place mémoire que ca prend. C’est le cas des Intel aujourd’hui.
Faire un short pour un compteur de boucle ne sert en pratique pas à grand chose, parce qu’il est en général dans ta stack et n’a qu’un impact mineur sur la taille globale.
Stocker des gros tableaux/structure de data pile à la bonne taille, ca peux par contre faire une grosse différence !
Le 265 permet de gagner de la place, mais au détriment de la qualité. Certes, moins de perte que les précédents codes à bitrate équivalent, mais ça ne remplacera pas le 264 de si tôt.
Choucroute ?
Le gain en place n’a rien à voir avec la perte de qualité.
Le concept de H.264/H.265 c’est que la plupart des infos dont tu as besoin pour encoder une image existent déjà dans les images d’avant ou dans d’autres morceaux de l’image courante. Du coup, pas la peine de les répéter, mais simplement te trouver la référence, et d’encoder la différence.
En limitant les fonctionnalités d’un encodeur H.264, tu peux te retrouver à utiliser les mêmes algo que le H.264.
Le H.265 rajoute surtout des nouveaux modes pour trouver/encoder ces fameuses références. Ca n’a rien à voir avec la qualité.
Normalement, un encodage loss-less (du coup à qualité égale) d’un flux vidéo aura quand même un meilleur bitrate en H.265 qu’en H.264
Après oui, dans un codec donné, plujs tu pourris la qualité, plus tu gagnes en place.. Mais ca c’est au choix de l’encodeur ! (Un petit réglage des QP et hop)
7 commentaires
Le 10/12/2014 à 23h47
Le 10/12/2014 à 18h05
Le 10/12/2014 à 18h04
Le 09/12/2014 à 16h21
Ce serait peut-être bien de faire un peu de lecture sur les compléments à 2 pour l’encodage des négatifs…
Ca évitera de sortir des valeurs mystiques de “16 616 803”
Le 06/09/2013 à 21h08
Le 06/09/2013 à 21h06
Le 06/09/2013 à 18h52
Fun comme article :) Je suis justement en train de porter/tweaker le code Rovi sur un proc many-core. La 4K HEVC à 60fps, c’est pas si loin que ca ;)
Concernant la qualité, c’est probablement juste une question de tuning des settings.
Le HEVC étant à la mode, ils ont probablement un peu forcer sur la compression en dépit de la qualité !