briaeros007 a écrit 9441 commentaires

pas tous, mais croire qu'une grande part des ados n'est pas obnubilé par draguer, se la péter , être dans le mouv, etc... me semble surestimer légèrement l'humanité.

Les autres flux ne sont pas forcément propriétaire.
Je pense notamment au H.264 dont sa documentation est facilement téléchargeable gratuitement sur internet.
Le problème amha c'est plus les brevets que savoir comment ca marche dans ce cas la.

tu vas nous expliquer que la personne a relancer un serveur X sans autorisation root sur le port tty8, serveur X modifié pour overrider lorsque l'on fait un ctrl+alt+f1 getty/login ?

marrant parce que quand j'essaie de lancer Xorg sans les droits root

/usr/bin/Xorg -logfile /tmp/toto :8

X.Org X Server 1.4.2
Release Date: 11 June 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux Debian (xorg-server 2:1.4.2-7)
Current Operating System: Linux oni 2.6.26-1-686 #1 SMP Wed Sep 10 16:46:13 UTC 2008 i686
Build Date: 30 September 2008 01:48:58AM

Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/toto", Time: Tue Nov 4 21:36:21 2008
(==) Using config file: "/etc/X11/xorg.conf"

Fatal server error:
xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)


Et en faisant un strace, on voit qu'en essayant d'ouvrir /dev/tty0 il tombe sur un permission denied
strace /usr/bin/Xorg -logfile /tmp/toto :1 2>&1|grep EACCES
open("/dev/mem", O_RDONLY) = -1 EACCES (Permission denied)
open("/dev/tty0", O_WRONLY) = -1 EACCES (Permission denied)


Alors c'est peut être possible, mais beaucoup beaucoup beaucoup moins simple que refaire un interpreteur de commande qui verifie si on lance su ou /bin/su pour capturer le mdp.


Et sans vouloir être vexant si on part sur la parano complète moi j'ai 10000 fois mieux et plus simple : un keylogger.

mais si ton su ensuite fait appel au vrai ?

roh vous faites chier, on fait juste ctrl+alt+f1 et voila :P

Les particuliers n'achètent pas leurs logiciels, même propriétaires.
Et les entreprises pas forcément non plus :
combien d'entreprises utilisent avast free, windows sans licence , etc... ?

y'en a une pour la ps3 ?

les heures sups... une grande partie des personnes ne se font pas payer quand elles restent 10min/30min//.... après leur boulot, et je compte même pas les tpe qui ne sont pas soumis aux 35h.

amha ce que voulait dire asgeir c'est "la distrib t'offre le noyau, ensuite si tu veux des libs spécifiques (genre sdl)
-> tu demande à ce qu'elle soit installé (comme sous windows quand un installateur se plains que "MSVC40.DLL n'existe pas")
-> tu la "ship" avec ton jeu (comme les loki games).
Comme ces librairies sont librement redistribuable, ca ne pose pas de problèmes particulier.

J'ai pas testé depuis très longtemps openbsd donc je peux pas en dire grande, mais en ce qui concerne le discours de "voir la faq"
je suis le premier à dire d'aller voir la doc, mais si pour CHAQUE chose il faut aller voir la faq, et/ou si en voyant la faq il faut se taper 15 000 lignes avant d'avoir une info pertinente alors :
Même si la faq répond aux questions, il y a un sérieux problème.

Bref RTFM c'est bien, mais ça fait pas tout, loin de là.

sauf qu'il faut gerer plusieurs contenu emmêlé, à la suite, sans temps mort, et synchronisé.
La vidéo ne me semble pas si "im pertinente" que ça ;)

Pourquoi diantre est-ce que la pièce de cinq euros est un journal similaire à celui-ci? Ah oui, je vois: ça doit être parce que les brevets coûtent cher.
Non, parce que tu n'as pas fait de dépêches.
Un journal est un journal, une dépêche est une dépêche.

Tu as pensé à le proposé à la liste de diffusion de ffmpeg ?
(je l'ai lu vite fait, mais comme je suis loin d'être un pro là dedans, j'ai pas bcp d'avis dessus).

Et merde!
Ca m'apprendra a lire trop vite, j'avais pas vu le .c.tgz en bas.
Mea maxima culpa

Amha, il ne s'agit pas d'une "modification de ffmpeg" mais d'un "script utilisant ffmpeg pour encoder à destination de la PSP".

