Voilà le paysage que j’ai vu par ma fenêtre en me levant ce matin… Oui, il neige en Normandie. Ce n’est pas exceptionnel, mais j’adore ça !
Ah, Vivement les vacances au ski !

Au passage, vous pourrez noter la formidable qualité de mon APN… Un Revio C2 (1Mpixel, 16 Mo de mémoire, optique fixe) que ma mère m’a gentiment ramené du Japon il y a 3 ans… Un téléphone portable fait mieux (sauf mon T610), mais il a au moins le mérite d’exister 😉

Voici une visite en photo du GooglePlex, le campus de Google…

C’est le paradis des Geeks !!!

Mais je me demande s’il y en a qui travaillent là dedans ??? Où alors ceux qui travaillent vraiment sont enfermés à la cave ???

Ah, c’est vraiment le fléau de notre monde virtuel…

Comme Choiz ou Rno, ce blog est aussi victime du Spam…
J’ai donc décider de mettre en place un test de turing nommé captcha (oui, ça s’éternue en un seul mot !!!)…
Ce test, contrairement à beaucoup d’autres, fait plus appel à votre intelligence qu’à vos talent de Champollion !!! Il vous suffit de répondre à une question simple, écrite dans un texte lisible… Le principe de ce test tient dans le fait que peu de spameurs s’amuse à faire des robots capables de comprendre notre belle langue 😉
Franchement, là, si ça ne marche toujours pas, je ne sais pas quoi faire…

Oui, je sais, je ne suis jamais très inspiré pour faire de long titres…

• CreamMonkey est pour Safari, l’équivalent de GreaseMonkey (qui lui est pour Firefox)… C’est a dire un système qui permet d’afficher des sites en utilisant des filtres pour les rendre plus beau, plus ergonomique, ou pour disposer de fonctions supplémentaires… Dans le principe, c’est un Javascript qui se charge de défigurer le site…
  C’est intéressant, mais il est dommage de voir que les scripts CreamMonkey et GreaseMonkey sont incompatible. Par contre, pour le nom, je vois pas pourquoi Cream….
• Wikicalc est un Wiki / Tableur à la sauce Ajax… Impréssionant et par Dan Bricklin, le créateur de VisiCalc (pour les non culturé, le premier tableur 😉 )…
• J’ai bossé un peu sur le proxy rtsp2http…
  J’ai ajouté le support de connexion multiples (via des threads) et un système de re-connexion automatique si la liaison avec la Freebox est interrompue.
  Le multi-connexion n’est pas du tout testé… Mais au moment ou j’écris ces ligne, je me rend compte qu’il ne marchera pas car tout les threads essaye d’écouter sur le même port UDP… Bref, à revoir…
  Par contre, je me suis aperçu que je devais, pour maintenir la liaison RTSP avec la Freebox plus de 30s, envoyer des paquets de réponses toutes les 5s… Ce paquet donne des infos sur le dernier paquet reçu, etc… Donc, je crois que je vais définitivement être obliger d’interpréter un peu plus le header…
  Comme d’habitude, c’est disponible ici (download)

Le transfert n’est pas rapide, mais c’est compensé par une MTU de presque 9Go…

Via Make:

• Une vidéo d’un disque dur en marche… Je savais que les têtes de lecture bougeaient très vite, mais c’est toujours impressionnant à voir !
• Emuler .Mac… C’est possible. iDisk est remplacer par un (ou plusieurs) partage WebDAV. iCal publie dans aussi dans WebDAV et un script CGI permet de faire fonctionner Backup. Pour arriver à cela, une classique attaque de type « Man in the Middle » a permis de faire croire à Backup qu’il causait à .Mac et a donc permis d’analyser le protocole… Malheureusement, bien que la même attaque ait été réussi contre iSync, personne ne semble avoir réussi à faire le script CGI pour faire fonctionner iSync… Pour l’instant ;-)…
  J’ai bien envie de me monter un .Mac perso avec plein de place et surtout un accès rapide de chez moi (vu que le serveur serait en local…)
• J’ai trouver le problème de mon proxy RTSP vers HTTP. Premièrement, le protocole RTP possède un en-tête de 12 octets pour chaque paquet émit. Deuxièmement, le buffer que j’utilisais pour stocker les paquets UDP reçu était trop petit… Le script mis à jour est visible ici (téléchargement).
  Il me reste plus qu’à lui faire gérer les connexions multiples et à l’embarquer dans mon routeur Asus WL500g

Hier soir, je n’arrivais pas à dormir… J’ai donc décidé de regarder la Freebox sur mon portable, en Wifi depuis mon lit…

