
Recherche avancée
Médias (1)
-
Bug de détection d’ogg
22 mars 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Video
Autres articles (40)
-
Installation en mode ferme
4 février 2011, parLe mode ferme permet d’héberger plusieurs sites de type MediaSPIP en n’installant qu’une seule fois son noyau fonctionnel.
C’est la méthode que nous utilisons sur cette même plateforme.
L’utilisation en mode ferme nécessite de connaïtre un peu le mécanisme de SPIP contrairement à la version standalone qui ne nécessite pas réellement de connaissances spécifique puisque l’espace privé habituel de SPIP n’est plus utilisé.
Dans un premier temps, vous devez avoir installé les mêmes fichiers que l’installation (...) -
Publier sur MédiaSpip
13 juin 2013Puis-je poster des contenus à partir d’une tablette Ipad ?
Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir -
Prérequis à l’installation
31 janvier 2010, parPréambule
Cet article n’a pas pour but de détailler les installations de ces logiciels mais plutôt de donner des informations sur leur configuration spécifique.
Avant toute chose SPIPMotion tout comme MediaSPIP est fait pour tourner sur des distributions Linux de type Debian ou dérivées (Ubuntu...). Les documentations de ce site se réfèrent donc à ces distributions. Il est également possible de l’utiliser sur d’autres distributions Linux mais aucune garantie de bon fonctionnement n’est possible.
Il (...)
Sur d’autres sites (6495)
-
Anomalie #2880 (Nouveau) : Gestion du portfolio
22 octobre 2012, par Charles De ClercqConcerne : ajouter une image ou un document dans un article Lorsque j’ajoute un archive zippée contenant des illustrations, il y a la possibilité de cocher la case pour ajouter les fichiers (jpg en l’occurrence) dans le portfolio. Bug constaté : les fichiers sont d’office ajoutés au portfolio que la (...)
-
Stream video and commands on same connection or split connections ?
10 mai 2013, par bizzehdeeBackground
I am in the middle of writing a client/server app that i will install on every machine within my office (roughly 30 - 35 machines). I currently have the client connecting to the server and it has an ability to send mouse movement, mouse clicks, key strokes and execute certain commands. The next step is to stream back a video output of the screen, i am using the GDI method from Fastest method of screen capturing to capture the entire screen and will be using the x264 encoder to compress the frames and transmit them back to the client which will then decode and display the stream.
Question
is it best (by means of reducing lag, ensuring all commands are delivered as fast as possible and that streaming is as live as possible) that i transmit back along the same connection that i established for the commands, or, should i establish a separate connection on the same port, or on a different port to stream back the video ?
P.S.
i am aware that VNC, RD and other things such as TeamViewer already exist and already do this sort of thing, but none of these support all the requirements needed for what we need within this system.
-
Making Sure The PNG Gets There
14 juin 2013, par Multimedia Mike — GeneralRewind to 1999. I was developing an HTTP-based remote management interface for an embedded device. The device sat on an ethernet LAN and you could point a web browser at it. The pitch was to transmit an image of the device’s touch screen and the user could click on the picture to interact with the device. So we needed an image format. If you were computing at the time, you know that the web was insufferably limited back then. Our choice basically came down to GIF and JPEG. Being the office’s annoying free software zealot, I was championing a little known up and coming format named PNG.
So the challenge was to create our own PNG encoder (incorporating a library like libpng wasn’t an option for this platform). I seem to remember being annoyed at having to implement an integrity check (CRC) for the PNG encoder. It’s part of the PNG spec, after all. It just seemed so redundant. At the time, I reasoned that there were 5 layers of integrity validation in play.
I don’t know why, but I was reflecting on this episode recently and decided to revisit it. Here are all the encapsulation layers of a PNG file when flung over an ethernet network :
So there are up to 5 encapsulations for the data in this situation. At the innermost level is the image data which is compressed with the zlib DEFLATE method. At first, I thought that this also had a CRC or checksum. However, in researching this post, I couldn’t find any evidence of such an integrity check. Further, I don’t think we bothered to compress the PNG data in this project long ago. It was a small image, monochrome, and transferring via LAN, so the encoder could get away with signaling uncompressed data.
The graphical data gets wrapped up in a PNG chunk and all PNG chunks have a CRC. To transmit via the network, it goes into a TCP frame, which also has a checksum. That goes into an IP packet. I previously believed that this represented another integrity check. While an IP frame does have a checksum, the checksum only covers the IP header and not the payload. So that doesn’t really count towards this goal.
Finally, the data gets encapsulated into an ethernet frame which has — you guessed it — a CRC.
I see that other link layer protocols like PPP and wireless ethernet (802.11) also feature frame CRCs. So I guess what I’m saying is that, if you transfer a PNG file over the network, you can be confident that the data will be free of any errors.