Voila j'ai eu un problème pour lire des .wmv (no comment) et peut être d'autres formats(oui je devrait convertir tout ça je sais pas la peine de me le dire)
Donc le problème et que ça lisait beaucoup trop vite (le son et la video)
la methode que j'ai trouvée et de passer -srate 44000 (pas sur du nombre exact, si quelqu'un pouvait confirmer ça ne serait pas supperflux.
Et pour avoir ces reglages definitivement faites:
echo srate=44000 >> /etc/mplayer/mplayer.conf
en root
si vous n'avez pas d'accès root vous pouvez faire en user:
echo srate=44000 >> ~/.mplayer/mplayer.conf
Je sais faudrait le mettre en astuce, mais si vous pouviez confirmez les 44000Hz avant ca pourait etre bien
Journal Problème résolu pour mplayer
23
fév.
2004
# Re: Problème résolu pour mplayer
Posté par seginus . Évalué à 1.
Pour tester, j'ai fait un google fight et j'obtiens 2430 pour "44000 Hz" et 46200 pour "44100 Hz" .
Je sais que c'est pas la méthode la meilleur qui soit mais bon.
(oui je devrait convertir tout ça je sais pas la peine de me le dire)
personnellement, ce sont des formats que j'ai jamais réussi à convertir, les résultats que j'obtiens sont toujours déplorables au niveau qualité/taille par rapport à l'original. Je pense que ça doit venir des différences entre les algorithmes de compressions ce qui fait que tu cumules les défauts de chaques encodage (ou codage, c'est comme vous voulez).
[^] # Re: Problème résolu pour mplayer
Posté par Ph Husson (site web personnel) . Évalué à 1.
enfin c'est la valeur par défaut dans le centre de control kde (il est tout beau le KDE 3.2 au fait)
et pour reencoder j'ai quand même un peu téster mais marchant sans problèmes sur mon linux(un PC) je m'en fiches un peu
enfin il parait que maintenant ca marche meme avec ffmpeg donc sur PPC/sparc(y a du son sur ca?)/alpha etc
[^] # Re: Problème résolu pour mplayer
Posté par xilun . Évalué à 1.
C'est la fréquence d'échantillonnage des CD audios.
Ou alors ptet 48000 Hz, c'est celle des DVD.
Mais 44000 ne correspond à aucune norme.
# Re: Problème résolu pour mplayer
Posté par jeff110 . Évalué à 1.
Perso, j'avais le meme probleme que toi, mais avec les ogg et cette m*rd* de nforce2 ...
(ça ne le faisait que pour des configue bien specifiques, sous mdk 9.2.)
probleme resolu en passant le son par artsd et debit specifié.
# Re: Problème résolu pour mplayer
Posté par Macolu (site web personnel) . Évalué à 1.
Exemple, mon .asoundrc (enfin, une partie) :
pcm.plop {
type dmix
ipc_key 1024 # must be unique!
slave {
pcm "hw:0,0" # you cannot use a "plug" device here, darn.
period_time 0
period_size 1024 # must be power of 2
buffer_size 16384 # dito. It
rate 48000
donc perso, j'utilise "-srate 48000"
Voilà...
[^] # Re: Problème résolu pour mplayer
Posté par Ph Husson (site web personnel) . Évalué à 1.
yamaha ou un truc du style
enfin merci de l'ajout d'info
[^] # Re: Problème résolu pour mplayer
Posté par Rin Jin (site web personnel) . Évalué à 1.
Dans tout les cas, j'ai utilisé les drivers alsa du 2.6.*
[^] # Re: Problème résolu pour mplayer
Posté par jaroug (site web personnel) . Évalué à 1.
Merci.
[^] # Re: Problème résolu pour mplayer
Posté par Ph Husson (site web personnel) . Évalué à 1.
eh ben franchement j'avais entendu dire que alsa s'en occupé mais non
Il faut toujours un server de son
SAUF si la carte son (et le driver avec) le supporte
[^] # Re: Problème résolu pour mplayer
Posté par Macolu (site web personnel) . Évalué à 1.
Alsa permet de créer des périphériques virtuels, qui ne correspondent à aucun matériel, mais qui permettent de faire tout un tas de manipulations sur les flux sonores. Si rien de particulier n'est configuré, il existe un seul périphérique, appelé "default" (logique), et qui se contente d'envoyer le son au vrai périphérique, appelé "hardware" (la carte son, en gros). En tout cas, c'était comme ça chez moi :-).
L'idée, c'est de paramétrer un module appelé "dmix", qui est capable de recevoir plusieurs flux (envoyés par les applications), de les fusionner, et d'envoyer le résultat au hardware. Super, c'est juste ce qu'il nous faut. Sauf que, ce "dmix" ne sais pas gérer les fréquences d'échantillonnages multiples : il faut forcément que tous les flux qu'il reçoit soient de même fréquence que le flux final envoyé au hardware. Pour avoir une qualité de son normale, le flux dmix -> hardware sera à 44100 ou 48000 Hz. Concrêtement, si vous lisez une vidéo ou un fichier son avec un taux d'échantillonage plus faible, le fichier sera lu trop rapidement (avec un son trop aigu).
Pour éviter ça, il y a le module "plug". Son rôle et de recevoir les flux envoyés par les applications, de tous les convertir en 44100 ou 48000, et de les envoyer à "dmix", qui lui va les fusionner et les envoyer au hardware.
Enfin, pour éviter de devoir reconfigurer toutes les applications, il faut faire en sorte que le "plug" soit le périphérique par défaut, pour que les applications y envoient leur flux sonore.
Donc au final, on a : application -> plug -> dmix -> carte son.
Pour régler tout ça, ça se passe dans le ~/.asoundrc. Le mien est ici :
http://www.macolu.org/.asoundrc(...)
Voilà, c'est ce que j'ai fait chez moi, et ça permet d'avoir plusieurs sons en même temps sur toutes les cartes sons, même les plus basiques.
Avec cette méthode, j'arrive à avoir plusieurs sons dans toutes les applis que j'utilise : mplayer, xmms, toutes les applis SDL, et j'en oublie sûrement.
Pour les cartes plus évoluées, et qui gèrent le mixage en hard, je en pense pas qu'il soit nécessaire de faire tout ça.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.