quand je parlais de Xvid, il s'agit de mpeg4.
ffmpeg a sa propre implémentation (que tu peux accéder avec mencoder en encodant -ovc lavc -lavcopts vcodec=mpeg4:...)

Sinon effectivement c'est plus clair ;)

Vlc peut essayer de faire de l'enco à la volée (mais moins performant que les routines optimisées de ffmpeg).
ffmpeg (ffserver) est censé pouvoir effectuer aussi ce streaming avec enco à la volée, mais la dernière fois que j'ai testé ffmpeg comme serveur de streaming , il aimait bien les segfault /o\
(un exemple de conf ffserver :
http://ffmpeg.mplayerhq.hu/sample.html ,dans notre cas ça sera "format avi", et si tu es sur de ne pas avoir de vidéo, alors active le VideoIntraOnly )

il y a aussi lscube (live.polito.it) qui semblait proposer ce genre de service (ils sont en dvp), mais leur site semble down /o\

Concernant MPEG-2, peut importe qu'il soit répandu ou non, puisque je suis libre d'installer ce que je veux, tant côté serveur que côté clients.
Je voulais surtout dire que tu as un (plus) grand nombre de solution (encoding/transmission/...) et que donc tu as un plus grand choix ;)

As-tu une idée d'un ordre de grandeur de consommation de ressources de Theora comparé à MPEG* ?
La dernière fois que j'ai essayé (une des premières beta), cela demandait plus de puissance que du xvid(mpeg4).
Il est possible que ça ait changé depuis le temps aussi.

pour tes clients, à vue de nez ils supportent le xvid 720p sans problème, je serais moins catégorique pour du h.264 (mais ils supporte du h.264 480p sans problème).
Pour l'encodeur, ben tout dépend de la machine, en sachant qu'a moins d'avoir des betes de guerre, encoder en temps réel le h.264 est relativement dure à atteindre.

En ce qui concerne les pertes, si tu adopte une stratégie de streaming (ce qui semble être le cas vu que tu essaie de faire d'après ce que j'ai compris un "live feed", cad affiché en presque temps réel une vidéo qui est capturée en live), alors tu ne peux pas utiliser TCP, cela entraine trop de délai et trop de traffic réseau.
De plus le vpn ne _doit pas_ être en tcp (tcp sur tcp c'est mal) , donc en udp.

Si tu ne cherche pas à faire du "live feed" (stockage des vidéos et acessibilité après), alors le plus simple c'est de mettre en place un répertoire partagée (nfs par exemple) ou chaque client ira récupérer la vidéo. La effectivement il n'y aura pas de problème de perte, mais dans ce cas je comprend pas très bien la contrainte d'encodage temps réel.

Si tu souhaite utiliser un système de stockage, alors n'importe quel conteneur peut faire l'affaire (le surpoids de chacun n'est pas ce qu'il y'a de plus important dans une simple vidéo).
Tu as le choix principalement entre trois conteneur
- avi (l'historique, peu de possibilité, mais suffisant pour une simple vidéo. Ne supporte pas tous les codecs).
- mp4 (le conteneur "officiel" du h.264. Plus évolué , plus adapté à l'envoi sur le réseau, mais pas parfait.
- mkv : conteneur libre, qui est le plus "performant" à l'heure actuel (support de presques tous les codecs, des st, possibilité de chapitrage, etc...).
Je te conseillerais le mkv, mais je ne connais pas d'outils qui permettent de créer un mkv avec "un pipe".

en ce qui concerne le fait que le contenu soit statique : c'est tout benef pour toi : un système de compression video se base sur le fait que deux images qui se suivent sont semblables.
Donc je te conseillerais d'augmenter au maximum le temps entre deux frames I (cad une frame qui contient une image au grand complet).



Pour résumer :
Si tous les clients doivent afficher la même vidéo en même temps
-> streaming (multicast si possible)
Si les vidéos proviennent d'une source qui capture en même temps (live feed,...)
-> streaming (multicast ou unicast)+ codec permettant d'encoder à la volée sur la machine d'enco.
Si les vidéos sont "offline"
-> streaming si archi déjà en place, réseau "correct"
-> répertoire nfs, vidéo préencoder.


Ps : en ce qui concerne théora : la qualité des MPEG est quand même très bien. Un Xvid/ lavc-mpeg4 bien encodé a une très bonne qualité, même a des bitrates "faibles".
faut voir si MSU (http://compression.ru/video/codec_comparison/mpeg-4_avc_h264(...) ou doom9 (http://www.doom9.org/index.html?/codecs-quali-105-3.htm, http://forum.doom9.org/showthread.php?t=140336, ...) a des comparaisons des codecs. Ils ont une bien meilleur opinion que moi des codecs ;)

1°) de combien veux tu économiser de la BP, si c'est pour transmettre sur un LAN ou tu vas envoyer que ça, alors un MPEG-2 semble le plus approprié :
-peu consommateur et en codage, et en décodage
-compression suffisante pour envoyer sur 10 Mbps
-codec "historique" => beaucoup de matériel/savent savent le lire

2°) la puissance nécessaire
- si tu as des machines de guerre, alors tu peux essayer des codecs plus efficaces comme le mpeg4 ou le mpeg4-avc (h.264). La consommation nécessaire est grosso modo la suivante
MPEG4=2-4x MPEG-2
MPEG4-AV=2-4x MPEG4

3°) Les pertes
Si ton réseau est soumis à perte ou modification , tu peux voir à
- augmenter la compression : on diminue le nombre de paquet a transmettre (un paquet modifié => un paquet perdu) , donc le nombre de paquet perdu diminue.... Mais le nombre d'information transmise par paquet est plus important. Par conséquent, une perte a(peut avoir) plus d'impact visuel.
- diminuer la compression , pour qu'une perte ait moins d'impact visuel.

tout dépend si les pertes sont dus à une congestion (trop de débit) , au médium, a ...

4°) La transmission
Il existe plusieurs moyen pour la transmission
- Tu peux essayer d'utiliser du multicast puisque c'est un producteur, de multiples consommateurs.
- Tu peux utiliser aussi du RTP/... en unicast
- Tu peux en outre essayer d'utiliser des mécanismes d'ARQ (récupérer des paquets perdu), mais la on commence a rentrer dans le lourd

par contre tu peux répondre dans le bon fil en cliquant sur "répondre" en dessous du message auxquel tu veux répondre :)

