Streaming pour vieux PC ne supportant pas le fullHD.
22 réponses
Baton .rouge
Bonjour
J'ai un vieux portable qui malheuresement ne supporte pas le full HD.
J'ai fais un peu le tour des systeme de streaming (vlc par exemple), mais le problème est que c'est mon vieux PC qui doit gerer le
calcule de redimensionnement pour l'adapter à sa taille. Hors, j'ai le son et de temps en temps une image. Avec VLC, le CPU est à
100% et le ventilo fait du bruit. Pour les vidéo classique, cela ne pose pas de problème.
Donc, y a t il moyen pour mon vieux PC de se connecter sur mon serveur plutôt balaise (Dualcore 2.8 avec 8Go de ram) et de faire
en sorte que se soit lui qui traite la video et l'envoie à mon vieux PC qui fera juste office d'écran ?
Le paramètre d'affiche (résolution peuvent être fixé sur le serveur)
Peut etre un xforwarding, mais je prefère une solution simple avec un serveur streaming afin que chaque PC de chez moi puisse en
profiter via un navigateur ou avec VLC
Merci de vos lumières
--
Vous voulez un conseil ?
Ne faites jamais confiance à ceux qui vous donnent des conseils.
On 04 Jan 2014 13:45:13 GMT, Nicolas George <nicolas$ wrote:
Baton .rouge , dans le message , a écrit :
Core 2 Duo. Il me semble un T7200
Avec une machine comme ça, tu ne dois vraiment pas être loin du décodage HD en temps réel. Avant de chercher des solutions de streaming, regarde s'il n'y aurait pas moyen d'y arriver. Je te suggère de compiler mplayer depuis SVN (pour qu'il soit adapté à ton processeur) et de lancer quelque chose du genre :
Peut-être qu'un affichage framebuffer plutôt que X11 permettrait de gagner encore un petit peu de temps.
Pour info, du hd 720, le proc est à 95% en moyenne en mode fenetré. Si je met en fullscreen, j'ai que le son et quelques image de temps en temps.
La solution reste le déchargement du client vers le serveur.
Sauf que c'est une usine à gaz à mettre en oeuvre car cela impose de réencoder à la volée puisque ton PC semble incapable de traiter le flux natif.
Le plus simple semble être le réencodage que tu peux faire rapidement en batch directement sur ton serveur, par exemple en 576p (standard DVD)
Cela dit je serais intéressé par le résultat de la manip proposée par Nicolas George.
Le 04/01/2014 15:40, Baton .rouge a écrit :
On 04 Jan 2014 13:45:13 GMT, Nicolas George <nicolas$george@salle-s.org> wrote:
Baton .rouge , dans le message
<fudac95phjl7ob1safm6kisltr9hah0beg@4ax.com>, a écrit :
Core 2 Duo.
Il me semble un T7200
Avec une machine comme ça, tu ne dois vraiment pas être loin du décodage HD
en temps réel. Avant de chercher des solutions de streaming, regarde s'il
n'y aurait pas moyen d'y arriver. Je te suggère de compiler mplayer depuis
SVN (pour qu'il soit adapté à ton processeur) et de lancer quelque chose du
genre :
On 04 Jan 2014 13:45:13 GMT, Nicolas George <nicolas$ wrote:
Baton .rouge , dans le message , a écrit :
Core 2 Duo. Il me semble un T7200
Avec une machine comme ça, tu ne dois vraiment pas être loin du décodage HD en temps réel. Avant de chercher des solutions de streaming, regarde s'il n'y aurait pas moyen d'y arriver. Je te suggère de compiler mplayer depuis SVN (pour qu'il soit adapté à ton processeur) et de lancer quelque chose du genre :
Peut-être qu'un affichage framebuffer plutôt que X11 permettrait de gagner encore un petit peu de temps.
Pour info, du hd 720, le proc est à 95% en moyenne en mode fenetré. Si je met en fullscreen, j'ai que le son et quelques image de temps en temps.
La solution reste le déchargement du client vers le serveur.
Sauf que c'est une usine à gaz à mettre en oeuvre car cela impose de réencoder à la volée puisque ton PC semble incapable de traiter le flux natif.
Le plus simple semble être le réencodage que tu peux faire rapidement en batch directement sur ton serveur, par exemple en 576p (standard DVD)
Cela dit je serais intéressé par le résultat de la manip proposée par Nicolas George.
Nicolas George
"denis.paris" , dans le message <52c84e72$0$3654$, a écrit :
Le plus simple semble être le réencodage que tu peux faire rapidement en batch directement sur ton serveur, par exemple en 576p (standard DVD)
Le standard du DVD serait plutôt du 576i, qui est évidemment à éviter à tout pris.
De plus, le standard du DVD, même amendé pour utiliser du progressif plutôt que de l'entrelacé, est anamorphique : la résolution de l'image est de 720×576 pour être affiché en 16/9, donc les pixels sont rectangulaires d'un rapport 64/45. Pour afficher sur un écran actuel, dont les pixels sont carrés, il faut étirer tout ça. Sinon, c'est moche.
Or les transformations de l'image sont précisément la source des problèmes de Bâton Rouge : je suis persuadé que sa machine est capable de décoder du H.264 en 1920×1080 (« full HD ») en temps réel, parce que j'avais une machine moins puissante qui y arrivait. Il peut vérifier en testant avec « mplayer -vo null ».
Le problème, ce sont les traitements après : il faut passer ce 1920×1080 à du 1280×720 pour que ça tienne sur l'écran, et passer du yuv420p (ou 444p, ou 444p10) obtenu du décodeur au RGB que veut l'écran. Normalement, on fait faire ça à la carte graphique, en utilisant XVideo ou OpenGL. Mais chez lui, ça ne marche pas pour cause de carte graphique défectueuse.
D'où ma suggestion : d'une, gagner du temps sur le décodage pour en avoir plus pour les conversions, et de deux, réduire la qualité de la conversion pour aller plus vite.
Quoi qu'il en soit, s'il décide de passer par une reconversion, le plus efficace serait de passer par du x264-gbr, où on triche sur l'encodage H.264 pour mettre la vidéo en RGB. Ça gaspille plein de débit, mais il y a beaucoup moins de conversion à faire.
En revanche, MPlayer semble incapable d'accepter directement du RGB pour un simple affichage x11, ce qui est un peu étrange.
Et dans tous les cas, encoder spécifiquement pour la résolution de l'écran cible, évidemment.
"denis.paris" , dans le message <52c84e72$0$3654$426a74cc@news.free.fr>,
a écrit :
Le plus simple semble être le réencodage que tu peux faire rapidement en
batch directement sur ton serveur, par exemple en 576p (standard DVD)
Le standard du DVD serait plutôt du 576i, qui est évidemment à éviter à tout
pris.
De plus, le standard du DVD, même amendé pour utiliser du progressif plutôt
que de l'entrelacé, est anamorphique : la résolution de l'image est de
720×576 pour être affiché en 16/9, donc les pixels sont rectangulaires d'un
rapport 64/45. Pour afficher sur un écran actuel, dont les pixels sont
carrés, il faut étirer tout ça. Sinon, c'est moche.
Or les transformations de l'image sont précisément la source des problèmes
de Bâton Rouge : je suis persuadé que sa machine est capable de décoder du
H.264 en 1920×1080 (« full HD ») en temps réel, parce que j'avais une
machine moins puissante qui y arrivait. Il peut vérifier en testant avec
« mplayer -vo null ».
Le problème, ce sont les traitements après : il faut passer ce 1920×1080 à
du 1280×720 pour que ça tienne sur l'écran, et passer du yuv420p (ou 444p,
ou 444p10) obtenu du décodeur au RGB que veut l'écran. Normalement, on fait
faire ça à la carte graphique, en utilisant XVideo ou OpenGL. Mais chez lui,
ça ne marche pas pour cause de carte graphique défectueuse.
D'où ma suggestion : d'une, gagner du temps sur le décodage pour en avoir
plus pour les conversions, et de deux, réduire la qualité de la conversion
pour aller plus vite.
Quoi qu'il en soit, s'il décide de passer par une reconversion, le plus
efficace serait de passer par du x264-gbr, où on triche sur l'encodage H.264
pour mettre la vidéo en RGB. Ça gaspille plein de débit, mais il y a
beaucoup moins de conversion à faire.
En revanche, MPlayer semble incapable d'accepter directement du RGB pour un
simple affichage x11, ce qui est un peu étrange.
Et dans tous les cas, encoder spécifiquement pour la résolution de l'écran
cible, évidemment.
"denis.paris" , dans le message <52c84e72$0$3654$, a écrit :
Le plus simple semble être le réencodage que tu peux faire rapidement en batch directement sur ton serveur, par exemple en 576p (standard DVD)
Le standard du DVD serait plutôt du 576i, qui est évidemment à éviter à tout pris.
De plus, le standard du DVD, même amendé pour utiliser du progressif plutôt que de l'entrelacé, est anamorphique : la résolution de l'image est de 720×576 pour être affiché en 16/9, donc les pixels sont rectangulaires d'un rapport 64/45. Pour afficher sur un écran actuel, dont les pixels sont carrés, il faut étirer tout ça. Sinon, c'est moche.
Or les transformations de l'image sont précisément la source des problèmes de Bâton Rouge : je suis persuadé que sa machine est capable de décoder du H.264 en 1920×1080 (« full HD ») en temps réel, parce que j'avais une machine moins puissante qui y arrivait. Il peut vérifier en testant avec « mplayer -vo null ».
Le problème, ce sont les traitements après : il faut passer ce 1920×1080 à du 1280×720 pour que ça tienne sur l'écran, et passer du yuv420p (ou 444p, ou 444p10) obtenu du décodeur au RGB que veut l'écran. Normalement, on fait faire ça à la carte graphique, en utilisant XVideo ou OpenGL. Mais chez lui, ça ne marche pas pour cause de carte graphique défectueuse.
D'où ma suggestion : d'une, gagner du temps sur le décodage pour en avoir plus pour les conversions, et de deux, réduire la qualité de la conversion pour aller plus vite.
Quoi qu'il en soit, s'il décide de passer par une reconversion, le plus efficace serait de passer par du x264-gbr, où on triche sur l'encodage H.264 pour mettre la vidéo en RGB. Ça gaspille plein de débit, mais il y a beaucoup moins de conversion à faire.
En revanche, MPlayer semble incapable d'accepter directement du RGB pour un simple affichage x11, ce qui est un peu étrange.
Et dans tous les cas, encoder spécifiquement pour la résolution de l'écran cible, évidemment.
Nicolas George
"denis.paris" , dans le message <52c84e72$0$3654$, a écrit :
Le plus simple semble être le réencodage que tu peux faire rapidement en batch directement sur ton serveur, par exemple en 576p (standard DVD)
Le standard du DVD serait plutôt du 576i, qui est évidemment à éviter à tout pris.
De plus, le standard du DVD, même amendé pour utiliser du progressif plutôt que de l'entrelacé, est anamorphique : la résolution de l'image est de 720×576 pour être affiché en 16/9, donc les pixels sont rectangulaires d'un rapport 64/45. Pour afficher sur un écran actuel, dont les pixels sont carrés, il faut étirer tout ça. Sinon, c'est moche.
Or les transformations de l'image sont précisément la source des problèmes de Bâton Rouge : je suis persuadé que sa machine est capable de décoder du H.264 en 1920×1080 (« full HD ») en temps réel, parce que j'avais une machine moins puissante qui y arrivait. Il peut vérifier en testant avec « mplayer -vo null ».
Le problème, ce sont les traitements après : il faut passer ce 1920×1080 à du 1280×720 pour que ça tienne sur l'écran, et passer du yuv420p (ou 444p, ou 444p10) obtenu du décodeur au RGB que veut l'écran. Normalement, on fait faire ça à la carte graphique, en utilisant XVideo ou OpenGL. Mais chez lui, ça ne marche pas pour cause de carte graphique défectueuse.
D'où ma suggestion : d'une, gagner du temps sur le décodage pour en avoir plus pour les conversions, et de deux, réduire la qualité de la conversion pour aller plus vite.
Quoi qu'il en soit, s'il décide de passer par une reconversion, le plus efficace serait de passer par du x264-gbr, où on triche sur l'encodage H.264 pour mettre la vidéo en RGB. Ça gaspille plein de débit, mais il y a beaucoup moins de conversion à faire.
En revanche, MPlayer semble incapable d'accepter directement du RGB pour un simple affichage x11, ce qui est un peu étrange.
"denis.paris" , dans le message <52c84e72$0$3654$426a74cc@news.free.fr>,
a écrit :
Le plus simple semble être le réencodage que tu peux faire rapidement en
batch directement sur ton serveur, par exemple en 576p (standard DVD)
Le standard du DVD serait plutôt du 576i, qui est évidemment à éviter à tout
pris.
De plus, le standard du DVD, même amendé pour utiliser du progressif plutôt
que de l'entrelacé, est anamorphique : la résolution de l'image est de
720×576 pour être affiché en 16/9, donc les pixels sont rectangulaires d'un
rapport 64/45. Pour afficher sur un écran actuel, dont les pixels sont
carrés, il faut étirer tout ça. Sinon, c'est moche.
Or les transformations de l'image sont précisément la source des problèmes
de Bâton Rouge : je suis persuadé que sa machine est capable de décoder du
H.264 en 1920×1080 (« full HD ») en temps réel, parce que j'avais une
machine moins puissante qui y arrivait. Il peut vérifier en testant avec
« mplayer -vo null ».
Le problème, ce sont les traitements après : il faut passer ce 1920×1080 à
du 1280×720 pour que ça tienne sur l'écran, et passer du yuv420p (ou 444p,
ou 444p10) obtenu du décodeur au RGB que veut l'écran. Normalement, on fait
faire ça à la carte graphique, en utilisant XVideo ou OpenGL. Mais chez lui,
ça ne marche pas pour cause de carte graphique défectueuse.
D'où ma suggestion : d'une, gagner du temps sur le décodage pour en avoir
plus pour les conversions, et de deux, réduire la qualité de la conversion
pour aller plus vite.
Quoi qu'il en soit, s'il décide de passer par une reconversion, le plus
efficace serait de passer par du x264-gbr, où on triche sur l'encodage H.264
pour mettre la vidéo en RGB. Ça gaspille plein de débit, mais il y a
beaucoup moins de conversion à faire.
En revanche, MPlayer semble incapable d'accepter directement du RGB pour un
simple affichage x11, ce qui est un peu étrange.
"denis.paris" , dans le message <52c84e72$0$3654$, a écrit :
Le plus simple semble être le réencodage que tu peux faire rapidement en batch directement sur ton serveur, par exemple en 576p (standard DVD)
Le standard du DVD serait plutôt du 576i, qui est évidemment à éviter à tout pris.
De plus, le standard du DVD, même amendé pour utiliser du progressif plutôt que de l'entrelacé, est anamorphique : la résolution de l'image est de 720×576 pour être affiché en 16/9, donc les pixels sont rectangulaires d'un rapport 64/45. Pour afficher sur un écran actuel, dont les pixels sont carrés, il faut étirer tout ça. Sinon, c'est moche.
Or les transformations de l'image sont précisément la source des problèmes de Bâton Rouge : je suis persuadé que sa machine est capable de décoder du H.264 en 1920×1080 (« full HD ») en temps réel, parce que j'avais une machine moins puissante qui y arrivait. Il peut vérifier en testant avec « mplayer -vo null ».
Le problème, ce sont les traitements après : il faut passer ce 1920×1080 à du 1280×720 pour que ça tienne sur l'écran, et passer du yuv420p (ou 444p, ou 444p10) obtenu du décodeur au RGB que veut l'écran. Normalement, on fait faire ça à la carte graphique, en utilisant XVideo ou OpenGL. Mais chez lui, ça ne marche pas pour cause de carte graphique défectueuse.
D'où ma suggestion : d'une, gagner du temps sur le décodage pour en avoir plus pour les conversions, et de deux, réduire la qualité de la conversion pour aller plus vite.
Quoi qu'il en soit, s'il décide de passer par une reconversion, le plus efficace serait de passer par du x264-gbr, où on triche sur l'encodage H.264 pour mettre la vidéo en RGB. Ça gaspille plein de débit, mais il y a beaucoup moins de conversion à faire.
En revanche, MPlayer semble incapable d'accepter directement du RGB pour un simple affichage x11, ce qui est un peu étrange.
Baton .rouge
On 04 Jan 2014 15:27:57 GMT, Nicolas George <nicolas$ wrote:
Baton .rouge , dans le message , a écrit :
Pour info, du hd 720, le proc est à 95% en moyenne en mode fenetré. Si je met en fullscreen, j'ai que le son et quelques image de temps en temps.
Justement, les paramètres que je te donne devraient ajuster les paramètres de redimensionnement, de sorte que ça peut changer complètement ça.
Le redimensionnement necessite du calcul que seul le CPU pourra prendre en carge vue que tout ce qui touche à la carte graphique est HS. (Puce NVIDIA cramé) -- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
On 04 Jan 2014 15:27:57 GMT, Nicolas George <nicolas$george@salle-s.org> wrote:
Baton .rouge , dans le message
<987gc9l5bqjgf10lfnt8i24b1gli24vfse@4ax.com>, a écrit :
Pour info, du hd 720, le proc est à 95% en moyenne en mode fenetré. Si je
met en fullscreen, j'ai que le son et quelques image de temps en temps.
Justement, les paramètres que je te donne devraient ajuster les paramètres
de redimensionnement, de sorte que ça peut changer complètement ça.
Le redimensionnement necessite du calcul que seul le CPU pourra prendre en carge vue que tout ce qui touche à la carte graphique
est HS. (Puce NVIDIA cramé)
--
Vous voulez un conseil ?
Ne faites jamais confiance à ceux qui vous donnent des conseils.
On 04 Jan 2014 15:27:57 GMT, Nicolas George <nicolas$ wrote:
Baton .rouge , dans le message , a écrit :
Pour info, du hd 720, le proc est à 95% en moyenne en mode fenetré. Si je met en fullscreen, j'ai que le son et quelques image de temps en temps.
Justement, les paramètres que je te donne devraient ajuster les paramètres de redimensionnement, de sorte que ça peut changer complètement ça.
Le redimensionnement necessite du calcul que seul le CPU pourra prendre en carge vue que tout ce qui touche à la carte graphique est HS. (Puce NVIDIA cramé) -- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
Baton .rouge
On Sat, 04 Jan 2014 19:09:54 +0100, "denis.paris" wrote:
Le 04/01/2014 15:40, Baton .rouge a écrit :
On 04 Jan 2014 13:45:13 GMT, Nicolas George <nicolas$ wrote:
Baton .rouge , dans le message , a écrit :
Core 2 Duo. Il me semble un T7200
Avec une machine comme ça, tu ne dois vraiment pas être loin du décodage HD en temps réel. Avant de chercher des solutions de streaming, regarde s'il n'y aurait pas moyen d'y arriver. Je te suggère de compiler mplayer depuis SVN (pour qu'il soit adapté à ton processeur) et de lancer quelque chose du genre :
Peut-être qu'un affichage framebuffer plutôt que X11 permettrait de gagner encore un petit peu de temps.
Pour info, du hd 720, le proc est à 95% en moyenne en mode fenetré. Si je met en fullscreen, j'ai que le son et quelques image de temps en temps.
La solution reste le déchargement du client vers le serveur.
Sauf que c'est une usine à gaz à mettre en oeuvre car cela impose de réencoder à la volée puisque ton PC semble incapable de traiter le flux natif.
Le plus simple semble être le réencodage que tu peux faire rapidement en batch directement sur ton serveur, par exemple en 576p (standard DVD)
Cela dit je serais intéressé par le résultat de la manip proposée par Nicolas George.
L'idéale serait un réencodage à la volé du serveur au format 1280x1024. Le serveur est largement assez puissant pour en faire 3 ou 4.
Ainsi le client n'aurai rien à faire à part afficher le flux. Mon débit réseau permet sans problème plusieurs flux fullHD.
Sinon il me reste la solution du eeepc, mais avec un écran de 10" environ, c'est pas top. -- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
On Sat, 04 Jan 2014 19:09:54 +0100, "denis.paris" <denis.paris@free.fr> wrote:
Le 04/01/2014 15:40, Baton .rouge a écrit :
On 04 Jan 2014 13:45:13 GMT, Nicolas George <nicolas$george@salle-s.org> wrote:
Baton .rouge , dans le message
<fudac95phjl7ob1safm6kisltr9hah0beg@4ax.com>, a écrit :
Core 2 Duo.
Il me semble un T7200
Avec une machine comme ça, tu ne dois vraiment pas être loin du décodage HD
en temps réel. Avant de chercher des solutions de streaming, regarde s'il
n'y aurait pas moyen d'y arriver. Je te suggère de compiler mplayer depuis
SVN (pour qu'il soit adapté à ton processeur) et de lancer quelque chose du
genre :
Peut-être qu'un affichage framebuffer plutôt que X11 permettrait de gagner
encore un petit peu de temps.
Pour info, du hd 720, le proc est à 95% en moyenne en mode fenetré. Si je met en fullscreen, j'ai que le son et quelques image de
temps en temps.
La solution reste le déchargement du client vers le serveur.
Sauf que c'est une usine à gaz à mettre en oeuvre car cela impose de
réencoder à la volée puisque ton PC semble incapable de traiter le flux
natif.
Le plus simple semble être le réencodage que tu peux faire rapidement en
batch directement sur ton serveur, par exemple en 576p (standard DVD)
Cela dit je serais intéressé par le résultat de la manip proposée par
Nicolas George.
L'idéale serait un réencodage à la volé du serveur au format 1280x1024.
Le serveur est largement assez puissant pour en faire 3 ou 4.
Ainsi le client n'aurai rien à faire à part afficher le flux. Mon débit réseau permet sans problème plusieurs flux fullHD.
Sinon il me reste la solution du eeepc, mais avec un écran de 10" environ, c'est pas top.
--
Vous voulez un conseil ?
Ne faites jamais confiance à ceux qui vous donnent des conseils.
On Sat, 04 Jan 2014 19:09:54 +0100, "denis.paris" wrote:
Le 04/01/2014 15:40, Baton .rouge a écrit :
On 04 Jan 2014 13:45:13 GMT, Nicolas George <nicolas$ wrote:
Baton .rouge , dans le message , a écrit :
Core 2 Duo. Il me semble un T7200
Avec une machine comme ça, tu ne dois vraiment pas être loin du décodage HD en temps réel. Avant de chercher des solutions de streaming, regarde s'il n'y aurait pas moyen d'y arriver. Je te suggère de compiler mplayer depuis SVN (pour qu'il soit adapté à ton processeur) et de lancer quelque chose du genre :
Peut-être qu'un affichage framebuffer plutôt que X11 permettrait de gagner encore un petit peu de temps.
Pour info, du hd 720, le proc est à 95% en moyenne en mode fenetré. Si je met en fullscreen, j'ai que le son et quelques image de temps en temps.
La solution reste le déchargement du client vers le serveur.
Sauf que c'est une usine à gaz à mettre en oeuvre car cela impose de réencoder à la volée puisque ton PC semble incapable de traiter le flux natif.
Le plus simple semble être le réencodage que tu peux faire rapidement en batch directement sur ton serveur, par exemple en 576p (standard DVD)
Cela dit je serais intéressé par le résultat de la manip proposée par Nicolas George.
L'idéale serait un réencodage à la volé du serveur au format 1280x1024. Le serveur est largement assez puissant pour en faire 3 ou 4.
Ainsi le client n'aurai rien à faire à part afficher le flux. Mon débit réseau permet sans problème plusieurs flux fullHD.
Sinon il me reste la solution du eeepc, mais avec un écran de 10" environ, c'est pas top. -- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
Baton .rouge
On 04 Jan 2014 18:27:04 GMT, Nicolas George <nicolas$ wrote:
D'où ma suggestion : d'une, gagner du temps sur le décodage pour en avoir plus pour les conversions, et de deux, réduire la qualité de la conversion pour aller plus vite.
Je vais essayer ça. ça repond pas à la question d'origine qui est de faire faire le travail par le serveur, mais qui me permet d'en apprendre plus sur la video et les différentes façon de faire.
Merci
-- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
On 04 Jan 2014 18:27:04 GMT, Nicolas George <nicolas$george@salle-s.org> wrote:
D'où ma suggestion : d'une, gagner du temps sur le décodage pour en avoir
plus pour les conversions, et de deux, réduire la qualité de la conversion
pour aller plus vite.
Je vais essayer ça. ça repond pas à la question d'origine qui est de faire faire le travail par le serveur, mais qui me permet
d'en apprendre plus sur la video et les différentes façon de faire.
Merci
--
Vous voulez un conseil ?
Ne faites jamais confiance à ceux qui vous donnent des conseils.
On 04 Jan 2014 18:27:04 GMT, Nicolas George <nicolas$ wrote:
D'où ma suggestion : d'une, gagner du temps sur le décodage pour en avoir plus pour les conversions, et de deux, réduire la qualité de la conversion pour aller plus vite.
Je vais essayer ça. ça repond pas à la question d'origine qui est de faire faire le travail par le serveur, mais qui me permet d'en apprendre plus sur la video et les différentes façon de faire.
Merci
-- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
Nicolas George
Baton .rouge , dans le message , a écrit :
Le redimensionnement necessite du calcul que seul le CPU pourra prendre en carge vue que tout ce qui touche à la carte graphique est HS. (Puce NVIDIA cramé)
Oui, j'ai bien compris (bis). Mais d'une part, selon la qualité, ce redimensionnement (et la conversion d'espace de couleur) peut demander plus ou moins de temps de calcul, et d'autre part, en réduisant le temps de décodage on libère du temps pour le redimensionnement.
Baton .rouge , dans le message
<5qngc9p0jv967mvek0763cgnnms8g3p7q3@4ax.com>, a écrit :
Le redimensionnement necessite du calcul que seul le CPU pourra prendre en
carge vue que tout ce qui touche à la carte graphique est HS. (Puce NVIDIA
cramé)
Oui, j'ai bien compris (bis). Mais d'une part, selon la qualité, ce
redimensionnement (et la conversion d'espace de couleur) peut demander plus
ou moins de temps de calcul, et d'autre part, en réduisant le temps de
décodage on libère du temps pour le redimensionnement.
Le redimensionnement necessite du calcul que seul le CPU pourra prendre en carge vue que tout ce qui touche à la carte graphique est HS. (Puce NVIDIA cramé)
Oui, j'ai bien compris (bis). Mais d'une part, selon la qualité, ce redimensionnement (et la conversion d'espace de couleur) peut demander plus ou moins de temps de calcul, et d'autre part, en réduisant le temps de décodage on libère du temps pour le redimensionnement.
Baton .rouge
On 04 Jan 2014 13:45:13 GMT, Nicolas George <nicolas$ wrote:
Peut-être qu'un affichage framebuffer plutôt que X11 permettrait de gagner encore un petit peu de temps.
J'ai vu qu'on pouvait lancer des vidéo directement dans un TTY, mais chez moi, ça fait de l'ascii-art ou bien juste du son et le texte indiquant le n° du frame ;o))
Avec juste de l'audio, je suis à environ 1% de charge du cpu ;o))
-- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
On 04 Jan 2014 13:45:13 GMT, Nicolas George <nicolas$george@salle-s.org> wrote:
Peut-être qu'un affichage framebuffer plutôt que X11 permettrait de gagner
encore un petit peu de temps.
J'ai vu qu'on pouvait lancer des vidéo directement dans un TTY, mais chez moi, ça fait de l'ascii-art ou bien juste du son et le
texte indiquant le n° du frame ;o))
Avec juste de l'audio, je suis à environ 1% de charge du cpu ;o))
--
Vous voulez un conseil ?
Ne faites jamais confiance à ceux qui vous donnent des conseils.
On 04 Jan 2014 13:45:13 GMT, Nicolas George <nicolas$ wrote:
Peut-être qu'un affichage framebuffer plutôt que X11 permettrait de gagner encore un petit peu de temps.
J'ai vu qu'on pouvait lancer des vidéo directement dans un TTY, mais chez moi, ça fait de l'ascii-art ou bien juste du son et le texte indiquant le n° du frame ;o))
Avec juste de l'audio, je suis à environ 1% de charge du cpu ;o))
-- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
Az Sam
"Baton .rouge" a écrit dans le message de news:
Sinon il me reste la solution du eeepc, mais avec un écran de 10" environ, c'est pas top.
il y a aussi les eebox, sans écran, ou de l'ITX
-- Cordialement, Az Sam.
"Baton .rouge" <nospam@trash.nul> a écrit dans le message de
news:vsngc91f1jkjog1eoqbkmqef2apsf2unc2@4ax.com...
Sinon il me reste la solution du eeepc, mais avec un écran de 10"
environ, c'est pas top.
Sinon il me reste la solution du eeepc, mais avec un écran de 10" environ, c'est pas top.
il y a aussi les eebox, sans écran, ou de l'ITX
-- Cordialement, Az Sam.
Baton .rouge
On Sun, 5 Jan 2014 07:18:09 +0100, "Az Sam" wrote:
"Baton .rouge" a écrit dans le message de news:
Sinon il me reste la solution du eeepc, mais avec un écran de 10" environ, c'est pas top.
il y a aussi les eebox, sans écran, ou de l'ITX
Et je regarde où ? Si on va dans cette direction autant prendre un RPi et un écran le tout dans une boite. -- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
On Sun, 5 Jan 2014 07:18:09 +0100, "Az Sam" <me@home.net> wrote:
"Baton .rouge" <nospam@trash.nul> a écrit dans le message de
news:vsngc91f1jkjog1eoqbkmqef2apsf2unc2@4ax.com...
Sinon il me reste la solution du eeepc, mais avec un écran de 10"
environ, c'est pas top.
il y a aussi les eebox, sans écran, ou de l'ITX
Et je regarde où ?
Si on va dans cette direction autant prendre un RPi et un écran le tout dans une boite.
--
Vous voulez un conseil ?
Ne faites jamais confiance à ceux qui vous donnent des conseils.
On Sun, 5 Jan 2014 07:18:09 +0100, "Az Sam" wrote:
"Baton .rouge" a écrit dans le message de news:
Sinon il me reste la solution du eeepc, mais avec un écran de 10" environ, c'est pas top.
il y a aussi les eebox, sans écran, ou de l'ITX
Et je regarde où ? Si on va dans cette direction autant prendre un RPi et un écran le tout dans une boite. -- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
