Hé! Autant commencer un nouveau fil! Était: Fiancement (soc) Logiciels
Libres. Ça n'a donc plus rien à voir.
Emmanuel Florac wrote:
> Le Fri, 20 Aug 2004 01:17:11 -0400, GP a écrit :
>
>
>> Bon! Quand tu finis par parler, on finit par se comprendre. Mais ce que
tu dis me surprend. J'ai discuté un peu de ça ailleurs et on me disait que
c'est Apple qui donnait un serveur streaming. Personne ne disait que
Microsoft donnait son serveur!
>
>
>
> Apple a publié les sources de son serveur de streaming.
Mais pas en GPL, je suppose...
> Il est très
> utilisé sous Mac OS X/Linux/Unix (mais il ne tourne pas sous windows).
> Mais Microsoft "donne" son serveur de streaming avec tous ses OS serveurs.
Ça, c'est comme dire que Explorer est /donné/... avec Windows.
> De plus, Microsoft donne aussi les outils d'encodage avec ses OS, ce qui
> n'est pas du tout le cas d'Apple ni de Real.
Ok, il faut donc payer pour encoder du QuickTine, on peut ensuite utiliser
un serveur sans frais, si c'est un Linux ou un des BSD.
Microsoft donne son codec et fournit son serveur avec Windows. Ce
serveur fonctionne seulement avec Windows et Windows est sous licence.
Or, il ne faut pas croire que la licence Windows de la SRC est la même
que celle de Joe Bleau qui diffuse de temps en temps un vidéo de sa
famille sur son site!
Microsoft, ce n'est pas du code libre. Il faut payer au pro rata du
travail accompli. Dans les bureaux, 100 secrétaires, ce n'est pas comme 1
secrétaire.
Les redevances pour distribuer des centaines de fichiers streaming à la
grandeur du pays, ne sont certainement pas les même que celles qu'on exige
de Joe Bleau, soit l'achat d'une copie de Windows.
Je me trompe peut-être? :)
Le serveur, il n'est pas libre du tout, il coûte des sous! Arrêtons
de rigoler!
Finalement, c'est simple. Microsoft te donne le codec, mais te vend le
serveur. Apple, te vend le codec, mais te permet ensuite d'utiliser
son serveur, un produit commercial payant, ou Linux.
Avec Microsoft, la licence s'applique sur l'OS. Faut passer à la
caisse de toute manière. Pass go, and... /pay/ $200! C'est une nouvelle
version du jeu de Monopoly.
Mais, parlant codecs, il y a Xvid et VP3 (ou 6, maintenant?) qui sont
libres. Il y a Dirac qui semble en préparation, avec un site chez
sourceforge. Le projet n'a pas l'air super actif:
Sauf que les deux premiers ne sont pas streaming, je suppose. Quel est
l'avantage du streaming? Y a-t-il un terme français pour cette
«technologie» ?
En tant qu'utilisateur, je trouve embêtant qu'on me serve des fichiers en
streaming. À aucun moment, je ne puis revenir en arrière. Pour réentendre un
passage, je dois tout réécouter. Parfois, c'est long...
Je ne puis même pas, normalement, sauver le fichier pour référence
future. Donc, à chaque fois que le veux le consulter, le serveur doit
me retransmettre le fichier.
Pourtant, un utilisateur de Windows me disait qu'un utilitaire permet de le
récupérer dans la cache. Alors, pourquoi ne pas le sauvegarder directement
sur le Desktop, maudit? (Au fait, y a-t-il un équivalent de cet utilitaire
sous Linux ou une procédure pour récupérer le fichier dans la cache? J'ai eu
plus de succès avec les fichiers swf qu'avec les fichiers streaming de la SRC.)
Donc, le streaming ne permet pas de préserver des droits. Les fichiers
peuvent être récupérés.
(Parenthèse)
On se souviendra que nous avons eu une longue discusssion ici sur la
possibilité de sauvegarder un fichier streaming. Quelqu'un a prétentu qu'il
était possible de récupérer ce genre de fichiers en remontant des fichiers
qui établissent des liens -- asx, ou je ne sais trop quoi -- aux fichiers
qui sont réellement servis.
Je n'ai jamais réussi à faire cela et les explications du sire ont
tourné court.
(Fin de la parenthèse)
J'ai de la difficulté à comprendre le concept même du streaming. En autant
que je sache, rien n'oblige à visionner un fichier avant qu'il soit
complètement arrivé.
Par exemple, lorsque'on reçoit une grosse page web -- disons 100 -150
k -- la page ne s'affiche pas tout d'un coup. On commence à voir le
début avant que la fin ne soit rentrée.
Pourquoi ne pourrait-il en être de même, très normalement, avec des
fichiers vidéo et/ou audio, sans ce qu'on appelle le streaming?
On semble parfois prétendre que le streaming, c'est la possibilité de servir
plusieurs /connections/ à la fois. Mais pourquoi ne pourrait-on faire cela
avec des fichiers qui s'enregistreraient simplement sur le desktop?
C'est vraiment renversant tout ce hype vis-à-vis d'un format dont on ne peut
même pas saisir l'utilité.
> Enfin et c'est le coup de
> grâce, pour obtenir un résultat comparable au coupe windows media
> server+player il faut sous windows installer le Quicktime Player...
C'est une affaire de rien, mais bien des gens s'arrêtent à la première
chose que MS leur fournit.
> Voilà, avec le windows media player installé par défaut sur tous les PC
> sous windows, et le windows media serveur sur tous les windows serveurs,
> la messe est dite : 99% des sites de streaming proposent du WMV en
> streaming. Parfois ils proposent aussi du Real, ou du Quicktime, mais le
> WMV est incontournable.
On laisse encore une fois MS jouer du coude pour exercer son monopole.
C'est le sujet du jour.
Est-ce que Windows Media Player n'a pas aussi des fichiers en extensions
.wmp et .wma? Quelles sont les différences selon les
extentions? Et les fichiers .avi est-ce que ça n'existe pas?
>> Toutefois, si j'avais en main un organigramme global, en grandes lignes,
>> de ce qui est disponible dans le propriétaire et l'open source, de ce
>> qu'il y a dans les enveloppes comme ogg et de ce qui y est propriétaire
>> ou pas, des avantages et désavantages du streaming versus... le
>> non-streaming, etc., ÇA M'AIDERAIT BEAUCOUP.
>
>
>
> Je comprends. Malheureusement je n'ai pas tellement d'urls, parce que je
> lis et je mémorise les information au fur et à mesure sur de longues
> périodes, pour me former un schéma global... Sur les problèmes du MPEG-4
et du WM9, cependant, une recherche sur
> arstechnica.com sur le sujet "DVD forum" te ramènera certainment pleins
> de liens.
J'ai lu un peu. Entre autres ceci:
In a move that has caught industry analysts off guard, Microsoft has
submitted Windows Media Series 9 to the Society of Motion Picture
Television Engineers (SMPTE), the body responsible for determining
standards in the video industry.
http://arstechnica.com/news/posts/1063508519.html
Ceci a été écrit il y a presque un an. Où en est cette offre de
Microsoft ?
> Pour ce qui est des formats, il faut distinguer les codecs (la manière
> dont la vidéo est traduite en chiffres)
Et, quand on tourne un vidéo binaire, l'encodage se fait-il
automatiquement au tournage? Si oui, quels sont les formats employés
par les grands manufacturiers? Sinon, qu'est ce qui se passe ensuite au
niveau ordi.
En un mot, qu'est-ce qui se passe de la caméra vidéo, amateur ou
professionnelle, jusqu'au visonnement sur l'ordi ou à la télédiffusion?
> du format d'encapsulation (la
> manière dont le tas de chiffres de la vidéo encodée est transporté).
Transporté... Habituellement, quand on dit ça, on parle réseaux...
Qu'est-ce qui se passe avec Ogg Vorbis et l'encapsulation ogm? Le
meilleur fichier vidéo que j'ai sur mon ordi, c'est un ogg, un trailer
de Futurama de Matt Groening. Mettons que c'est plus drôle que
d'écouter Rumsfeld :)
Je regarde ce vidéo en plein écran et la qualité me semble toujours
très acceptable. Le problème, c'est que, pour une durée de 75 sec., il
fait 9,3 Mo, ce qui correspond à un débit de 9,3 * 1024 * 8 / 75 =
1015 kbps. Or, nornalement, Radio-Canada diffuse sur internet en 44
kbps, je crois.
Évidemment, la SRC n'offre pas la même qualité. Mais du ogg --
laissons faire la question de streaming ou pas, ici -- à 44 kbps,
est-ce que ça ne vaudrait pas la qualité des fichiers Windows?
Actuellement, je suppose que ce n'est pas du WM9. Ce doit être
l'équivalent du standard mpeg-2, mais c'est vraiment pas fortiche.
(Parenthèse)
Depuis le début des olympiques, la Société Radio-Canada (SRC)
ne diffuse R_I_E_N de sa programmation régulière, sous prétexte que le
CIO refuse qu'elle diffuse ses reportages sur l'internet.
Un chroniqueur a tenté de m'éclairer à ce sujet, Apparemment, des
reportages rentrent d'Athènes à toutes les heures cinquante cinq
minutes. Il faudrait déconnecter l'accès au site de la SRC à ce
moment et les employés de la SRC auraient la flemme de le faire.
J'avoue avoir eu peine à suivre son raisonnement. Admettons même qu'il
faille opérer une sorte de rebranchement, est-ce qu'un simple script
/cron/ dans Linux ne pourrait pas faire cela? Est-il possible que
Windows n'offre pas l'équivalent de cron? J'en doute beaucoup.
Comme je l'ai déjà dit, je suis un complet ignorant en matière vidéo.
Je ne puis que poser des questions, je cherche à comprendre. Ici, je
mentirais en prétendant que je comprends.
Peut-être une prochaine chronique nous révèlera-t-elle les dessus de
l'affaire...
(Fin de parenthèse)
> Les codecs, par contre, sont en grande majorité très propriétaires et
> bardés de brevets, et les encodeurs disponibles (à l'exception de
> l'encodeur Windows Media) contre d'assez jolies sommes.
> Dans le domaine des codecs et depuis longtemps, le logiciel libre est
> très mal loti, et court derrière les systèmes propriétaires et
> brevetés...
Le format OGM, tu trouves que c'est «mal loti»? Et ce que le projet Theora
fait avec VP3 aussi?
> De plus, le frein principal à l'adoption d'un codec est sa disponibilité
> sur la plate-forme la plus répandue : MS Windows+Windows Media Player...
Sauf que là, on parle d'encoder les documents d'une société d'État. Alors,
soit que Microsoft offre codec et serveur en libre, soit que la SRC adopte
un format libre et offre le décodeur en téléchargement pour Windows si MS
refuse de le faire.
Ça ne doit pas être trop compliqué. Chaque fois que je demande un fichier,
je me fais présenter une fenêtre qui m'offre de télécharger Windows Media,
étant entendu qu'une fois sur le site de téléchargement, je ne trouverais
pas de décodeur pour Linux. Façon de dire aux newbies: «Achetez-vous donc un
OS moderne, qui performe vraiment.»
Et la télévision d'État fait affaire avec des gens comme ça, jusqu'à livrer
leurs messages de merde!
> La seule chose qui semble pouvoir avoir un effet sur l'adoption d'un codec
> si j'en crois l'expérience du passé (remember Sorenson Video V3 en 1998)
> c'est une grande supériorité technique sur la concurrence. Si des types
> arrivent à faire un codec libre qui enfonce vraiment WM9 (le meilleur
> codec à l'heure actuelle, gratuit et disponible d'office sur 95% des
> postes clients potentiels!), alors ils auraient une ouverture pour
> pénéter un peu le marché, et une raison de se faire entendre dans les
> discussions techniques.
Ce que tu racontes ici n'a aucun sens.
Note: La secrétaire du représentant du Conseil du Trésor m'a rappelé pour
avoir plus de précisions sur les enjeux. On tâche de bien cerner le problème.
Je vais te dire. Des fichiers video streaming qui font plus que 50 megs, il ne doit pas y en avoir des tonnes. Qui n'a pas 50 megs sur son disque?
Par exemple le streaming a souvent été envisagé dans le cadre de la set-top box, c'est à dire un petit boitier qu'on branche sur une télé, et évidemment dépourvu de tout stockage... Dans ce cas, bien sûr, pas moyen de faire autrement que de diffuser au fur et à mesure que ça arrive!
Misère! Va-t-on finir par sortir de cette galère? Comme je l'ai expliqué dans le cas de la grosse page web, est-ce qu'elle n'est pas diffusée en direct? En admettant qu'on puisse lire la page à la vitesse à laquelle elle s'affiche, est-ce que le début ne pourrait pas disparaître quand on lit la fin?
Oui, ça prend un peu de ram. Seulement, les set-top box modernes, ils ont non seulement du ram à revendre, ils ont même des disques durs de plusieurs G.
GP
Emmanuel Florac wrote:
Je vais te dire. Des fichiers video streaming qui font plus que 50 megs, il
ne doit pas y en avoir des tonnes. Qui n'a pas 50 megs sur son disque?
Par exemple le streaming a souvent été envisagé dans le cadre de la
set-top box, c'est à dire un petit boitier qu'on branche sur une télé,
et évidemment dépourvu de tout stockage... Dans ce cas, bien sûr, pas
moyen de faire autrement que de diffuser au fur et à mesure que ça
arrive!
Misère! Va-t-on finir par sortir de cette galère? Comme je l'ai expliqué
dans le cas de la grosse page web, est-ce qu'elle n'est pas diffusée en
direct? En admettant qu'on puisse lire la page à la vitesse à laquelle elle
s'affiche, est-ce que le début ne pourrait pas disparaître quand on lit la fin?
Oui, ça prend un peu de ram. Seulement, les set-top box modernes, ils ont
non seulement du ram à revendre, ils ont même des disques durs de plusieurs G.
Je vais te dire. Des fichiers video streaming qui font plus que 50 megs, il ne doit pas y en avoir des tonnes. Qui n'a pas 50 megs sur son disque?
Par exemple le streaming a souvent été envisagé dans le cadre de la set-top box, c'est à dire un petit boitier qu'on branche sur une télé, et évidemment dépourvu de tout stockage... Dans ce cas, bien sûr, pas moyen de faire autrement que de diffuser au fur et à mesure que ça arrive!
Misère! Va-t-on finir par sortir de cette galère? Comme je l'ai expliqué dans le cas de la grosse page web, est-ce qu'elle n'est pas diffusée en direct? En admettant qu'on puisse lire la page à la vitesse à laquelle elle s'affiche, est-ce que le début ne pourrait pas disparaître quand on lit la fin?
Oui, ça prend un peu de ram. Seulement, les set-top box modernes, ils ont non seulement du ram à revendre, ils ont même des disques durs de plusieurs G.
GP
GP
Emmanuel Florac wrote:
En téléchargement et d'une le partage (multicast) du fichier est absolument impossible
J'aimerais donc pourquoi on ne poirrait envoyer un fichier ordinaire en milticast. Car, pour le moment, dans le cas du streaming comme d'un fichier standard, tout ce que je vois, ce sont des bits qui rentrent sur l'ordi.
Si un ordi éprouvait des problèmes de réseau, fin de la transmission. Meilleure chance la prochaine fois! Un fournisseur qui n'a pas la bande passamte pour du 44 kbps, il ferait mieux de fermer ses portes.
et de deux le téléchargement se fait à la vitesse qu'il peut (en général la bande passante disponible soit côté serveur, soit côté client).
C'est pourquoi, comme pour le streaming, la diffusion de fichiers en multicast devrait se faire à des vitesses suffisamment basses pour que le réseau ne cause pas de problèmes.
Qu'est-ce que tu dis? Comprends-tu pourquoi le site de la SRC est complètement bloqué 24 h heures par jour parce que les capsules audio de 5 minutes seraient reçues d'Athènes une fois l'heure?
Le script qui pourrait régler le problème pendant deux semaines, ça prend combien de temps pour l'écrire. Dix ans ou quoi?
5 minutes. Mais qui est responsable de l'écrire? Qui est responsable s'il est cause d'une panne? Dans une grosse entreprise, personne ne fait jamais de modification de ce genre sans qu'il ne faille 6 mois de réunions, notes de services, etc, pour que les responsabilités soient diluées comme il se doit.
Ça, c,est un problèmeé Un responsable de la SRC m'a appelé ce matin à ce sujet, mais j'ai manqué son appel. Il est «très occupé» aujourd'hui et n'a pas retourné mon appel, tel que promis, ce midi. Mais il se pourrait même qu'il me rappelle ce soir.
Funalement, ça prend peut-être plus que 5 min pour écrire ce script :)
Xvid c'est du mpeg 4. Légalement, ils n'ont pas le droit de diffuser de codec librement et gratuitement, ils devraient payer des royalties aux ayant-droits du format mpeg 4. C'est pourquoi il ne diffusent pas de "logiciel" mais uniquement du "source".
Puisque le source peut-être compilé, je ne vois pas trop ce que ça change d'un point de vue légal.
Oui, on dirait que les développeurs Linux ne pas rentrés dasn la nouvelle vague. Je me demande si, comme moi, ils ne se demandent pas à quoi ça sert. le streaming.
Pas exactement. Disons qu'ils n'en ont pas eu besoin. Le streaming est surtout utile aux grosses boîtes, par définition.
Moi, je pense toujours que ce n'est utile à personne.
Et le .NET ça sert vraiment à quelque chose? Que personne ne m'ensevelisse de termes techniques et qu'on me dise ce que .NET permettra que la technologie actuelle ne permet pas.
..NET sert à des tas de choses, mais ça n'a aucun rapport avec le streaming.
Non... vrai? :)
Je propose qu'on en parle éventuellement dans un autre fil.
Je te laisse le partir.
Là encore, ils utilisent des librairies "pirates", parce que les spécifications ne sont pas disponibles, légalement on n'a pas le droit de regarder un wmv ou un mov sous linux.
C'est tout ce qu'il y a à dire. La SRC offre ses fichiers dasn un format qu'il est illégal de visionner autrement qu'avec des logiciels propriétaires.
C'est pour cette raison que ces codecs ne sont pas dispos dans les distribs officielles, et qu'il faut aller les chercher sur un site hongrois.
Et, finalement, ça fait l'affaire de Microsoft. Ainsi la SRC va prétendre que je peux visionner le format WM avec Linux. J'attends qu'ils me disent ça...
D'autre part, les gens qui comprennent les enjeux sont capables de compiler du source et sont portés à temporiser plus que s'il n'y avait aucune alternative. Ils se prêtent au jeu du chat et de la souris en prétendant s'en sortir ainsi. Les newbies, eux, restent avec Windows, parce que «Windows, c'est plus facile.» Ensuite, on se demande pourquoi Linux figure aussi bas au zeitgeist...
Pendant ce temps, l'Empire Microsoft s'étend. L'État tend sa laisse en demandant qu'on en fasse un esclave.
GP
Emmanuel Florac wrote:
En téléchargement
et d'une le partage (multicast) du fichier est absolument impossible
J'aimerais donc pourquoi on ne poirrait envoyer un fichier ordinaire en
milticast. Car, pour le moment, dans le cas du streaming comme d'un fichier
standard, tout ce que je vois, ce sont des bits qui rentrent sur l'ordi.
Si un ordi éprouvait des problèmes de réseau, fin de la transmission.
Meilleure chance la prochaine fois! Un fournisseur qui n'a pas la bande
passamte pour du 44 kbps, il ferait mieux de fermer ses portes.
et
de deux le téléchargement se fait à la vitesse qu'il peut (en général
la bande passante disponible soit côté serveur, soit côté client).
C'est pourquoi, comme pour le streaming, la diffusion de fichiers en
multicast devrait se faire à des vitesses suffisamment basses pour que le
réseau ne cause pas de problèmes.
Qu'est-ce que tu dis? Comprends-tu pourquoi le site de la SRC est
complètement bloqué 24 h heures par jour parce que les capsules audio
de 5 minutes seraient reçues d'Athènes une fois l'heure?
Le script qui pourrait régler le problème pendant deux semaines, ça
prend combien de temps pour l'écrire. Dix ans ou quoi?
5 minutes. Mais qui est responsable de l'écrire? Qui est responsable s'il
est cause d'une panne? Dans une grosse entreprise, personne ne fait jamais
de modification de ce genre sans qu'il ne faille 6 mois de réunions,
notes de services, etc, pour que les responsabilités soient diluées
comme il se doit.
Ça, c,est un problèmeé Un responsable de la SRC m'a appelé ce matin à ce
sujet, mais j'ai manqué son appel. Il est «très occupé» aujourd'hui et n'a
pas retourné mon appel, tel que promis, ce midi. Mais il se pourrait même
qu'il me rappelle ce soir.
Funalement, ça prend peut-être plus que 5 min pour écrire ce script :)
Xvid c'est du mpeg 4. Légalement, ils n'ont pas le droit de diffuser de
codec librement et gratuitement, ils devraient payer des royalties aux
ayant-droits du format mpeg 4. C'est pourquoi il ne diffusent pas de
"logiciel" mais uniquement du "source".
Puisque le source peut-être compilé, je ne vois pas trop ce que ça change
d'un point de vue légal.
Oui, on dirait que les développeurs Linux ne pas rentrés dasn la
nouvelle vague. Je me demande si, comme moi, ils ne se demandent pas à
quoi ça sert. le streaming.
Pas exactement. Disons qu'ils n'en ont pas eu besoin. Le streaming est
surtout utile aux grosses boîtes, par définition.
Moi, je pense toujours que ce n'est utile à personne.
Et le .NET ça sert vraiment à quelque chose? Que personne ne
m'ensevelisse de termes techniques et qu'on me dise ce que .NET
permettra que la technologie actuelle ne permet pas.
..NET sert à des tas de choses, mais ça n'a aucun rapport avec le
streaming.
Non... vrai? :)
Je propose qu'on en parle éventuellement dans un autre fil.
Je te laisse le partir.
Là encore, ils utilisent des librairies "pirates", parce que les
spécifications ne sont pas disponibles, légalement on n'a pas le droit
de regarder un wmv ou un mov sous linux.
C'est tout ce qu'il y a à dire. La SRC offre ses fichiers dasn un format
qu'il est illégal de visionner autrement qu'avec des logiciels propriétaires.
C'est pour cette raison que ces codecs ne sont pas dispos dans les
distribs officielles, et qu'il faut aller les chercher sur un site
hongrois.
Et, finalement, ça fait l'affaire de Microsoft. Ainsi la SRC va prétendre
que je peux visionner le format WM avec Linux. J'attends qu'ils me disent ça...
D'autre part, les gens qui comprennent les enjeux sont capables de compiler
du source et sont portés à temporiser plus que s'il n'y avait aucune
alternative. Ils se prêtent au jeu du chat et de la souris en prétendant
s'en sortir ainsi. Les newbies, eux, restent avec Windows, parce que
«Windows, c'est plus facile.» Ensuite, on se demande pourquoi Linux figure
aussi bas au zeitgeist...
Pendant ce temps, l'Empire Microsoft s'étend. L'État tend sa laisse en
demandant qu'on en fasse un esclave.
En téléchargement et d'une le partage (multicast) du fichier est absolument impossible
J'aimerais donc pourquoi on ne poirrait envoyer un fichier ordinaire en milticast. Car, pour le moment, dans le cas du streaming comme d'un fichier standard, tout ce que je vois, ce sont des bits qui rentrent sur l'ordi.
Si un ordi éprouvait des problèmes de réseau, fin de la transmission. Meilleure chance la prochaine fois! Un fournisseur qui n'a pas la bande passamte pour du 44 kbps, il ferait mieux de fermer ses portes.
et de deux le téléchargement se fait à la vitesse qu'il peut (en général la bande passante disponible soit côté serveur, soit côté client).
C'est pourquoi, comme pour le streaming, la diffusion de fichiers en multicast devrait se faire à des vitesses suffisamment basses pour que le réseau ne cause pas de problèmes.
Qu'est-ce que tu dis? Comprends-tu pourquoi le site de la SRC est complètement bloqué 24 h heures par jour parce que les capsules audio de 5 minutes seraient reçues d'Athènes une fois l'heure?
Le script qui pourrait régler le problème pendant deux semaines, ça prend combien de temps pour l'écrire. Dix ans ou quoi?
5 minutes. Mais qui est responsable de l'écrire? Qui est responsable s'il est cause d'une panne? Dans une grosse entreprise, personne ne fait jamais de modification de ce genre sans qu'il ne faille 6 mois de réunions, notes de services, etc, pour que les responsabilités soient diluées comme il se doit.
Ça, c,est un problèmeé Un responsable de la SRC m'a appelé ce matin à ce sujet, mais j'ai manqué son appel. Il est «très occupé» aujourd'hui et n'a pas retourné mon appel, tel que promis, ce midi. Mais il se pourrait même qu'il me rappelle ce soir.
Funalement, ça prend peut-être plus que 5 min pour écrire ce script :)
Xvid c'est du mpeg 4. Légalement, ils n'ont pas le droit de diffuser de codec librement et gratuitement, ils devraient payer des royalties aux ayant-droits du format mpeg 4. C'est pourquoi il ne diffusent pas de "logiciel" mais uniquement du "source".
Puisque le source peut-être compilé, je ne vois pas trop ce que ça change d'un point de vue légal.
Oui, on dirait que les développeurs Linux ne pas rentrés dasn la nouvelle vague. Je me demande si, comme moi, ils ne se demandent pas à quoi ça sert. le streaming.
Pas exactement. Disons qu'ils n'en ont pas eu besoin. Le streaming est surtout utile aux grosses boîtes, par définition.
Moi, je pense toujours que ce n'est utile à personne.
Et le .NET ça sert vraiment à quelque chose? Que personne ne m'ensevelisse de termes techniques et qu'on me dise ce que .NET permettra que la technologie actuelle ne permet pas.
..NET sert à des tas de choses, mais ça n'a aucun rapport avec le streaming.
Non... vrai? :)
Je propose qu'on en parle éventuellement dans un autre fil.
Je te laisse le partir.
Là encore, ils utilisent des librairies "pirates", parce que les spécifications ne sont pas disponibles, légalement on n'a pas le droit de regarder un wmv ou un mov sous linux.
C'est tout ce qu'il y a à dire. La SRC offre ses fichiers dasn un format qu'il est illégal de visionner autrement qu'avec des logiciels propriétaires.
C'est pour cette raison que ces codecs ne sont pas dispos dans les distribs officielles, et qu'il faut aller les chercher sur un site hongrois.
Et, finalement, ça fait l'affaire de Microsoft. Ainsi la SRC va prétendre que je peux visionner le format WM avec Linux. J'attends qu'ils me disent ça...
D'autre part, les gens qui comprennent les enjeux sont capables de compiler du source et sont portés à temporiser plus que s'il n'y avait aucune alternative. Ils se prêtent au jeu du chat et de la souris en prétendant s'en sortir ainsi. Les newbies, eux, restent avec Windows, parce que «Windows, c'est plus facile.» Ensuite, on se demande pourquoi Linux figure aussi bas au zeitgeist...
Pendant ce temps, l'Empire Microsoft s'étend. L'État tend sa laisse en demandant qu'on en fasse un esclave.
GP
GP
Rakotomandimby Mihamina wrote:
GP wrote:
Oh, quel avantage!
C'est ironique ou plutot foutage de gueule comme remarque ?
Simplement ironique, car j'espère que tu comprends tout de même mon point de vue.
Je vais te dire. Des fichiers video streaming qui font plus que 50 megs, il ne doit pas y en avoir des tonnes. Qui n'a pas 50 megs sur son disque?
Ca ne veut pas dire qu'il n'y en aura pas .
Quand bien même il y en aurait, avec des disques de 200 G, je ne vois toujours pas le problème.
Longues séquences? On parle de quoi? 500 megs? Mais s'il n'y a pas suffisamment d'espace sur le disque, le logiciel pourrait demander si on veut arrêter la réception et conserver le début, ou effacer le début et poursuivre la réception.
Le logiciel donc. Pas le format. Ben si l'editeur de la sequence video le voulais il peut mettre a disposition le fichier ... si il le fait pas c'est qu'il veut pas. Il prefere que tu revienne visiter le site.
Oui, mais ça demande de la bande passante.
En tant que webmaster d'un site qui recherche a atteindre un certain nombre de visites, je peux comprendre cette volonté.
Ça me semble une façon peu efficace d'implémenter un audimètre. Il y a d'autres moyens de s'assurer de la popularité d'une émission amplement suffisants pour une télévision d'État. À moins qu'on ne croie vraiment plus qu'à la course à l'audimètre?
Et puis on va pas tout servir tout le monde sur un plateau d'argent non plus ;-)
«Tout le monde», ici, c'est le contribuable. Il a payé pour produire les émussions qu'il visionne. S'il ne peut les conserver sur son ordi, elles vont éventuellement disparaître du site, et il devra payer pour les visionner.
Or, face au déluge d'informations auquel nous sommes soumis, combien de fois Monsieur-Tout-le-Monde va-t-il être prêt à payer pour visionner un fichier?
On se retrouve donc avec une information à deux vitesses où la masse ne vit plus que dans l'éphémère du présent et où les privilégiés, principalement les entreprises, ont accès au passé.
Pour une société d'État, trouves-tu que c'est une option acceptable que de fonder ses revenus sur cette politique à deux vitesses, surtout quand les petits contribuables ont majoritairement contribué au projet?
Moi pas. Je ne pense pas qu'il y ait de FM (fuckin' manual) écrit à ce sujet, c'est juste le simple bon sens.
Sinon a ta question de savoir si on peut enregistrer un stream, oui c'est avec une option du genre --dumpstream (pour mplayer)
Et, avec xine, toi, ou quelqu'un d'autre, vous faites quoi pour récupérer un stream wmp?
Si ça continue, cette discussion va virer comme celle que j'ai eue avec Vincent Bernat au sujet de la possibilité de remonter au fichier original: tout le monde va dire que ça se fait, mais on ne saura jamais comment.
Je répète: Comment fait-on pour récupérer un stream wmp avec Linux?
et surement apprachante pour les auters lecteurs sous Linux qui possedent une CLI. Tiens, on parlait de VLC y a queleques jours (oui il parait que c'est un logiciel codé par des "brelles") il permet aussi -de memoire- d'enregistrer le stream que tu regarde.
Si un logiciel peut le faire, c'est que les fichiers sont sur l'ordi, dans la cache, le plus probablement. Y a-t-il un «scrambling» dans les fichiers qui interdit de les lire directement, sans l'aide d'un utilitaire?
C'est comme la Radio tu sais (NRJ, Fun, Europe2, RTL, FranceInfo ... ) ils peuvent pas mettre tous les CDs des artistes a dispo des auditeurs
Encore une fois, nous parlons ici de la Société Radio-Canada (SRC) et, en sous-entendu, de la Canadian /Broadcasting/ Corporation (CBC), la radiotélédiffusion d'État au Canada.
GP
Rakotomandimby Mihamina wrote:
GP wrote:
Oh, quel avantage!
C'est ironique ou plutot foutage de gueule comme remarque ?
Simplement ironique, car j'espère que tu comprends tout de même mon point de
vue.
Je vais te dire. Des fichiers video streaming qui font plus que 50
megs, il ne doit pas y en avoir des tonnes. Qui n'a pas 50 megs sur
son disque?
Ca ne veut pas dire qu'il n'y en aura pas .
Quand bien même il y en aurait, avec des disques de 200 G, je ne vois
toujours pas le problème.
Longues séquences? On parle de quoi? 500 megs? Mais s'il n'y a pas
suffisamment d'espace sur le disque, le logiciel pourrait demander si
on veut arrêter la réception et conserver le début, ou effacer le
début et poursuivre la réception.
Le logiciel donc. Pas le format. Ben si l'editeur de la sequence video
le voulais il peut mettre a disposition le fichier ... si il le fait pas
c'est qu'il veut pas. Il prefere que tu revienne visiter le site.
Oui, mais ça demande de la bande passante.
En
tant que webmaster d'un site qui recherche a atteindre un certain nombre
de visites, je peux comprendre cette volonté.
Ça me semble une façon peu efficace d'implémenter un audimètre. Il y a
d'autres moyens de s'assurer de la popularité d'une émission amplement
suffisants pour une télévision d'État. À moins qu'on ne croie vraiment plus
qu'à la course à l'audimètre?
Et puis on va pas tout
servir tout le monde sur un plateau d'argent non plus ;-)
«Tout le monde», ici, c'est le contribuable. Il a payé pour produire les
émussions qu'il visionne. S'il ne peut les conserver sur son ordi, elles
vont éventuellement disparaître du site, et il devra payer pour les visionner.
Or, face au déluge d'informations auquel nous sommes soumis, combien de fois
Monsieur-Tout-le-Monde va-t-il être prêt à payer pour visionner un fichier?
On se retrouve donc avec une information à deux vitesses où la masse ne vit
plus que dans l'éphémère du présent et où les privilégiés, principalement
les entreprises, ont accès au passé.
Pour une société d'État, trouves-tu que c'est une option acceptable que de
fonder ses revenus sur cette politique à deux vitesses, surtout quand les
petits contribuables ont majoritairement contribué au projet?
Moi pas. Je ne pense pas qu'il y ait de FM (fuckin' manual) écrit à ce
sujet, c'est juste le simple bon sens.
Sinon a ta question de savoir si on peut enregistrer un stream, oui
c'est avec une option du genre --dumpstream (pour mplayer)
Et, avec xine, toi, ou quelqu'un d'autre, vous faites quoi pour récupérer un
stream wmp?
Si ça continue, cette discussion va virer comme celle que j'ai eue avec
Vincent Bernat au sujet de la possibilité de remonter au fichier original:
tout le monde va dire que ça se fait, mais on ne saura jamais comment.
Je répète: Comment fait-on pour récupérer un stream wmp avec Linux?
et surement
apprachante pour les auters lecteurs sous Linux qui possedent une CLI.
Tiens, on parlait de VLC y a queleques jours (oui il parait que c'est un
logiciel codé par des "brelles") il permet aussi -de memoire-
d'enregistrer le stream que tu regarde.
Si un logiciel peut le faire, c'est que les fichiers sont sur l'ordi, dans
la cache, le plus probablement. Y a-t-il un «scrambling» dans les fichiers
qui interdit de les lire directement, sans l'aide d'un utilitaire?
C'est comme la Radio tu sais (NRJ, Fun, Europe2, RTL, FranceInfo ... )
ils peuvent pas mettre tous les CDs des artistes a dispo des auditeurs
Encore une fois, nous parlons ici de la Société Radio-Canada (SRC) et, en
sous-entendu, de la Canadian /Broadcasting/ Corporation (CBC), la
radiotélédiffusion d'État au Canada.
C'est ironique ou plutot foutage de gueule comme remarque ?
Simplement ironique, car j'espère que tu comprends tout de même mon point de vue.
Je vais te dire. Des fichiers video streaming qui font plus que 50 megs, il ne doit pas y en avoir des tonnes. Qui n'a pas 50 megs sur son disque?
Ca ne veut pas dire qu'il n'y en aura pas .
Quand bien même il y en aurait, avec des disques de 200 G, je ne vois toujours pas le problème.
Longues séquences? On parle de quoi? 500 megs? Mais s'il n'y a pas suffisamment d'espace sur le disque, le logiciel pourrait demander si on veut arrêter la réception et conserver le début, ou effacer le début et poursuivre la réception.
Le logiciel donc. Pas le format. Ben si l'editeur de la sequence video le voulais il peut mettre a disposition le fichier ... si il le fait pas c'est qu'il veut pas. Il prefere que tu revienne visiter le site.
Oui, mais ça demande de la bande passante.
En tant que webmaster d'un site qui recherche a atteindre un certain nombre de visites, je peux comprendre cette volonté.
Ça me semble une façon peu efficace d'implémenter un audimètre. Il y a d'autres moyens de s'assurer de la popularité d'une émission amplement suffisants pour une télévision d'État. À moins qu'on ne croie vraiment plus qu'à la course à l'audimètre?
Et puis on va pas tout servir tout le monde sur un plateau d'argent non plus ;-)
«Tout le monde», ici, c'est le contribuable. Il a payé pour produire les émussions qu'il visionne. S'il ne peut les conserver sur son ordi, elles vont éventuellement disparaître du site, et il devra payer pour les visionner.
Or, face au déluge d'informations auquel nous sommes soumis, combien de fois Monsieur-Tout-le-Monde va-t-il être prêt à payer pour visionner un fichier?
On se retrouve donc avec une information à deux vitesses où la masse ne vit plus que dans l'éphémère du présent et où les privilégiés, principalement les entreprises, ont accès au passé.
Pour une société d'État, trouves-tu que c'est une option acceptable que de fonder ses revenus sur cette politique à deux vitesses, surtout quand les petits contribuables ont majoritairement contribué au projet?
Moi pas. Je ne pense pas qu'il y ait de FM (fuckin' manual) écrit à ce sujet, c'est juste le simple bon sens.
Sinon a ta question de savoir si on peut enregistrer un stream, oui c'est avec une option du genre --dumpstream (pour mplayer)
Et, avec xine, toi, ou quelqu'un d'autre, vous faites quoi pour récupérer un stream wmp?
Si ça continue, cette discussion va virer comme celle que j'ai eue avec Vincent Bernat au sujet de la possibilité de remonter au fichier original: tout le monde va dire que ça se fait, mais on ne saura jamais comment.
Je répète: Comment fait-on pour récupérer un stream wmp avec Linux?
et surement apprachante pour les auters lecteurs sous Linux qui possedent une CLI. Tiens, on parlait de VLC y a queleques jours (oui il parait que c'est un logiciel codé par des "brelles") il permet aussi -de memoire- d'enregistrer le stream que tu regarde.
Si un logiciel peut le faire, c'est que les fichiers sont sur l'ordi, dans la cache, le plus probablement. Y a-t-il un «scrambling» dans les fichiers qui interdit de les lire directement, sans l'aide d'un utilitaire?
C'est comme la Radio tu sais (NRJ, Fun, Europe2, RTL, FranceInfo ... ) ils peuvent pas mettre tous les CDs des artistes a dispo des auditeurs
Encore une fois, nous parlons ici de la Société Radio-Canada (SRC) et, en sous-entendu, de la Canadian /Broadcasting/ Corporation (CBC), la radiotélédiffusion d'État au Canada.
GP
GP
oxidor trucidel wrote:
Et s'il est offert par la télévision d'État, quel est l'avantage que le fichier s'efface(1). J'ai eu une discussion là-dessus avec Denis Beauregard
sur soc.culture.quebec. Si tu veux repiquer la discussion ici, libre à toi.
Je crois que ce serait HS ;-)
Sur soc.culture.quebec, nous discutons de notre droit à recevoir la culture, dont l'information, le plus librement possible. Je crains que nous ne discutions de cela ici aussi :)
Ici, sur fcold, je discute d'une tentative d'amener le gouvernement du Canada à définir sa position face au libre. Je crains de parler aussi de cela sur soc.culture.quebec...
Je ne pense pas être HS ici non plus.
Pour te faire gagner du temps, je vais la rechercher sur google.
Ce faisant, tu liras peut-être d'autres de mes messages sur le même sujet. Tu te rendras compte que je pourrais tous les repiquer ici, et vice-versa.
La culture et la technique, tu sais, ç'a peut-être quelque chose à voir.
GP
oxidor trucidel wrote:
Et s'il est offert par la télévision d'État, quel est l'avantage que le
fichier s'efface(1). J'ai eu une discussion là-dessus avec Denis
Beauregard
sur soc.culture.quebec. Si tu veux repiquer la discussion ici, libre à
toi.
Je crois que ce serait HS ;-)
Sur soc.culture.quebec, nous discutons de notre droit à recevoir la culture,
dont l'information, le plus librement possible. Je crains que nous ne
discutions de cela ici aussi :)
Ici, sur fcold, je discute d'une tentative d'amener le gouvernement du
Canada à définir sa position face au libre. Je crains de parler aussi de
cela sur soc.culture.quebec...
Je ne pense pas être HS ici non plus.
Pour te faire gagner du temps, je vais la rechercher sur google.
Ce faisant, tu liras peut-être d'autres de mes messages sur le même sujet.
Tu te rendras compte que je pourrais tous les repiquer ici, et vice-versa.
La culture et la technique, tu sais, ç'a peut-être quelque chose à voir.
Et s'il est offert par la télévision d'État, quel est l'avantage que le fichier s'efface(1). J'ai eu une discussion là-dessus avec Denis Beauregard
sur soc.culture.quebec. Si tu veux repiquer la discussion ici, libre à toi.
Je crois que ce serait HS ;-)
Sur soc.culture.quebec, nous discutons de notre droit à recevoir la culture, dont l'information, le plus librement possible. Je crains que nous ne discutions de cela ici aussi :)
Ici, sur fcold, je discute d'une tentative d'amener le gouvernement du Canada à définir sa position face au libre. Je crains de parler aussi de cela sur soc.culture.quebec...
Je ne pense pas être HS ici non plus.
Pour te faire gagner du temps, je vais la rechercher sur google.
Ce faisant, tu liras peut-être d'autres de mes messages sur le même sujet. Tu te rendras compte que je pourrais tous les repiquer ici, et vice-versa.
La culture et la technique, tu sais, ç'a peut-être quelque chose à voir.
GP
Emmanuel Florac
Le Mon, 23 Aug 2004 12:06:28 -0400, GP a écrit :
Misère! Va-t-on finir par sortir de cette galère? Comme je l'ai expliqué dans le cas de la grosse page web, est-ce qu'elle n'est pas diffusée en direct? En admettant qu'on puisse lire la page à la vitesse à laquelle elle s'affiche, est-ce que le début ne pourrait pas disparaître quand on lit la fin?
Ah non, la page web est un document structuré, la fin est en partie déterminée par le début.
Oui, ça prend un peu de ram. Seulement, les set-top box modernes, ils ont non seulement du ram à revendre, ils ont même des disques durs de plusieurs G.
Ouuui. Je ne dis pas le contraire. Je te parle des conditions qui ont présidé à la conception du streaming.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Le Mon, 23 Aug 2004 12:06:28 -0400, GP a écrit :
Misère! Va-t-on finir par sortir de cette galère? Comme je l'ai expliqué
dans le cas de la grosse page web, est-ce qu'elle n'est pas diffusée en
direct? En admettant qu'on puisse lire la page à la vitesse à laquelle elle
s'affiche, est-ce que le début ne pourrait pas disparaître quand on lit la fin?
Ah non, la page web est un document structuré, la fin est en partie
déterminée par le début.
Oui, ça prend un peu de ram. Seulement, les set-top box modernes, ils ont
non seulement du ram à revendre, ils ont même des disques durs de plusieurs G.
Ouuui. Je ne dis pas le contraire. Je te parle des conditions qui ont
présidé à la conception du streaming.
--
A thing of beauty is a joy forever.
J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.
Misère! Va-t-on finir par sortir de cette galère? Comme je l'ai expliqué dans le cas de la grosse page web, est-ce qu'elle n'est pas diffusée en direct? En admettant qu'on puisse lire la page à la vitesse à laquelle elle s'affiche, est-ce que le début ne pourrait pas disparaître quand on lit la fin?
Ah non, la page web est un document structuré, la fin est en partie déterminée par le début.
Oui, ça prend un peu de ram. Seulement, les set-top box modernes, ils ont non seulement du ram à revendre, ils ont même des disques durs de plusieurs G.
Ouuui. Je ne dis pas le contraire. Je te parle des conditions qui ont présidé à la conception du streaming.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Emmanuel Florac
Le Mon, 23 Aug 2004 12:58:24 -0400, GP a écrit :
J'aimerais donc pourquoi on ne poirrait envoyer un fichier ordinaire en milticast.
Le multicast ne permet aucune garantie de service. Ce n'est pas très grave pour de la vidéo ou du son (on peut avoir une saute de temps en temps, si ce n'est pas trop fréquent ça ne perturbe pas trop le message), par contre pour des documents ou des applications c'est impensable.
Car, pour le moment, dans le cas du streaming comme d'un fichier standard, tout ce que je vois, ce sont des bits qui rentrent sur l'ordi.
Il faut que tu te renseignes sur les différences entre UDP et TCP :) Dans la vie de tous les jours, il n'y a que microsoft qui s'appuie sur du broadcast ou du multicast pour faire tourner son protocole réseau.
Si un ordi éprouvait des problèmes de réseau, fin de la transmission. Meilleure chance la prochaine fois! Un fournisseur qui n'a pas la bande passamte pour du 44 kbps, il ferait mieux de fermer ses portes.
Ça n'est pas si simple. La bande passante en hébergement est considérablement plus coûteuse qu'à la maison. 100 mbit/s disponibles et garantis ça peut coûter plusieurs dizaines de milliers d'euros par mois. Pas question de gaspiller.
Ça, c,est un problèmeé Un responsable de la SRC m'a appelé ce matin à ce sujet, mais j'ai manqué son appel. Il est «très occupé» aujourd'hui et n'a pas retourné mon appel, tel que promis, ce midi. Mais il se pourrait même qu'il me rappelle ce soir.
Funalement, ça prend peut-être plus que 5 min pour écrire ce script :)
5 minutes pour faire le script, mais 6 mois de réunions, emails, notes de services, coups bas et messes basses pour savoir qui s'y colle...
Xvid c'est du mpeg 4. Légalement, ils n'ont pas le droit de diffuser de codec librement et gratuitement, ils devraient payer des royalties aux ayant-droits du format mpeg 4. C'est pourquoi il ne diffusent pas de "logiciel" mais uniquement du "source".
Puisque le source peut-être compilé, je ne vois pas trop ce que ça change d'un point de vue légal.
Il faut lire la licence pour ça. Je pense que c'est expliqué sur les sites des uns et des autres. Au départ, DiVX:) devait être libre, puis ensuite apparemment ils ont choisi de payer les royalties légales et de ne distribuer que des binaires (tel que prévui par la licence). Xvid est dérivé de là, avec le choix de ne PAS payer les licences et donc de jouer au chat et à la souris...
Pas exactement. Disons qu'ils n'en ont pas eu besoin. Le streaming est surtout utile aux grosses boîtes, par définition.
Moi, je pense toujours que ce n'est utile à personne.
À l'heure actuelle c'est quand même très utile aux chaînes de télé...
..NET sert à des tas de choses, mais ça n'a aucun rapport avec le streaming.
Non... vrai? :)
Tout à fait. On peut le comparer à Java, à HTTP, à XUL, à des tas de trucs mais vraiment le streaming, je ne vois pas le lien :)
Je propose qu'on en parle éventuellement dans un autre fil.
Je te laisse le partir.
Ah?
Là encore, ils utilisent des librairies "pirates", parce que les spécifications ne sont pas disponibles, légalement on n'a pas le droit de regarder un wmv ou un mov sous linux.
C'est tout ce qu'il y a à dire. La SRC offre ses fichiers dasn un format qu'il est illégal de visionner autrement qu'avec des logiciels propriétaires.
Absolument.
Et, finalement, ça fait l'affaire de Microsoft. Ainsi la SRC va prétendre que je peux visionner le format WM avec Linux. J'attends qu'ils me disent ça...
C'est "possible". Comme de regarder un DVD sous Linux, c'est possible mais illégal (ou à tout le moins "en zone grise").
Pendant ce temps, l'Empire Microsoft s'étend. L'État tend sa laisse en demandant qu'on en fasse un esclave.
Note bien que toutes les politiques gouvernementales du monde occidental jouent exclusivement et uniquement pour les grosses entreprises. Malheureusement, il faut bien se dire quà l'heure actuelle c'est tout bonnement jouer les entreprises contre le peuple, pour faire court (les grandes multinationales sont les ennemies des gens).
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Mon, 23 Aug 2004 12:58:24 -0400, GP a écrit :
J'aimerais donc pourquoi on ne poirrait envoyer un fichier ordinaire en
milticast.
Le multicast ne permet aucune garantie de service. Ce n'est pas très
grave pour de la vidéo ou du son (on peut avoir une saute de temps en
temps, si ce n'est pas trop fréquent ça ne perturbe pas trop le
message), par contre pour des documents ou des applications c'est
impensable.
Car, pour le moment, dans le cas du streaming comme d'un fichier
standard, tout ce que je vois, ce sont des bits qui rentrent sur l'ordi.
Il faut que tu te renseignes sur les différences entre UDP et TCP :) Dans
la vie de tous les jours, il n'y a que microsoft qui s'appuie sur du
broadcast ou du multicast pour faire tourner son protocole réseau.
Si un ordi éprouvait des problèmes de réseau, fin de la transmission.
Meilleure chance la prochaine fois! Un fournisseur qui n'a pas la bande
passamte pour du 44 kbps, il ferait mieux de fermer ses portes.
Ça n'est pas si simple. La bande passante en hébergement est
considérablement plus coûteuse qu'à la maison. 100 mbit/s disponibles
et garantis ça peut coûter plusieurs dizaines de milliers d'euros par
mois. Pas question de gaspiller.
Ça, c,est un problèmeé Un responsable de la SRC m'a appelé ce matin à ce
sujet, mais j'ai manqué son appel. Il est «très occupé» aujourd'hui et n'a
pas retourné mon appel, tel que promis, ce midi. Mais il se pourrait même
qu'il me rappelle ce soir.
Funalement, ça prend peut-être plus que 5 min pour écrire ce script :)
5 minutes pour faire le script, mais 6 mois de réunions, emails, notes de
services, coups bas et messes basses pour savoir qui s'y colle...
Xvid c'est du mpeg 4. Légalement, ils n'ont pas le droit de diffuser
de codec librement et gratuitement, ils devraient payer des royalties
aux ayant-droits du format mpeg 4. C'est pourquoi il ne diffusent pas
de "logiciel" mais uniquement du "source".
Puisque le source peut-être compilé, je ne vois pas trop ce que ça
change d'un point de vue légal.
Il faut lire la licence pour ça. Je pense que c'est expliqué sur les
sites des uns et des autres. Au départ, DiVX:) devait être libre, puis
ensuite apparemment ils ont choisi de payer les royalties légales et de
ne distribuer que des binaires (tel que prévui par la licence). Xvid est
dérivé de là, avec le choix de ne PAS payer les licences et donc de
jouer au chat et à la souris...
Pas exactement. Disons qu'ils n'en ont pas eu besoin. Le streaming est
surtout utile aux grosses boîtes, par définition.
Moi, je pense toujours que ce n'est utile à personne.
À l'heure actuelle c'est quand même très utile aux chaînes de télé...
..NET sert à des tas de choses, mais ça n'a aucun rapport avec le
streaming.
Non... vrai? :)
Tout à fait. On peut le comparer à Java, à HTTP, à XUL, à des tas de
trucs mais vraiment le streaming, je ne vois pas le lien :)
Je propose qu'on en parle éventuellement dans un autre fil.
Je te laisse le partir.
Ah?
Là encore, ils utilisent des librairies "pirates", parce que les
spécifications ne sont pas disponibles, légalement on n'a pas le
droit de regarder un wmv ou un mov sous linux.
C'est tout ce qu'il y a à dire. La SRC offre ses fichiers dasn un
format qu'il est illégal de visionner autrement qu'avec des logiciels
propriétaires.
Absolument.
Et, finalement, ça fait l'affaire de Microsoft. Ainsi la SRC va
prétendre que je peux visionner le format WM avec Linux. J'attends
qu'ils me disent ça...
C'est "possible". Comme de regarder un DVD sous Linux, c'est possible mais
illégal (ou à tout le moins "en zone grise").
Pendant ce temps, l'Empire Microsoft s'étend. L'État tend sa laisse en
demandant qu'on en fasse un esclave.
Note bien que toutes les politiques gouvernementales du monde occidental
jouent exclusivement et uniquement pour les grosses entreprises.
Malheureusement, il faut bien se dire quà l'heure actuelle c'est tout
bonnement jouer les entreprises contre le peuple, pour faire court (les
grandes multinationales sont les ennemies des gens).
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray
J'aimerais donc pourquoi on ne poirrait envoyer un fichier ordinaire en milticast.
Le multicast ne permet aucune garantie de service. Ce n'est pas très grave pour de la vidéo ou du son (on peut avoir une saute de temps en temps, si ce n'est pas trop fréquent ça ne perturbe pas trop le message), par contre pour des documents ou des applications c'est impensable.
Car, pour le moment, dans le cas du streaming comme d'un fichier standard, tout ce que je vois, ce sont des bits qui rentrent sur l'ordi.
Il faut que tu te renseignes sur les différences entre UDP et TCP :) Dans la vie de tous les jours, il n'y a que microsoft qui s'appuie sur du broadcast ou du multicast pour faire tourner son protocole réseau.
Si un ordi éprouvait des problèmes de réseau, fin de la transmission. Meilleure chance la prochaine fois! Un fournisseur qui n'a pas la bande passamte pour du 44 kbps, il ferait mieux de fermer ses portes.
Ça n'est pas si simple. La bande passante en hébergement est considérablement plus coûteuse qu'à la maison. 100 mbit/s disponibles et garantis ça peut coûter plusieurs dizaines de milliers d'euros par mois. Pas question de gaspiller.
Ça, c,est un problèmeé Un responsable de la SRC m'a appelé ce matin à ce sujet, mais j'ai manqué son appel. Il est «très occupé» aujourd'hui et n'a pas retourné mon appel, tel que promis, ce midi. Mais il se pourrait même qu'il me rappelle ce soir.
Funalement, ça prend peut-être plus que 5 min pour écrire ce script :)
5 minutes pour faire le script, mais 6 mois de réunions, emails, notes de services, coups bas et messes basses pour savoir qui s'y colle...
Xvid c'est du mpeg 4. Légalement, ils n'ont pas le droit de diffuser de codec librement et gratuitement, ils devraient payer des royalties aux ayant-droits du format mpeg 4. C'est pourquoi il ne diffusent pas de "logiciel" mais uniquement du "source".
Puisque le source peut-être compilé, je ne vois pas trop ce que ça change d'un point de vue légal.
Il faut lire la licence pour ça. Je pense que c'est expliqué sur les sites des uns et des autres. Au départ, DiVX:) devait être libre, puis ensuite apparemment ils ont choisi de payer les royalties légales et de ne distribuer que des binaires (tel que prévui par la licence). Xvid est dérivé de là, avec le choix de ne PAS payer les licences et donc de jouer au chat et à la souris...
Pas exactement. Disons qu'ils n'en ont pas eu besoin. Le streaming est surtout utile aux grosses boîtes, par définition.
Moi, je pense toujours que ce n'est utile à personne.
À l'heure actuelle c'est quand même très utile aux chaînes de télé...
..NET sert à des tas de choses, mais ça n'a aucun rapport avec le streaming.
Non... vrai? :)
Tout à fait. On peut le comparer à Java, à HTTP, à XUL, à des tas de trucs mais vraiment le streaming, je ne vois pas le lien :)
Je propose qu'on en parle éventuellement dans un autre fil.
Je te laisse le partir.
Ah?
Là encore, ils utilisent des librairies "pirates", parce que les spécifications ne sont pas disponibles, légalement on n'a pas le droit de regarder un wmv ou un mov sous linux.
C'est tout ce qu'il y a à dire. La SRC offre ses fichiers dasn un format qu'il est illégal de visionner autrement qu'avec des logiciels propriétaires.
Absolument.
Et, finalement, ça fait l'affaire de Microsoft. Ainsi la SRC va prétendre que je peux visionner le format WM avec Linux. J'attends qu'ils me disent ça...
C'est "possible". Comme de regarder un DVD sous Linux, c'est possible mais illégal (ou à tout le moins "en zone grise").
Pendant ce temps, l'Empire Microsoft s'étend. L'État tend sa laisse en demandant qu'on en fasse un esclave.
Note bien que toutes les politiques gouvernementales du monde occidental jouent exclusivement et uniquement pour les grosses entreprises. Malheureusement, il faut bien se dire quà l'heure actuelle c'est tout bonnement jouer les entreprises contre le peuple, pour faire court (les grandes multinationales sont les ennemies des gens).
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
GP
Emmanuel Florac wrote:
J'aimerais donc pourquoi on ne poirrait envoyer un fichier ordinaire en milticast.
Le multicast ne permet aucune garantie de service. Ce n'est pas très grave pour de la vidéo ou du son (on peut avoir une saute de temps en temps, si ce n'est pas trop fréquent ça ne perturbe pas trop le message), par contre pour des documents ou des applications c'est impensable.
Justement. Ici on parle de fichiers audio et vidéo. S'il y a un blanc dans le fichier, ce n'est pas pire que lorsque ça se produit en streaming.
D'autre part, j'ai l'impression que lorsqu'il y a des blancs dans le streaming que je reçois, c'est plus dû serveur et à sa bande passante qu'à la mienne.
Car, en général, quand je télécharge d'un bon serveur en Europe ou même en Australie, je télécharge à 300 - 305 kpbs à toute heure du jour avec la stabilité du rock. Évidemment, pour passer de 300 à 305, il faut quelques minutes. Mais on en joue pas dans cette fourchette-là avec le streaming et on n'y jouerait pas plus avec le multicast fichiers.
Et, comme je le disais, le multicast fichiers, contrairement au streaming permettrait de garder les fichiers, de les partager, et ainsi, de moins solliciter le serveur.
Car, pour le moment, dans le cas du streaming comme d'un fichier standard, tout ce que je vois, ce sont des bits qui rentrent sur l'ordi.
Il faut que tu te renseignes sur les différences entre UDP et TCP :)
Justement, je m'attendais à ce que tu m'informes de ce que cela vient faire dans le contexte.
Dans la vie de tous les jours, il n'y a que microsoft qui s'appuie sur du broadcast ou du multicast pour faire tourner son protocole réseau.
Le «protocole réseau de Linux ne peut tourner en broadcast ou en multicast»? Je ne comprends pas trop la signification de cela.
En général, quand les experts disent que le principe ne peut être discuté qu'entre eux, c'est mauvais signe. Je deviens méfiant. Il y a souvent, comme qui dirait, des coins d'ombre. Il me semble avoir compris le principe de choses plus complexes que des «protocoles réseau»
Il faudrait décidément que tu expliques.
Mais, en admettant que tu aies raison, est-ce que ça ne voudrait pas simplement dire que ce serait LE projet qui devrait réunir les télévisions publiques à travers le monde?
À première vue, ça me semble un meilleur projet que de faire du streaming avec Dirac.
Si un ordi éprouvait des problèmes de réseau, fin de la transmission. Meilleure chance la prochaine fois! Un fournisseur qui n'a pas la bande passamte pour du 44 kbps, il ferait mieux de fermer ses portes.
Ça n'est pas si simple. La bande passante en hébergement est considérablement plus coûteuse qu'à la maison. 100 mbit/s disponibles et garantis ça peut coûter plusieurs dizaines de milliers d'euros par mois. Pas question de gaspiller.
Quand je parlais de fournisseurs, je voulais dire d'accès internet. Quant à la bande passante de la SRC, nous le disions, c'est le streaming qui en demande le plus.
(...)
..NET sert à des tas de choses, mais ça n'a aucun rapport avec le streaming.
Non... vrai? :)
Tout à fait. On peut le comparer à Java, à HTTP, à XUL, à des tas de trucs mais vraiment le streaming, je ne vois pas le lien :)
Mon «Non... vrai?» était ironique.
Pendant ce temps, l'Empire Microsoft s'étend. L'État tend sa laisse en demandant qu'on en fasse un esclave.
Note bien que toutes les politiques gouvernementales du monde occidental jouent exclusivement et uniquement pour les grosses entreprises. Malheureusement, il faut bien se dire quà l'heure actuelle c'est tout bonnement jouer les entreprises contre le peuple, pour faire court (les grandes multinationales sont les ennemies des gens).
C'est peut-être un peu manichéen comme conception, mais il est clair qu'il faudrait créer un «level playing field» pour tout le monde.
J'ai exprimé ce point de vie dans mon dernier message à Denis Beauregard sur soc.culture.quebec.
J'ai reçu les appels des représentants de la SRC et du Conseil du Trésor. Je reviendrai là-dessus. Ici ou sur soc.culture.quebec. Je ne sais pas.
GP
Emmanuel Florac wrote:
J'aimerais donc pourquoi on ne poirrait envoyer un fichier ordinaire en
milticast.
Le multicast ne permet aucune garantie de service. Ce n'est pas très
grave pour de la vidéo ou du son (on peut avoir une saute de temps en
temps, si ce n'est pas trop fréquent ça ne perturbe pas trop le
message), par contre pour des documents ou des applications c'est
impensable.
Justement. Ici on parle de fichiers audio et vidéo. S'il y a un blanc dans
le fichier, ce n'est pas pire que lorsque ça se produit en streaming.
D'autre part, j'ai l'impression que lorsqu'il y a des blancs dans le
streaming que je reçois, c'est plus dû serveur et à sa bande passante qu'à
la mienne.
Car, en général, quand je télécharge d'un bon serveur en Europe ou même en
Australie, je télécharge à 300 - 305 kpbs à toute heure du jour avec la
stabilité du rock. Évidemment, pour passer de 300 à 305, il faut quelques
minutes. Mais on en joue pas dans cette fourchette-là avec le streaming et
on n'y jouerait pas plus avec le multicast fichiers.
Et, comme je le disais, le multicast fichiers, contrairement au streaming
permettrait de garder les fichiers, de les partager, et ainsi, de moins
solliciter le serveur.
Car, pour le moment, dans le cas du streaming comme d'un fichier
standard, tout ce que je vois, ce sont des bits qui rentrent sur l'ordi.
Il faut que tu te renseignes sur les différences entre UDP et TCP :)
Justement, je m'attendais à ce que tu m'informes de ce que cela vient faire
dans le contexte.
Dans
la vie de tous les jours, il n'y a que microsoft qui s'appuie sur du
broadcast ou du multicast pour faire tourner son protocole réseau.
Le «protocole réseau de Linux ne peut tourner en broadcast ou en multicast»?
Je ne comprends pas trop la signification de cela.
En général, quand les experts disent que le principe ne peut être discuté
qu'entre eux, c'est mauvais signe. Je deviens méfiant. Il y a souvent, comme
qui dirait, des coins d'ombre. Il me semble avoir compris le principe de
choses plus complexes que des «protocoles réseau»
Il faudrait décidément que tu expliques.
Mais, en admettant que tu aies raison, est-ce que ça ne voudrait pas
simplement dire que ce serait LE projet qui devrait réunir les télévisions
publiques à travers le monde?
À première vue, ça me semble un meilleur projet que de faire du streaming
avec Dirac.
Si un ordi éprouvait des problèmes de réseau, fin de la transmission.
Meilleure chance la prochaine fois! Un fournisseur qui n'a pas la bande
passamte pour du 44 kbps, il ferait mieux de fermer ses portes.
Ça n'est pas si simple. La bande passante en hébergement est
considérablement plus coûteuse qu'à la maison. 100 mbit/s disponibles
et garantis ça peut coûter plusieurs dizaines de milliers d'euros par
mois. Pas question de gaspiller.
Quand je parlais de fournisseurs, je voulais dire d'accès internet. Quant à
la bande passante de la SRC, nous le disions, c'est le streaming qui en
demande le plus.
(...)
..NET sert à des tas de choses, mais ça n'a aucun rapport avec le
streaming.
Non... vrai? :)
Tout à fait. On peut le comparer à Java, à HTTP, à XUL, à des tas de
trucs mais vraiment le streaming, je ne vois pas le lien :)
Mon «Non... vrai?» était ironique.
Pendant ce temps, l'Empire Microsoft s'étend. L'État tend sa laisse en
demandant qu'on en fasse un esclave.
Note bien que toutes les politiques gouvernementales du monde occidental
jouent exclusivement et uniquement pour les grosses entreprises.
Malheureusement, il faut bien se dire quà l'heure actuelle c'est tout
bonnement jouer les entreprises contre le peuple, pour faire court (les
grandes multinationales sont les ennemies des gens).
C'est peut-être un peu manichéen comme conception, mais il est clair qu'il
faudrait créer un «level playing field» pour tout le monde.
J'ai exprimé ce point de vie dans mon dernier message à Denis Beauregard sur
soc.culture.quebec.
J'ai reçu les appels des représentants de la SRC et du Conseil du Trésor. Je
reviendrai là-dessus. Ici ou sur soc.culture.quebec. Je ne sais pas.
J'aimerais donc pourquoi on ne poirrait envoyer un fichier ordinaire en milticast.
Le multicast ne permet aucune garantie de service. Ce n'est pas très grave pour de la vidéo ou du son (on peut avoir une saute de temps en temps, si ce n'est pas trop fréquent ça ne perturbe pas trop le message), par contre pour des documents ou des applications c'est impensable.
Justement. Ici on parle de fichiers audio et vidéo. S'il y a un blanc dans le fichier, ce n'est pas pire que lorsque ça se produit en streaming.
D'autre part, j'ai l'impression que lorsqu'il y a des blancs dans le streaming que je reçois, c'est plus dû serveur et à sa bande passante qu'à la mienne.
Car, en général, quand je télécharge d'un bon serveur en Europe ou même en Australie, je télécharge à 300 - 305 kpbs à toute heure du jour avec la stabilité du rock. Évidemment, pour passer de 300 à 305, il faut quelques minutes. Mais on en joue pas dans cette fourchette-là avec le streaming et on n'y jouerait pas plus avec le multicast fichiers.
Et, comme je le disais, le multicast fichiers, contrairement au streaming permettrait de garder les fichiers, de les partager, et ainsi, de moins solliciter le serveur.
Car, pour le moment, dans le cas du streaming comme d'un fichier standard, tout ce que je vois, ce sont des bits qui rentrent sur l'ordi.
Il faut que tu te renseignes sur les différences entre UDP et TCP :)
Justement, je m'attendais à ce que tu m'informes de ce que cela vient faire dans le contexte.
Dans la vie de tous les jours, il n'y a que microsoft qui s'appuie sur du broadcast ou du multicast pour faire tourner son protocole réseau.
Le «protocole réseau de Linux ne peut tourner en broadcast ou en multicast»? Je ne comprends pas trop la signification de cela.
En général, quand les experts disent que le principe ne peut être discuté qu'entre eux, c'est mauvais signe. Je deviens méfiant. Il y a souvent, comme qui dirait, des coins d'ombre. Il me semble avoir compris le principe de choses plus complexes que des «protocoles réseau»
Il faudrait décidément que tu expliques.
Mais, en admettant que tu aies raison, est-ce que ça ne voudrait pas simplement dire que ce serait LE projet qui devrait réunir les télévisions publiques à travers le monde?
À première vue, ça me semble un meilleur projet que de faire du streaming avec Dirac.
Si un ordi éprouvait des problèmes de réseau, fin de la transmission. Meilleure chance la prochaine fois! Un fournisseur qui n'a pas la bande passamte pour du 44 kbps, il ferait mieux de fermer ses portes.
Ça n'est pas si simple. La bande passante en hébergement est considérablement plus coûteuse qu'à la maison. 100 mbit/s disponibles et garantis ça peut coûter plusieurs dizaines de milliers d'euros par mois. Pas question de gaspiller.
Quand je parlais de fournisseurs, je voulais dire d'accès internet. Quant à la bande passante de la SRC, nous le disions, c'est le streaming qui en demande le plus.
(...)
..NET sert à des tas de choses, mais ça n'a aucun rapport avec le streaming.
Non... vrai? :)
Tout à fait. On peut le comparer à Java, à HTTP, à XUL, à des tas de trucs mais vraiment le streaming, je ne vois pas le lien :)
Mon «Non... vrai?» était ironique.
Pendant ce temps, l'Empire Microsoft s'étend. L'État tend sa laisse en demandant qu'on en fasse un esclave.
Note bien que toutes les politiques gouvernementales du monde occidental jouent exclusivement et uniquement pour les grosses entreprises. Malheureusement, il faut bien se dire quà l'heure actuelle c'est tout bonnement jouer les entreprises contre le peuple, pour faire court (les grandes multinationales sont les ennemies des gens).
C'est peut-être un peu manichéen comme conception, mais il est clair qu'il faudrait créer un «level playing field» pour tout le monde.
J'ai exprimé ce point de vie dans mon dernier message à Denis Beauregard sur soc.culture.quebec.
J'ai reçu les appels des représentants de la SRC et du Conseil du Trésor. Je reviendrai là-dessus. Ici ou sur soc.culture.quebec. Je ne sais pas.
GP
Sam Hocevar
On Mon, 23 Aug 2004 23:19:09 -0400, GP wrote:
Et, comme je le disais, le multicast fichiers, contrairement au streaming permettrait de garder les fichiers, de les partager, et ainsi, de moins solliciter le serveur.
Ça ne marcherait que si tout le monde demande le même morceau du même fichier en même temps. En gros, quasiment jamais. Le multicast, ça ne marche guère que pour les flux ou pour des annonces ponctuelles.
-- Sam.
On Mon, 23 Aug 2004 23:19:09 -0400, GP wrote:
Et, comme je le disais, le multicast fichiers, contrairement au streaming
permettrait de garder les fichiers, de les partager, et ainsi, de moins
solliciter le serveur.
Ça ne marcherait que si tout le monde demande le même morceau du même
fichier en même temps. En gros, quasiment jamais. Le multicast, ça ne
marche guère que pour les flux ou pour des annonces ponctuelles.
Et, comme je le disais, le multicast fichiers, contrairement au streaming permettrait de garder les fichiers, de les partager, et ainsi, de moins solliciter le serveur.
Ça ne marcherait que si tout le monde demande le même morceau du même fichier en même temps. En gros, quasiment jamais. Le multicast, ça ne marche guère que pour les flux ou pour des annonces ponctuelles.
-- Sam.
Thierry
GP wrote:
Emmanuel Florac wrote:
Dans la vie de tous les jours, il n'y a que microsoft qui s'appuie sur du broadcast ou du multicast pour faire tourner son protocole réseau.
Le «protocole réseau de Linux ne peut tourner en broadcast ou en multicast»? Je ne comprends pas trop la signification de cela.
Les ordinateurs Windows sont REPUTES (cf. autre fil) utiliser massivement le broadcast (et consommer ainsi plus de bande passante qu'il ne serait nécessaire sur le LAN).
-- Thierry
GP wrote:
Emmanuel Florac wrote:
Dans
la vie de tous les jours, il n'y a que microsoft qui s'appuie sur du
broadcast ou du multicast pour faire tourner son protocole réseau.
Le «protocole réseau de Linux ne peut tourner en broadcast ou en
multicast»?
Je ne comprends pas trop la signification de cela.
Les ordinateurs Windows sont REPUTES (cf. autre fil) utiliser
massivement le broadcast (et consommer ainsi plus de bande passante
qu'il ne serait nécessaire sur le LAN).
Dans la vie de tous les jours, il n'y a que microsoft qui s'appuie sur du broadcast ou du multicast pour faire tourner son protocole réseau.
Le «protocole réseau de Linux ne peut tourner en broadcast ou en multicast»? Je ne comprends pas trop la signification de cela.
Les ordinateurs Windows sont REPUTES (cf. autre fil) utiliser massivement le broadcast (et consommer ainsi plus de bande passante qu'il ne serait nécessaire sur le LAN).
-- Thierry
Franck Yvonnet
Ainsi Parlait Thierry
Les ordinateurs Windows sont REPUTES (cf. autre fil) utiliser massivement le broadcast (et consommer ainsi plus de bande passante qu'il ne serait nécessaire sur le LAN).
Prouve-le!
-- Franck Yvonnet "Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
Ainsi Parlait Thierry <invalid@invalid.fr>
Les ordinateurs Windows sont REPUTES (cf. autre fil) utiliser
massivement le broadcast (et consommer ainsi plus de bande passante
qu'il ne serait nécessaire sur le LAN).
Prouve-le!
--
Franck Yvonnet <franck@yvonnet.org>
"Reality is that which, when you stop believing in it, doesn't go away."
- Philip K. Dick
Les ordinateurs Windows sont REPUTES (cf. autre fil) utiliser massivement le broadcast (et consommer ainsi plus de bande passante qu'il ne serait nécessaire sur le LAN).
Prouve-le!
-- Franck Yvonnet "Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
