| Tepaze — 2014-12-29 17:54:55 |
Bonjour à tous,
Je suis embêté par un problème dont je commence à cerner l'origine (du moins je crois), mais dont je ne trouve pas de solution, notamment parce que je ne connais rien en MAO (du moins je crois)
Je stream un flux audio video via ffmpeg dont voici la commande (c'est une portion d'un script Bash) : En soit, si à la place de J'utilise Cela fonctionne sans soucis notable.
Le probleme, c'est que cela grève la qualité d'encodage, j'aimerais donc encoder avec le preset le plus lent possible (mais faster suffirait).
Or dans ce cas, j'ai des désynchronisation de son très importante, assortie de messages : Après beaucoup de recherche et de bidouillage des réglages de Jack, un peu au hasard je l'avoue, je ne touve pas de solution... Pourtant, à priori, c'est un probleme de tampon...
Ma théorie c'est que comme l'encodage faster necessite plus de temps de traitement que l'encodage ultrafast ( c'est le principe, puisque plus le preset est lent, plus l'encodeur analyse d'images et optimise l'encodage de celle ci ), la memoire tampon qui permet de synchroniser le son et l'image est dépassé, ce qui provoque d'incessant décrochage... Mais je ne suis pas sur...
Enfin, ces xrun on lieu avec ffmpeg, mais n'apparaissent pas dans Jack...
Qu'en pensez vous ? Voyez vous comment faire ?
Pour ma part, je n'arrive à rien...
Bien à vous (et joyeuses fêtes :P) |
| sakramh — 2014-12-29 23:00:13 |
je ne dirais rien sur ta commande ffmpeg (aucun job pour la tester actuellement ) si ce n'est que ... tu fais qlq chose comme du mp4 (x264 + aac ) dans du flv (sorenson + mp3) .(mais ce n'est qu'une première impression :rolleyes: )
Par contre lors de multiples essais avec Jack , moi et le dev. de tangostudio en étions arrivés à la conclusion qu'il n'est pas forcément bon de verrouiller la mémoire pour celui-ci . Nous avions constaté des conflits (je ne sais plus avec quoi, hélas) . En tout cas même si je laisse "@audio - memlock unlimited" (dans /etc/security/limits.d/audio.conf), je coche "pas de verrouillage mémoire"dans les réglages qjackcontrol . Avec un peu de chance ...
Je vais quand même prendre le temps de regarder les spécifications de ce que l'on trouve de plus en plus : du .webm
http://fr.wikipedia.org/wiki/WebM
constat : libvpx plus lente que libx264 (mais très bons résultats même en 320p)
question : la taille de ton buffer (*5) autorise jusqu'à cinq fois le maxrate . beaucoup non ? |
| Tepaze — 2014-12-30 14:04:33 |
Bonjour Sakramh,
Et merci de ton attention. Les spécifications flash sont aujourd'hui celles que j'utilise. Que ce soit avec Flash Live Media Encoder ou quelques autres encodeur (WireCast par ex.), le conteneur est en FLV, et les spécifications, de près ou de loin, celles utilisées ci dessus.
Par contre, je n'ai pas essayé de jouer avec la taille du buffer... Je vais voir. De même, je vais tenter le non verrouillage de la mémoire. Je te tiens au jus.
Bonne année :-)
[edit]
Mais bon... Le maxrate est de 650k, soit 3250k de buffer... C'est pas non plus la mort. D'autant qu'a priori, c'est une information transmise coté client, afin que le player bufferise...
La desactivation du verouillage de la memoire ne change rien...
Une autre question au hasard, cela peut il avoir un lien avec la carte son ? J'utilise un ordi portable de test, et la carte son est une carte intel de base...
Enfin, à l'issue de mon dernier test, j'ai eu une sortie console pour jack, je vous la livre : [/edit] |
| Tepaze — 2014-12-30 18:07:49 |
J'ai trouvé une solution. Il faut utiliser : Ce qui donne : Bonne fêtes |
| sakramh — 2014-12-30 20:47:26 |
et aussi : sauf si tu as forcé le mode 16bits pour jack, il te sort du 32 float . Et je ne vois aucune conversion pour l'audio . Sauf si par défaut AAC fait du 48khz/16bits . Quand même une sacrée jungle l'encodage :mad:
-threads 4 >> reste pas beaucoup de place pour le reste . J'essaie toujours pour de l'encodage à la volée de limiter à 1 .
Le noyau (si bien fait) se chargera de répartir le surplus . (l'important étant de rester légèrement au dessus du fps prévu . |
| Tepaze — 2014-12-30 22:53:53 |
Je vois ton message alors que je viens pour dire que finalement, ça ne fonctionne pas si bien que cela...
Selon les cas, de façon aléatoire j'ai l'impression, l'encodage saute, mais plus au son... C'est l'image qui hoquette à présent... Et pas systématiquement, alors je tatonne dans les réglages...
-threads 4 ou -threads 2 ne change rien chez moi...
16 bits ou pas, c'est pareil aussi...
Bon, voila quoi... |
| Jessica Nichenin — 2014-12-31 08:40:44 |
et avec un noyau temps réel ??
http://jackaudio.org/faq/linux_rt_config.html
le scale est obligatoire ?? |
| sakramh — 2014-12-31 09:29:23 |
je rappelle l'article de référence pour toutes ces questions : http://wiki.linuxaudio.org/wiki/system_configuration
bien lire les chapitres Do I really need a real-time kernel ? et Using the threadirqs kernel option .
Maintenant avec un kernel rt on peut donner des priorités à autre chose que l'audio . Mais il faut les répartir . C'est délicat .
Bien lire le fichier limits.conf et le script rtirqinit .
J'ai çà dans audio.conf : @audio - rtprio 85
@audio - memlock unlimited
##ou qté max de mémoire (unlimited est là pour empêcher des softs de se plaindre (ardour, rosegarden...) Je l'inhibe dans qjackcontrl)##
et rien n'empêche dans limits.d d'avoir un truc genre : @video - rtprio 50
@video - memlock 1000000000
chez moi pd se lance avec une prio -7
Là le souci c'est ffmpeg . Lors du transcodage d'un fichier si aucune image n'est corrompue tout se passe bien . Mais lors d'une capture (v4l2 par exemple) il y a des problèmes de synchro et donc des images qui sautent ou qui doublent .
Peut-être essayer 25 ips sur le producteur et 24 ips sur l'encodeur . Je rappelle que 18 ips est suffisant pour l'oeil en ciné . |
| Tepaze — 2014-12-31 12:12:42 |
J'ai cru au début que c'etait obligatoire, mais après lecture j'ai cru comprendre qu'il suffisait de mettre une priorité suffisament haute. J'ai mis, pour Jack, une priorité de 50 (au lieu de 70 conseiller en usage classique), mais cela n'a rien changé...
citation :le scale est obligatoire ??
En l'occurrence pour mon cas actuel, non, mais le désentrelacement (yadif=0:0:0) oui, et utilise plus de ressources je pense. De plus, ce n'est pas un probleme de temps cpu, mais plus une histoire de synchro... Le temps CPU utilisé est inferieur à 70%... Mais merci pour ces pistes.
citation :Là le souci c'est ffmpeg .
C'est ça.
citation :Mais lors d'une capture (v4l2 par exemple) il y a des problèmes de synchro et donc des images qui sautent ou qui doublent .
Pour mes test, je lis un film dans pd-exteneded > [pix_record] > v4l2 > ffmpeg. Dans ce cas, est il possible qu'il y ait des saute d'image ?
Actuellement il me semble que c'est l'encodage qui fait sauter des images, ou du son suivant les reglages...
Actuellement en priorité au vue de le commande "top" (pas dans l'ordre) j'ai : Serais ce une bonne idée de monter la priorité de ffmpeg au dessus de 20 ? |
| sakramh — 2014-12-31 12:45:54 |
20 = priorité par défaut (c'est dire si les applis sont tranquilles :cool: )
citation :Serais ce une bonne idée de monter la priorité de ffmpeg au dessus de 20 ?
pas au dessus mais en dessous .
avant lancement sinon plantage (et en général seul root sauf si le groupe y a droit)
idem pour nice renice . un simple utilisateur peut augmenter mais pas diminuer .
et souvent plantage si en cours d'exécution .
C'est vrai que c'est dans les concepts de base Unix mais les distrib. font du par défaut donc se documenter .
semble qu'il ait la prio donnée à pd (tu as de l'audio dedans ) . La preuve , cela ne reflète pas la prio de 50 donnée (devrait afficher -51)
(chez moi carte son pci -86 , carte son usb -81 , jackD -75 , des synth ou daw qui tournent -70 etc... )
citation :citation :
et avec un noyau temps réel ??
http://jackaudio.org/faq/linux_rt_config.html
J'ai cru au début que c'etait obligatoire, mais après lecture j'ai cru comprendre qu'il suffisait de mettre une priorité suffisament haute
réponse : http://wiki.linuxaudio.org/wiki/system_configuration
et encore : est il vraiment nécessaire d'utiliser jack ? pour lire du fichier audio ou du commentaire micro alsa suffit . |
| sakramh — 2014-12-31 19:35:07 |
bon alors ... fait un essai juste pour entendre . (autant que mes oreilles le permettent)
ffmpeg -f jack -i ffmpeg -acodec pcm_s16le song.wav
dans htop ffmpeg est signalé prio -70 (la même que les softs patchés sur jack, logique)
ai eu sur 15 mn , 6 Audio packet xrun (non signalés par jack (en ai jamais) donc produits dans ffmpeg)
inaudibles à la réécoute . çà devrait bien se passer :)
par contre ai l'impression que coté qualité le passage de 32 float à 16 signed (même samplerate 44100) .... :( |
| Tepaze — 2015-01-01 14:05:04 |
Ya un truc que je ne comprend pas...
J'ai creusé les priorité,et les processus suite à ton message Sakramh, et je suis étonné de voir plusieurs processus jackD, dont 1 à -51 (donc comme mis dans les prefs de jack) et un autre à 20 (et je ne confond pas avec Qjackctl).
De même, pour ffmpeg, je trouve un grosse 20aine de processus, dont 1 seul à -46 mais avec un CPU < 1%... A coté de cela, un autre processus ffmpeg prends 50% à 70%, 2 autres 15 à 25% et le reste à 0%...
J'avoue ne pas bien comprendre... |
| sakramh — 2015-01-01 14:30:16 |
moi non plus en fait :lol: . Top, htop, task-manager, etc... ne traitent pas de la même manière les threads . Top les résument en un . htop les séparent plus ou moins . nous on se gratte la tête . Suis quand même le lien donné vers Using the threadirqs kernel option pour que ta carte son suive (c'est de la gestion harware là), si tu n'utilises pas un vrai kernelRT .
Rassure toi j'ai moi aussi des doubles processus type jackd 20 et jackd -75, zynaddsubfx 20 zyndaddsubfx -70, etc... . Pour le matos audio par contre un seul process par carte répertorié par les priorités données par le script rtirqinit .
En fait aussi en standard les kernels sont compilés peu bavards pour essentiellement des raisons de taille et d'utilité . D'où les outils se débrouillent comme ils peuvent . et nous aussi :rolleyes:
il existe aussi un script perl de test pour tout çà : realtimeconfigquickscan https://github.com/raboof/realtimeconfigquickscan |
| Tepaze — 2015-01-01 19:15:25 |
Ok, merci pour toutes ces informations. Ya plus qu'a :-) |
| sakramh — 2015-01-03 20:50:57 |
J'ai aussi un peu creusé ...
Le processus ffmpeg à -46 correspond à ... la création du client jack . D'où le petit 1% .
Dans htop on peut (à peu près) considérer le pid à la plus grosse conso comme le total (sur un processeur) .
J'ai par ailleurs tenté de donner diverses prio/nice par un fichier au groupe video . Pas bon : même en quadruplant la latence jack, des déconnections intempestives .
Ai aussi refait des essais ffmpeg, cette fois avec video (-f v4l2 -sameq... -f jack -sameq ... -vcodec mjpeg ...) histoire de voir (gros débit) . Çà se passe bien une minute ou deux puis gros tremblement de terre puis bien ...
D'où faudrait quand même faire l'essai avec alsa . Le temps réel audio ne se justifie pas forcément si on n'enregistre pas 8 pistes audio en overdub plus 10 softsynth midi . Économie de ressources machine . Place pour l'encodage video/audio .
J'ai déjà fait du stream (avec gephex + ffserver en flv (mais sorenson + mp3) ou en asf avec alsa (gephex ne connaît pas jack) . Çà se passait bien . |
| sakramh — 2015-01-04 12:16:49 |
le vieux démon du stream m'a re-contaminé .
http://www.maartenbaert.be/simplescreen … r-avserver
http://nginx.org/en/download.html
https://github.com/arut/nginx-rtmp-module
quand j'aurais un moment compilerai en /local |
| Tepaze — 2015-01-04 13:26:05 |
J'ai testé ca aussi. Pas mal, mais je n'ai pas eu le temps de creuser : https://mistserver.org/ |
| sakramh — 2015-01-05 20:32:48 |
pffff ...
j'utilisais ffmpeg +ffserver . J'ai retrouvé mes anciens fichiers de conf . Soit en asf (windows-media) soit en flv (h263+mp3) . Pas retrouvé celui qui donnait les meilleurs résultats et le plus léger : mpeg ts ( mpeg2 + mpga ) . Grrrr.. :mad:
Mais refais divers essais de stream avec VLC et c'est bien le plus léger et de bonne qualité (le mpeg-ts ).
Tout de même , ayant plein d'autres choses à faire , j'ai fait quelques essais avec ce que j'ai trouvé ici :
http://wiki.labomedia.org/index.php/Flux_TaBec (merci Olivier & co)
soit pour moi (un peu dans le désordre et à affiner): pour adapter à mon patch Pd et vers un fichier vu que je n'ai aucune utilité vers un serveur de stream (et pas encore trouvé comment remplir la conf de ffserver pour ce genre de manip ).
même pas pris la peine de remettre ma carte son et jack à 44.1 (sont à 48) juste fait un ti v4l2loopback-ctl set-fps 25 (il était à 30) .
Ben résultat qualité : image quasi aussi bonne que mplayer ou vlc en direct sur le /dev/videoX
son idem
sortie std de ffmpeg indiquant un audioXrun par minute en moyenne ET à la relecture du flv effectivement un tremblement image aux mêmes temps que les Xrun (aucun dans jack) comme si elle voulait se recaler .
Pas parfait donc mais acceptable pour du stream . :cool:
Par contre, pas léger l'histoire : 180 % de cpu . Soit 45 % d'un 4 cœurs . :(
faut dire que je lui ai collé un film avec plein de particules en tous sens et un max de bruit :D |
| Tepaze — 2015-01-06 11:42:26 |
Salut Sakramh,
Je suis tenu par mon serveur de stream de fournir du flv en conteneur... citation :Pas parfait donc mais acceptable pour du stream
Ben non, pas pour nous... Mais j'ai plus ou moins trouvé la solution tout de même.Il faut à présent que j'affine avec une carte son digne de ce nom et un vrai ordi, pas un truc de bidouille. Je vais entrer en phase de test de diffusion en parallele... On va voir si c'est acceptable. Dans tous les cas cela suffit tout à fait pour faire un backup de streaming si une autre machine plante...
J'ai bien entendu utilisé les sources d'Olivier / Labomedia au début de ma recherche. Mais pour tout dire je me suis fadé une bonne partie de la documentation de ffmpeg. Voici quelques lien utilie :
La doc complete de ffmpeg : https://www.ffmpeg.org/ffmpeg-all.html
Le streaming Guide ffmpeg : https://trac.ffmpeg.org/wiki/StreamingGuide
Encoding Streaming Guide de ffmpeg : https://trac.ffmpeg.org/wiki/EncodingForStreamingSites
Les reglages particuliers pour le streaming sur YouTube : https://gist.github.com/olasd/9841772
Le blog de Fabio Sonnati, instructif sur le h264 : http://sonnati.wordpress.com/
Voila entre autre, mes sources...
Enfin, je creuse actuellement vers gstreamer afin de voir si c'est plus fiable/efficace... Mais je n'en suis qu'au stade de la découverte... |
| sakramh — 2015-01-06 12:05:57 |
citation :Je suis tenu par mon serveur de stream de fournir du flv en conteneur...
ben c'est ce que je proposais ci-dessus .
quand aux liens je vois que l'on a visité les mêmes ... ;)
je suis monté à "crf 24" plus de tremblements image sur les audioXrun mais craquements sur l'audio . va comprendre :(
-tune zerolatency met le dawa .
Je pense aussi qu'un ordi avec deux cpu modernes le ferait mieux . Les noyaux Debian supportent 16 cœurs en standard (ubuntu probablement aussi) . Je bosse sur un Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz (un peu juste) |
| Tepaze — 2015-01-06 16:31:28 |
sakramh a écrit:
tepaze a écrit:Je suis tenu par mon serveur de stream de fournir du flv en conteneur...
ben c'est ce que je proposais ci-dessus
Ah oui, pardon...
Mais pour le coup, j'utilise -tune zerolatency dans mes réglages, et cela va bien mieux... Sinon, c'est inaudible / inregardable en -preset medium...
Le CPU :
Core i5 M 480 @ 2.67GHz
Pas de carte graphique dédié. |
| sakramh — 2015-01-06 20:19:53 |
http://ytlive.blogspot.fr/2013/03/youtu … tings.html
citation :Mais j'ai plus ou moins trouvé la solution tout de même
ha ! on peut savoir ? |
| Tepaze — 2015-01-07 22:02:02 |
Mon dernier code de test : Donc ce ne doit pas être loin de ce que je vais utiliser... Mais ce n'est pas encore définitif... Me souviens plus de l'effficacité de la ligne de ré-encodage du son... A retirer si nécessaire... |
| sakramh — 2015-01-07 22:25:21 |
Merci .
Je vois que le désentrelacement a disparu : je pigeais pas trop pourquoi ( mais c'est vrai que si c'est du xDV à l'origine ...)
Sauf que les vloopback sortent en standard du RAW YUYV à 30 ips . Réglable avec v4l2loopbak-ctl . V4l2-ctl (un autre outil, voir les man des deux) donne les specifs des /dev/videox . Autant les caler pour soulager ffmpeg . Idem la carte son et jack .
baseline -level 3.1 : ben oui tout le monde a pas un truc à la pomme dernier cri . Fonctionne sur un androïd de base . Mais comme d'hab. c'est une jungle (en standard mon phone ne lit que du h263) .
Bon courage .
Ha ! me sert intensément de ajsnapshot depuis peu . Le ladish du pauvre . M'énervait surtout de repatcher ffmpeg à chaque fois .
note: dans le dernier code sur git/v4l2loopback y'a deux choix de "interlace" . :rolleyes: |
| Tepaze — 2015-01-08 13:07:03 |
Il y a toujours le désentrelacement (yadif=0:0:0), sauf que je l'ai intégré dans -filter-complex. Notre source est un ATEM en 1080i25
Mais je le redis, ce n'est qu'un code de base qui va être adapté lors de nos test en grandeur nature :-) |