Le problème en Wifi, c’est qu’il y a beaucoup trop de paquets perdus… et comme le flux est en UDP, ils ne sont pas retransmis… Donc, ça coupe tout le temps et on a toujours plein de gros carrés.

Je me suis donc mis en tête d’écrire un petit proxy RTSP vers HTTP. Mon postulat de départ est simple. En HTTP, grâce a une liaison TCP, la qualité devrait être meilleur, vu que les paquets perdus sont retransmis (en contrepartie, il faut un buffer pour pouvoir attendre que tout les paquet soient arrivé et dans l’ordre avant de les jouer, mais ça c’est le player qui s’en occupe…). D’autre part, le fait de disposer d’un flux http devrais permettre de lire le flux avec des players qui ne gèrent pas le RTSP (comme QuikTime Player ou des périphériques dédié). Enfin, je me suis dit que l’écriture d’un truc comme ça devait être simple est marrante…

J’ai donc commencé à essayer de le faire en C… Puis je me suis rappelé le nombre de lignes de code qu’il faut aligner avant de pouvoir mettre en place un socket, et aussi que la gestion des string était inexistante… J’ai donc décidé d’essayer d’écrire ça en python… Comme je viens de me mettre à ce langage, je me suis dit que ça pouvait être un bon exercice…

L’algorithme est plutôt simple :

• On met en place un socket serveur pour attendre une connexion HTTP de la part du client
• On récupère l’url demandé par le client, et on lui renvois le header de réponse
• On se connecte à la Freebox, et on demande a jouer le flux demandé (via l’url)
• On met en place un socket UDP prêt à recevoir le flux de la Freebox
• Et enfin, on répète toutes les données envoyées sur le port UDP vers le client

Voilà le code que ça donne (Télécharger) :

import socket import sys # une petire class de serveur qui me simplifie un petit peu le travail class server_socket(socket.socket): 	def __init__(self, arg): 		if not type(arg)==tuple: 			self.socket=arg 		else: 			self.socket=socket.socket(socket.AF_INET, socket.SOCK_STREAM) 			self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) 			self.socket.bind(arg) 			self.socket.listen(1) 	def accept(self): 		s, addr=self.socket.accept() 		return server_socket(s), addr 	def readline(self): 		"""receive and return a complete line""" 		line="" 		while 1: 			char = self.recv(1) 			if not char: 				if line=="": 					return False 				return line 			if char==" ": 				return line 			if char!="
": 				line += char 	def __getattr__(self, name): 		return getattr(self.socket, name) # une petite class de client.. la même que pour un serveur, sauf l'initialisation class client_socket(server_socket): 	def __init__(self, ip, port): 		self.socket=socket.socket(socket.AF_INET, socket.SOCK_STREAM) 		self.socket.connect((ip,port)) # une class qui essaye de comprendre les réponses au requettes RTSP class basic_rtsp_socket(client_socket): 	def __init__(self, ip, port): 		client_socket.__init__(ip, port) 		self.cseq=1 	def request(self, request): 		print " ".join([">>> %s" % x for x in request.split(" ")]) 		self.send(request % self.cseq) 		self.cseq+=1 		l=self.readline() 		print "<<< %s" % l 		(proto, code)=l.split(" ")[0:2] 		if proto[0:4]!="RTSP": raise "Error: not a rtsp response", l 		if code!="200": raise "Error: rtsp error", l 		l=self.readline() 		print "<<< %s" % l 		header={} 		while l!="" and l!=None: 			l2=l.split(": ") 			if len(l2)!=2: raise "Incorrect response", l 			header[l2[0]]=l2[1] 			l=self.readline() 			print "<<< %s" % l 		if l==None: raise "rtsp connection closed by foreign host", None 		data=None 		if "Content-length" in header.keys(): 			data=read(int(header["Content-length"])) 		return (header, data) # Début du code # on met en place un serveur http http_listen=server_socket(("", 8082)) http_conn, addr = http_listen.accept() print 'Connected by', addr data = http_conn.readline() if not data: raise "no data on http line", None # on prend la première ligne (request, url, proto)=data.split(" ")[0:3] if request!="GET": 	raise "Error : not a get request", data if proto[0:4]!="HTTP": 	raise "Error : not a http request", data # on attend la fin de la requette # soit une ligne vide # un peu barbare... mais je suis qur qu'il ren a dire d'interressant l=http_conn.readline() print "<<< %s" %l while l!="" and l!=None: 	l=http_conn.readline() 	print "<<< %s" % l 	# parle a ma main !!! if l==None: raise "http connection closed", None # on repond le header http_conn.send("""HTTP/1.0 200 OK Content-type: application/octet-stream Cache-Control: no-cache """) # on établie la connexion rtsp rtsp_session=client_socket("mafreebox.freebox.fr", 554) print "connected to the rtsp session" # dump du dialogue RTSP entre VLC et la freebox... (header, data)=rtsp_session.request("""OPTIONS rtsp://mafreebox.freebox.fr/freeboxtv%s RTSP/1.0 CSeq: %s User-Agent: rtsp2http v0.0.1 """ % (url, "%d")) (header, data)=rtsp_session.request("""SETUP rtsp://212.27.38.253/freeboxtv%s RTSP/1.0 CSeq: %s Transport: RTP/AVP;unicast;client_port=1662-1663 User-Agent: rtsp2http v0.0.1 """ % (url, "%d")) session=header["Session"] # on se prépare a recevoir les connexion UDP rtsp_data = socket.socket(socket.AF_INET,socket.SOCK_DGRAM) rtsp_data.bind(("", 1662)) # Go, go, go (header, data)=rtsp_session.request("""PLAY rtsp://mafreebox.freebox.fr/freeboxtv%s RTSP/1.0 CSeq: %s Session: %s Range: npt=0.000- User-Agent: rtsp2http v0.0.1 """ % (url, "%d", session)) # on repete tout au client http ok=True while ok: 	data, addr=rtsp_data.recvfrom(1024) 	if addr[0]==socket.gethostbyname("mafreebox.freebox.fr"): 		try: 			http_conn.sendall(data) 			# il y a peut etre besoin d'une conversion... 			# mais j'espere pas... 			# a creuser 		except: 			ok=False # une execption... on arrete tout ! # une des connexion a été coupée, on ferme toutes les connexions... rtsp_session.request("""TEARDOWN rtsp://mafreebox.freebox.fr/freeboxtv%s RTSP/1.0 CSeq: %s Session: %s User-Agent: rtsp2http v0.0.1 """ % (url, "%d", session)) rtsp_session.close() rtsp_data.close() http_listen.close() http_conn.close() 