un forum Usenet binaire est une aberration inutile aux gens honnêtes, autant que je sache.
Tanguy Ortolo, l'homme qui sait ce qui est utile aux gens honnêtes.

si il n'y a pas de mouvements sur le compte, et que vu que les relevé sont envoyé en lettre simple, tu peux facilement prétexter la bonne foi :"j'ai rien reçu, donc je pensais qu'il n'y avait rien". Ca te fait tenir une bonne année comme ça :]

Ensuite j'avoue que je ne connais pas les délais légaux

Parce que la personne qui reçoit un placebo pendant le test ne sait par définition pas que c'en est un, et ne connait donc pas son prix ?
On peut très bien le faire autrement, cad en faisant un test qui ne semble pas être en double aveugle (tt façon faire un test en double aveugle pour des placebos XD), voir étudieur les deux séquentiellement, en lachant des phrases style "celui la est plus cher"

Toutes les entreprises ne sont pas toutes ultra rigide, par ex tu peux demander l'ouverture de port suivant les départements/pc etc.
Faut bien entendu que ce soit motivé, mais c'est loin d'être impossible.

normalement (en france en tout cas) c'est pas le commercant qui fait le scan etc... mais les banques.
Et ce sont les banques qui conservent les chèques (c'est d'ailleur la détentrice du compte qui garde les chèque d'un compte).

Et c'est pour ça tu peux voir de l'argent retiré suis à un chèque en bois :
La banque X recoit un chèque de la banque Y
La banque X crédite donc le compte sur lequelle est déposé l'argent et envoie le cheque à la banque Y pour être payé
La banque Y valide ... ou pas le chèque. Si elle ne le valide pas, la banque X débite le montant qu'elle avait crédité.
La banque Y stocke le chèque (je crois qu'ils stockent juste un scan maintenant mais je n'en suis pas sur).

je vais t'avouer un autre secret ... les chèques non plus (en dessous d'un certain montant).

Bon pour les chèques c'est plus compréhensif que pour un système qui peut être fortement informatisé.

Mais c'est très interessant pour toi.
Lorsque tu déménage, tu fais valoir que tu n'as JAMAIS signé d'autorisation => ils sont donc obligé de te rembourser :]