Le 10/12/2014 à 23h 47

lossendae a écrit :



C’est quand mieux comme explication. On est sur NXI, pas dans un colloque de développeur…





C’était surtout visé à l’auteur de l’article plus qu’aux lecteurs !

C’est une drole d’idée de se lancer dans des calculs bizarres quand on ne sait pas comment marche un négatif en binaire :)

Le 10/12/2014 à 18h 05

lossendae a écrit :



  “Si tu sais, partage !”





WikipediaC’est juste la méthode “universelle” (à part quelques architectures exotiques) d’encoder un négatif en binaire.

Et du coup, la valeur négative de Google marche.

Le 10/12/2014 à 18h 04

le podoclaste a écrit :



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 09/12/2014 à 16h 21

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 à 21h 08

David_L a écrit :



Ce sera aussi intéressant de voir avec d’autres implémentations du HEVC et des réglages différents d’un simple mode auto comme c’est le cas ici " />







Le code de référence est dispo normalement, et tout se règle si on y prend le temps. Par contre, il rame franchement…



Edit: Avec un petit lien pour faire riche:

http://hevc.hhi.fraunhofer.de/

Le 06/09/2013 à 21h 06

linkin623 a écrit :



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)

Le 06/09/2013 à 18h 52

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é !