ffmpeg, rtmp, jack et Audio packet xrun

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) :

./ffmpeg/ffmpeg \
	-f v4l2 -i /dev/video23 \
	-f jack -i ffmpeg -ac 2 \
	-filter_complex "[0:v] scale=640:360" -deinterlace \
	-vcodec libx264 -pix_fmt yuv420p \
	-r 25 -g 50 \
	-crf 28 -preset faster -maxrate $1k -bufsize $((5*$1))k \
	-acodec libfdk_aac -vbr 3 \
	-f flv rtmp://mon-url.com

En soit, si à la place de

-preset faster

J'utilise

 -preset ultrafast

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 :

[jack @ 0x9a3b360] Audio packet xrun

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 )

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 )
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 ?

Dernière modification par sakramh (2014-12-30 11:26:07)

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 :

Jack: JackClient::Deactivate
Jack: JackClient::Deactivate res = 0
Jack: JackPosixThread::Kill
Jack: jack_client_close
Jack: JackClient::Close ref = 5
Jack: JackClient::Deactivate
Jack: JackSocketClientChannel::Stop
Jack: JackPosixThread::Kill
Jack: JackClientSocket::Close
Jack: JackClientSocket::Close
Jack: JackPosixSemaphore::Disconnect name = jack_sem.1000_default_ffmpeg
Jack: JackLibClient::~JackLibClient
Jack: JackShmReadWritePtr1::~JackShmReadWritePtr1 4
Jack: Succeeded in unlocking 422 byte memory area
Jack: JackLibGlobals Destroy 9dc3c10
Jack: ~JackLibGlobals
Jack: JackPosixSemaphore::Disconnect name = jack_sem.1000_default_system
Jack: JackPosixSemaphore::Disconnect name = jack_sem.1000_default_freewheel
Jack: JackPosixSemaphore::Disconnect name = jack_sem.1000_default_dbusapi
Jack: JackPosixSemaphore::Disconnect name = jack_sem.1000_default_qjackctl
Jack: JackPosixSemaphore::Disconnect name = jack_sem.1000_default_pd_extended_0
Jack: no message buffer overruns
Jack: JackPosixThread::Stop
Jack: JackPosixThread::ThreadHandler : exit
Jack: JackShmReadWritePtr::~JackShmReadWritePtr 1
Jack: Succeeded in unlocking 1186 byte memory area
Jack: JackShmReadWritePtr::~JackShmReadWritePtr 0
Jack: Succeeded in unlocking 82274202 byte memory area
Jack: jack_client_close res = 0
Received signal 2: terminating.

[/edit]

Dernière modification par Tepaze (2014-12-30 14:24:09)

Tepaze · 2014-12-30 18:07:49

J'ai trouvé une solution. Il faut utiliser :

-tune zerolatency

Ce qui donne :

./ffmpeg/ffmpeg \
	-f v4l2 -i /dev/video23 \
	-f jack -i ffmpeg \
	-filter_complex "[0:v] scale=640:360, yadif=0:0:0"  \
	-pix_fmt yuv420p -threads 4 \
	-vcodec libx264 \
	-crf 21 -crf_max 33 -preset medium -tune zerolatency \
	-profile:v main -level 3.1 \
	-r 25 -g 125 \
	-maxrate $1k -bufsize $((5*$1))k \
	-acodec libfdk_aac -ac 2 -b:a 40k \
	-f flv rtmp://mon-url.com

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
-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 .

Dernière modification par sakramh (2014-12-30 20:57:51)

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é .

Dernière modification par sakramh (2014-12-31 09:38:04)

Tepaze · 2014-12-31 12:12:42

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. 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 :

ffmpeg	> 20
Xorg	> 20
Firefox	> 20
pd	> -7
jackd	> -7

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 )

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 .

citation :
-7 pour jackD

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 .

Dernière modification par sakramh (2014-12-31 13:33:45)

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) ....

Dernière modification par sakramh (2014-12-31 19:41:13)

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 . 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
il existe aussi un script perl de test pour tout çà : realtimeconfigquickscan https://github.com/raboof/realtimeconfigquickscan

Dernière modification par sakramh (2015-01-02 11:05:44)

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 .

Dernière modification par sakramh (2015-01-03 20:52:48)

Annonce

#1 2014-12-29 17:54:55 ffmpeg, rtmp, jack et Audio packet xrun

ffmpeg, rtmp, jack et Audio packet xrun

#2 2014-12-29 23:00:13 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

#3 2014-12-30 14:04:33 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

#4 2014-12-30 18:07:49 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

#5 2014-12-30 20:47:26 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

#6 2014-12-30 22:53:53 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

#7 2014-12-31 08:40:44 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

#8 2014-12-31 09:29:23 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

#9 2014-12-31 12:12:42 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

citation :

citation :

citation :

citation :

#10 2014-12-31 12:45:54 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

citation :

citation :

citation :

#11 2014-12-31 19:35:07 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

#12 2015-01-01 14:05:04 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

#13 2015-01-01 14:30:16 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

#14 2015-01-01 19:15:25 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

#15 2015-01-03 20:50:57 Re : ffmpeg, rtmp, jack et Audio packet xrun

Re: ffmpeg, rtmp, jack et Audio packet xrun

Pied de page des forums