Re: Pas encore au niveau de VLC

Si je reprends mon exemple, j'aurai aussi pu me passer de gstreamer, avec un truc qui parait bien plus simple avec arecord/aplay, netcat et celtenc/celtdec

arecord -f dat --file-type raw | celtenc --16bit --rate 48000 --stereo --bitrate 256 --framesize 64 - - | netcat -q0 -l -p 2999 | celtdec - - | aplay -f dat

sachant que -f dat correspond à --format S16_LE --rate 48000 --channels 2

Effectivement, quand on compare la première méthode que j'ai présenté et celle ci pour faire du duplex audio en CELT, et la méthode de guillaume et la tienne pour encoder en mp3, y a pas photo, celles qui n'utilisent pas gstreamer sont plus simple.

Sauf que... dans mon exemple avec netcat
- je ne sais pas gérer la gigue
- si un des deux bouts plantes, les deux s'arrêtent
- si l'un des deux envoie avec de l'avance, c'est autant de retard (accumulé dans le pipe) qui ne sera jamais récupéré
- etc.

Dans ton exemple de fichier mp3, clairement, les paramêtres d'ffmpeg sont conçus pour les usages communs quand on garde tout par défaut, donc évidemment ça déchire tout, il va deviner ton format avec l'extension, etc. Si tu veux modifier ces optiond par défaut (cbr ou vbr ? échantillonage ? nombre de canaux ? bitrate ? ta commande ffmpeg ne sera pas beaucoup plus courte que la commande gstreamer. Et avec la commande gstreamer, tu pourras faire plus que ce que tu fais avec ffmpeg. Ton -i il prend un fichier, avec gstreamer tu n'as pas que les fichiers, tu va pouvoir prendre en source un flux réseau (udp, ou avec netcat ;), une archive... Tu pourras toujours piper ton entrée standard avec d'autres outils, mais c'est justement là qu'on approche l'avantage cité par Guillaume : ton pipe gstreamer, il contient des métadonnées sur la nature du flux que tu pipe.

Là où avec les pipe unix, il faut que tu surcharges toutes tes commabdes du format d'échange

arecord --format S16_LE --rate 48000 --channels 2 --file-type raw | celtenc --16bit --rate 48000 --stereo --bitrate 256 --framesize 64 --comp 0 - -

une fois que tu as précisé le format que tu voulais audio/x-raw-int,rate=48000,width=16,channels=2, tu n'as plus besoin de le repréciser entre chaque pipe, si on voulait ajouter des effets par exemple :

gst-launch-0.10 -v alsasrc ! audioconvert audioresample ! "audio/x-raw-int,rate=48000,width=16,channels=2" ! effet1 option-effet1 ! effet2 option-effet2 ! effet3 option-effet3 ! celtenc option-celtenc ! rtpceltpay ! udpsink

alors qu'avec des pipe unix tu fais un truc du genre

arecord --format S16_LE --rate 48000 --channels 2 --file-type raw | effet1 --format S16_LE --rate 48000 --channels 2 --file-type raw --option-effet1 | effet2 --format S16_LE --rate 48000 --channels 2 --file-type raw --option-effet2 | effet3 --format S16_LE --rate 48000 --channels 2 --file-type raw --option-effet3 | celtenc --16bit --rate 48000 --stereo --bitrate 256 --framesize 64 --comp N - - | monPayloadRtpSurUDP --bitrate 256 --framesize 64 --comp N --option-rtp

et j'imagine même pas si je veux traiter la vidéo en même temps que le son, sur le même pipe ;) déjà que piper de la vidéo c'est bien plus coton que du son PCM...

Donc en fait, ffmpeg (et mplayer) c'est bien tant que tu n'as rien à piper, et que tu travailles de fichier standard vers fichier standard, avec des options communes, ton exemple d'extraire un mp3 d'un flv.
Dès que les options ne sont pas celles par défaut, la verbosité devient kifkif, alors dès que les usages commencent à ne plus être "communs", n'en parlons pas :)

VLC s'approche plus de ce que fait Ggstreamer, mais là je suis d'accord avec toi, c'est inhumain. :D

ce commentaire est sous licence cc by 4 et précédentes