Pour l’instant, VLC arrive à se connecter, le proxy se connecte à la Freebox et commence à répéter le flux… mais rien a ne s’affiche à l’écran…

Bon il était déjà 2h30 et maintenant, j’avais vraiment envie de dormir… Mission réussie… Je suis aller me coucher 😉

J’ai deux piste à creuser pour essayer de faire marcher ça : Vérifier que toutes les données sont bien retransmises (problème de taille de buffer, ou de vitesse (paquets dropé) par exemple), ou vérifier si je peux bien renvoyer le flux brute de cette façon, et s’il ne faut pas le convertir et el remettre en forme…

Affaire à suivre 😉

Update 12/02/2006 : J’ai débugé le script.
Update 21/02/2006 : Quelques modifications.

Sur la mailing liste de Rotomalug, Aurélien Moreau se demande quel est l’intérêt du passage à la 3D pour un desktop… Il vrai qu’a première vue ça n’apporte rien… C’est pour cela que je pense qu’un petit éclaircissement est nécessaire…

Le problème, c’est qu’actuellement, les cartes vidéo n’offre plus aucune accélération matérielle en 2D… Si tu veux affiche une fenêtre en 2D, il te faut compter uniquement sur le CPU… Et le CPU, il a pas que ça a faire…

A coté de la partie 2D dans une carte vidéo, il y a la 3D… La 3D est beaucoup plus rapide que la 2D, même pour faire de la 2D… De plus, la 3D est en constante évolution… Elle prend plus de 95% du silicium d’une puce de carte vidéo…
Donc, l’idée est de codé dans la partie 3D (via de l’open GL) toutes les fonctions graphiques… Que ce soit la gestion des fenêtres ou les primitives de dessin…

La carte vidéo dessine beaucoup plus vite que le CPU. Par exemple, appliquer un flou sur une image dans Gimp prend quelques secondes (voire minutes sur des effets plus complexes)… La plupart des effets de Gimp peuvent être fait instantanément (genre à 60 images traitées par seconde) via la carte vidéo… Ce qui veux dire aussi que de tels effets peuvent aussi être appliqué en temps réel sur chaque images d’une vidéo… Toutes les machines vendues depuis 4 ans ont des cartes capables de telles prouesses mais elles sont inutilisées… Pourquoi ne pas les utiliser ?

D’autre part, certains prédisent même que la partie 2D des cartes vidéo va disparaître dans un futur proche (au moins une fois que les PC se seront débarrassés de leur BIOS (qui utilise toujours le mode 2D) pour booter le PC) au profit de l’EFI).

