iTanguy a écrit 237 commentaires

En revanche, si les rumeurs que j'ai entendues pendant la phase de normalisation sont restées, il y a un changement significatif : la disparition des modes spécifiques pour les vidéos entrelacées ! Enfin la fin de ce mode issu des débuts de la télévision analogique et cathodique, et qui est désuet pour nos écran LCD ou autre (qui ne peuvent d'ailleurs pas le rendre correctement, introduisant moultes artefacts).

Y aurai-t-il quelqu'un qui puisse confirmer ?

La prédiction inter-image évolue, notamment sur les Motion Vector indiquant le déplacement des pixels à effectuer sur l'image de référence. Ceux-ci sont désormais donnés en précision de quart de pixel (au lieu de demi-pixel en h264) et peuvent désormais être plus grand (-8192..8192).

Il me semble que le quart de pixel était inclus dans H.264/AVC; il n'était pas disponible en MPEG-2, et optionnel (pas présent dans le premier profil simple mais à partir du profil Advanced Simple Profile) en "MPEG-4 part 2" (base de divx /xvid).

En revanche, l'efficacité du quart de pixel est légèrement améliorée dans H.265/HEVC, je crois, grâce à un filtre d'interpolation plus adapté qu'en H.264/AVC.

A vue de nez, le patch est inclus dans le noyau 3.5.6-1 qui est disponible depuis ce matin sous Archlinux.

Mission accomplie !
J'ai compilé un noyau en suivant les instructions du wiki https://wiki.archlinux.org/index.php/Kernels/Compilation/Traditional après avoir appliqué le patch https://launchpadlibrarian.net/118308181/hid-keep-dev_rdesc-unmodified-and-use-it-for-comparisons.patch mentionné dans le ticket Ubuntu.

Je sors tout juste d'hibernation avec mon nouveau noyau patché, et je m'apprête à cliquer sur "Prévisualiser".

Arf, je ne sais pas cliquer :

[ 81.850550] drivers/hid/usbhid/hid-core.c: report descriptor changed
[ 81.850552] usbhid 3-1:1.1: >reset_resume error 1

Ce qui confirme la piste évoquée dans les liens précédents.

Il en me reste plus qu'à réussir à compiler un noyau et à appliquer un patch…

Bon, c'est pas dans le noyau 3.5.5-1, même si d'après un commentaire la correction serait acceptée sur la branche 3.5 (mais le commentaire datant du 04 octobre, qu'il faut attendre la 3.5.6). Ou du moins, en noyau 3.5.5, j'ai toujours le problème.

J'ai activé les message de debug du module hid-core (qui s'appelle hid tout court, apparement), en suivant les instruction Archlinux du wiki https://wiki.archlinux.org/index.php/Kernel_modules#Configuration . Etrangement, je n'ai pas réussi à faire marcher la méthode des fichiers dans /etc/modprobe.d . Mais en rajoutant "hid.debug=1" dans GRUB, j'ai bien un message de plus :

Il y a déjà un post sur ce problème, apparement :
https://bbs.archlinux.org/viewtopic.php?id=149458
Je lis ça et après j'essayerai de voir comment continuer les choses…

PS: si ça se trouve c'est inclus dans le noyau 3.5.5 qui vient d'arriver sur Archlinux. Je n'ai pas encore eu le temps de tester.

Je suis tout à fait dans la même configuration, (Archlinux, 64 bit, souris Logitech sans fil), et depuis quelques semaines j'ai le même soucis (c'est donc clairement une régression… du noyau ou pas, je l'ignore). J'avais cherché rapidement sur les forums et dans mes logs, mais pour ma part je n'y avais pas trouvé de problème semblable, ni remarqué ta petite ligne "reset_resume error 1".

En attendant d'avoir du temps pour investiguer, j'avais renoncé à l'hibernation, mais je crois que je vais investiguer, comme toi. Même si j'ai jamais touché au noyau et apparentés sous Archlinux, ça va être rigolo :D

As-tu ouvert un ticket ou un post sur les sites Archlinux sinon ?

J'ai l'impression que, en dehors du problème éventuel (ça reste à prouver) d'infrastructure actuelles ou à venir, c'est le modèle de paiement en fonction de la bande passante qui est défaillant...

A mon avis, dans mon idéal, dans un mode libéral:

1) les usagers, ont un contrat avec leur FAI:
- pour un débit max donné: il paient pour pouvoir grimper jusque là, que ce soit du ;ode; old-school, de l'ADSL classique, du ADSL-Max ou Fibre très haut débit
- pour un débit minimum garanti (ce qui contribue rendre les abonnements pros plus chers)
- débits répartis d'une certaine manière entre upload et download (les abonnements sont + chers si l'upload est élevé
- ce débit devrait pouvoir être librement utilisé, pas de filtrage, puisqu'on a payé
- les services opérateurs (téléphonie et TV, VoD de l'opérateur ADSL) devraient être fournis sans nuire au débit minimum garanti

2) les fournisseurs de contenus (YouTube, Facebook, mais aussi les petits sites webs) ont un contrat avec leur FAI ou hébergeur:
- pour des trafics donnés (en Mo/jour), avec un facturation, un débit min, etc pour le trafic au delà
- pour (éventuellement) des débits min et/ou max
- pour n'importe quel type de traffic (dans les limites de la légalité, pour les hébergeurs)
- le coût de la bande passante est financé par le site: publicité, services payants, etc

3) entre 1) et 2), les réseaux opérateurs:
- qui peuvent assurer au moins les débits minimums contractuellement assurés à tous leurs clients (sans quoi c'est juste du vol)
- qui peuvent monter un peu vers les débits max
- et qui ne sont pas limités par les "peering" entre les opérateurs (si le peering est saturé, c'est le devoir de l'opérateur d'améliorer pour assurer le service qu'il doit à tous ses clients, et c'est financé par ce paient leurs clients pour leur bande passante).

J'ai parfois l'impression qu'en fait, les FAIs sont partis dans un modèle économique inadapté:
- les FAIs n'ont aucune obligation de débit minimal dans les abonnements ADSL grand public, brefs ils sont inattaquables si demain toutes nos connections sont à 56 kbs
- le modèle de peering ne marche pas...
- les gros fournisseurs de contenus ne paient probablement pas assez leur bande passante

Je suis peut-être très Bisounours baba-cool ce matin, mais qu'en pensez-vous?

Ma Meego 1.1 fonctionne au poil sur eeePc 900 et lui a donné de la fraîcheur par rapport au Xandros originel. Mais je triche, le diable est dans le détails: c'est EeePc 900A :)

C'est clair que l'intégration était très moyenne, sinon pourrie, de mon expérience.
J'ai une Asus EeepPC 900A que j'utilise pour les week-end hors de chez moi (famille, amis, étranger...). Je l'avais gardé en config d'usine sous Xandros; j'étais convaincu que si je jouais mon geek dessus je ficherai en l'air le wifi, héhé.
Au final il était extrêmement peu réactif (touch pad, freeze de 2-10 secondes et je ne parle pas de sites avec du flash) , a tel point que ma copine refusait presque de s'en servir.
J'ai fini par installer dessus un Meego il ya quelques mois; ben c'est le jour et la nuit! Certes ce n'est pas la même génération de Linux, mais le fait est que Xandros (ou son intégration) nuisait à la qualité du produit.

Nexus S: Autonomie de presque 18 jours en veille en 3G.
Parce que bon, 18h, c'est un peu court, à moins qu'on passe (enfin) la plupart de notre vie le téléphone portable éteint.

Bon, après mise à jour de la NeufBox, le service FTP est supprimé et remplacé par du partage "Microsoft" Samba. Bon, je dois pas être doué, car j'arrive à monter le disque, à lister les fichiers, mais pas à lire ou écrire, erreur:

cp /mnt/neufsmb/Yann\ Tiersen\ -\ Tout\ Est\ Calme/01\ -\ Plus\ Au\ Sud.ogg .
cp: cannot open `/mnt/neufsmb/Yann Tiersen - Tout Est Calme/01 - Plus Au Sud.ogg' for reading: Permission denied

Pourtant j'ai l'air d'avoir les droits:

ls -l /mnt/neufsmb/Yann Tiersen - Tout Est Calme/
total 0
drwxrwxrwx 0 itanguy users 0 Apr 10 15:04 01 - Plus Au Sud.ogg

J'ai monté ça avec cifs:

mount -t cifs -v --verbose -o rw,guest,domain=MONTROUGE,uid=1000,gid=100,forcegid,forceuid,noserverino,noperm,nounix,file_mode=0777,dir_mode=0777 //NEUFBOX/music /mnt/neufsmb/

mount.cifs kernel mount options: unc=//NEUFBOX\music,user=,ver=1,guest,domain=MONTROUGE,forcegid,forceuid,noserverino,noperm,nounix,file_mode=0777,dir_mode=0777,uid=1000,gid=100,ip=192.168.1.1

Et finalement, le pire (je suis dégoûté, mais plein d'espor pourtant), Firefox y arrive, lui! La vie est injuste...

smb://neufbox/music/Yann%20Tiersen%20-%20Tout%20Est%20Calme/01%20-%20Plus%20Au%20Sud.ogg

dans la barre d'addresse le lit le ogg correspondant... Du coup, me voilà dépité! PS: et dans la NeufBox, pas de de trace de réglage de login/passowrd ou de droits...

Ben j'ai lu deux tutos sur NFS et ça m'a semblé bien complexe.

Après, la NeufBox ne le propose pas...

Bem j'ai lu deux tutos et ça m'a semblé assez complexe à mettre en place.

Et surtout, la NeufBox ne le propose pas!

C'est surtout que la NeufBox ne propose pas NFS.

Après, ça m'a semblé un peu complexe à mettre en place aussi, mais oui, après ça marche bien.

Je vais dans ton sens:
C'est de l'HERESIE d'informaticien en manque.
C'est completement anti-pragmatique. En general, pour un probleme donné, c'est la solution la plus simple qui est la plus performante.

Avec du XHTTP par exemple ca donne:
a/ des requetes + difficillement generables qu'aujourd'hui
b/ des requetes plus grosses, qu'il faut donc compresser (gzip...), y compris les requetes qui etaient courtes
c/ de l'analyse de requetes plus compliquée: besoin de tout parser (valider le XML, et construire l'arbre en memoire) avant de traiter le contenu [ca necessite temps, ressources CPU, memoire]
bref, ca fait des proxys et des serveurs XHTTP avec un processeur 2 fois plus gros et 4 fois plus de memoire pour la meme performance qu'en HTTP...

Ce que je vois donc c'est une techno (XML) qui n'est pas efficace, donc inadequate, pour tout ce qui est un minimum intensif. Et pour compenser cette inadequation, ben tu colles au dessus une autre techno (compression) pour essayer de compenser le mal ta techno cherie!!! Cette techno inadequate introduit de la complexite en plus, et ca ca a un impact direct sur la performance en general.

Bref, "Keep It Stupid Simple" comme on dit

PS: sur ce qui est moins intensif, ca peut presenter un peu plus d'interet, px sur des fichiers de config... mais faut pas se leurrer, ca compliquera tt de meme les porgrrammes pour la generation et le parsage des fichiers, d'ou certainement un demarrage des applis et du systeme en general plus lent...

Perso je n'ai vu aucun des deux films, seulement les bandes-annonces
Et celle du dernier trappeur présente le film comme "l'histoire exceptionnelle d'un homme extraordinaire" et j'exagere a peine! C'est vachement axé sur l'homme, sa vie, son oeuvre... que sur la nature & cie. A tel point que ca ne m'a vraiment pas donné envie d'aller le voir!

J'avoue, c'est un private joke pour les habitants de Rennes-Patton, qui sont toujours censés être dégroupés "courant été 2004" (et encore, quand je me suis inscrit, c'était prévu pour Mars 2004).

Bah c pas nouveau, quand je me suis inscrit en decembre 2002 (sur pat35) c'etait annonce pour avril 2003! Quand ils s'y mettront enfin ma télé sera tombee en rade :-/

Toute la subtilite (et la difficulte) du watermarking est qu'il faut qu'il resiste au maximum a la distortion creee par la compression avec perte des codecs.
Bon, si c'est tres compresse, le watermarking ne sera plus detectable, mais normallement la qualite sera aussi completement pourrie...

ouaip, watermarking
d'ailleurs a ce qu'on m'a dit (des gens qui bossaient pour EMI) ils le font aussi pour les pressages en avant-premiere qu'ils filent a des journalistes et cie. Et ils constataient effectivement des fuites! (sans porter plainte pour autant)

(...) tous sauf h264+CABAC (..) utilisent un ditionnaire de huffman prédéfini, donc non optimal

Et encore, le Cabac utilise des modeles de probabilites predetermines, meme s'il les affine au fil du codage de chaque trame.

En meme temps ils piquent le code AVANT qu'il soit public (et commite sur cvs)... donc le code n'est pas encore libre et dispo (et ils le gardent pour eux, héhé)

reprenons:
pour passer de 29.97 a 30 fps ca nous fait une trame dupliquee toutes les 33.33 secondes
pour passer de 24.975 (=29.97*25/30) a 25fps ca nous fait une trame dupliquee toutes les 40 secondes
zut on est encore loin du compte :-/

Le cinema est tourne a 24fps (trames par secondes), et aux USA la tele est a 30fps.
Certains connaisent la manip du telecine pour passer de 24 fps a 30 fps (rajouter une frame toutes les 5 frames, meme si c'est un peu plus complique que ca grace a l'entrelacement).

Sauf qu'en fait la tele aux USA c'est pas 30 fps mais 29.97fps !!!
Alors bon ca fait 3 frames de trop toutes les 100 secondes si je calcule bien (?)
Donc c'est p-e pas ce qu'on cherche :-/ mais bon c'est peut-etre un truc du genre non?
surtout qu'avec une conversion 30->25fps en plus (la tele en europe etant a 25fps) on retombe p-e sur nos pattes? je sais plus faire le calcul...