MacOSX (oui, je radote encore) implémente déjà ces technologies… Pour bien comprendre de quoi il retourne, je vous invite a lire l’excellent article (et aussi la page suivante) de ARS Technica présentant l’architecture mise en jeu… Ce qu’ils disent la s’appliquera bientôt aussi a Linux. Je peux dire que c’est une véritable avancée en matière de performance, même sur une petite machine (Je parle de mon PowerBook 1.3Ghz)… Donc oui, je suis convaincu que ça apporte vraiment beaucoup !

Pour info :

Je viens d’effectuer, avec l’aide de Jürgen Schweizer, la traduction en Français de Xyle scope…
Xyle scope est un outil permettant de débugger et d’analyser les feuilles de styles (CSS) pour les pages Web… J’en avais déjà parlé dans un billet précédent.
La nouvelle version de Xyle scope est donc désormais disponible en Français. Il me reste encore l’aide à traduire pour une prochaine version…

Cette traduction n’est pas figée dans le marbre. Il est possible que certain texte ne soit pas forcément très clair… Ce n’est pas facile de toujours trouver le bon mot (J’ai appris grâce a cette traduction, qu’il est plus facile de traduire des phrases que des mots ou des bouts de phrases)… Bref, si vous avez des commentaires, ou que vous trouvez des fautes d’orthographe, n’hésitez pas à le souligner avec vigueur dans un commentaire à ce billet ou via un petit mail…

Enfin, Xyle scope n’est pas un logiciel libre, mais je pense qu’il est important de supporter les développeurs indépendant qui, comme Jürgen, mettent toute leur énergie pour faire des logiciels performants et innovants. Un bon logiciel a parfois un prix (en plus, là, il est vraiment pas élevé !)…

Essayez Xyle scope

J’ai passé la majeure partie de ce samedi après midi à me documenter sur les bindings Cocoa…. Au terme de cette lecture, je ne regrette qu’une chose, que cette technologie ne soit pas disponible dans GNUStep… 😉

• Le design du Web2.0… Dégradé, bords arrondis, grandes polices sans serif… Le bougre, il a raison, c’est vraiment à la mode en ce moment !
• Le point sur l’affichage sous Linux (ou en anglais, The State of Linux Graphics, car certaines phrases ne sont pas vraiment claires dans la traduction) est plus une liste exhaustive des défauts de X11 de nos jours ! L’auteur explique notamment que les cartes graphiques modernes sont plus rapides en traitement 3D qu’en 2D. Sa proposition est de créer un serveur graphique basé sur OpenGL. Il a d’ailleurs commencé avec Xgl… Malheureusement, ce projet ne semble pas encore utilisable.
  Il propose de revoir complètement l’architecture graphique de Linux pour la rendre plus puissante, maintenable et sécurisée. Selon lui, les drivers vidéo devrait être intégrées au Kernel au lieu d’être en espace utilisateur dans X11 (ça me semble ahurissant que ce ne soit pas le cas !). Le Kernel devrais fournir une API uniformisé et stable. Toutes les fonctions de cette API qui ne sont pas disponibles sur la carte graphique sont faites en logiciel. L’API proposé (mais il explique qu’il pourrais y en avoir d’autre) est l’OpenGL avec un mapage des fonctions non matérielles vers Mesa… De plus il voudrait que le serveur X utilise les fonction HotPlug fournit par le Kernel…
  Il est vrai que niveau affichage, actuellement, Linux ne tiens pas la route face à MacOSX ou le futur Windows Vista…
  J’en ai rêvé toutes la nuit, d’un bureau Linux accéléré OpenGL et supportant le HotPlug (branchement à chaud des périphériques d’entrées bien sur, mais aussi des écrans, changement de résolutions à la volée, etc…).
• Et pour vous mettre l’eau a la bouche, voici ce que ça pourrais donner : Preview des wobbling windows. Ceux qui disent que ça ne sert à rien n’ont rien compris… Ici ce qui est intéressant, ce n’est pas de déformer les fenêtres, c’est plutôt d’avoir un affichage capable de composer les fenêtres en utilisant le GPU au lieu de la carte graphique, ou encore de pouvoir utiliser l’accélération OpenGL pour des bibliothèques de dessin vectorielle comme Cairo… Bref ce que fait déjà Quartz (même si une grande partie de l’interface est en fait composé de Bitmap) et ce que promet Vista… Avec les résolutions des écrans qui augmentent sans cesse (1920×1200 sur un 15″ !!!), il va être temps de quitter le monde du bitmap pour passer au vectoriel. Bref il est temps que l’unité de mesure pour l’affichage ne soit plus le pixel, mais le centimètre !!!

Bon j’arrête un peu de rêver et je retourne bosser !!!