[ninux-Firenze] ffmpeg questo s-conosciuto

[Emanuele Ricciardi]

Cari,
ho postato sul sito l'articolo sullo stream con ffmpeg. Ho avuto qualche
problema con la notazione della stesura dell'articolo, per mia ignoranza.
Se qualcuno ci può buttare un occhio...
Comunque accodo anche qui l'articolo:
------------------------
ffmpeg questo s-conosciuto.
Durante gli ultimi incontri ci siamo concentrati sulla possibilità di
sperimentare lo streaming audio-video sfruttando in parte la rete ninux.
L'idea è stata quella di sfruttare l'occasione della festa dell'Ex-Fila
degli scorsi 11-12-13 settembre come pretesto per mettere alla prova la
rete e streammare qualche evento musicale e così abbiamo iniziato la
sperimentazione.
Per ridurre le variabili in gioco abbiamo scelto il canale di youtube come
streamer finale verso l'utente, per ovvii motivi, così ci siamo concentrati
sul software ffmpeg, per la cattura, l'encoding e la pubblicazione
server-client per la trasmissione verso i server di youtube.

1) La cattura è avvenuta sfruttando una banale web-cam usb rilevata su
/dev/video0 di un portatile. La riga di comando per catturare dal
dispositivo video e audio e stremmare su un server è simile alla seguente:

ffmpeg -f v4l2 -i /dev/video0 -f alsa -ac 2 -i pulse -s 426x240 -vcodec
libx264  -pix_fmt yuv420p -vb 1000k -profile:v auto -preset:v fast  -g 60
-r 30 -acodec libmp3lame -ab 128k -f flv "rtmp://
a.rtmp.youtube.com/live2/nome.utente.aaaa-bbbb-cccc-dddd"
Descrizione di alcuni parametri:
-i = input
-ac = numero di canali audio
-s 426x240 = risoluzione del frame. I formati accettati da youtube sono:
426x240 854x480 1280x720
-vcodec libx264 = video codec suggerito da youtube
-pix_fmt yuv420p = formato del pixel richiesto da youtube
-vb = video bitrate adeguato alla risoluzione scelta.
-preset:v fast = è la qualità con cui viene effettuato l'encoding. Migliore
è la qualità (slow), maggiore impegno per la cpu ma flusso più leggero
sulla rete!
-g 60 = video gop size. E' la quantità di fotogrammi tra un keyframe e
l'altro. 60 significa un keyframe ogni 2 secondi (suggerito da youtube) se
imposto il framerate a 30.
-r 30 = framerate (richiesto da youtube)
-acodec libmp3lame oppure aac è il codec di compressione audio richiesto da
youtube.
-ab 128k = bitrate audio.

2) La seconda parte della riga di comando produce l'output verso i server
youtube, rispettando i requisiti severi di quest'ultimo.
3) Qui sono sorti i primi problemi. La banda in upload da Ex-Fila non era
sufficiente così abbiamo pensato di utilizzare un tool di ffmpeg, ffserver
che si occupa di pubblicare una sorgente audio-video, dopo averla encodata
nel formato adatto, nella nostra rete ninux.
ffserver -f ffserver.conf

[ffserver.conf]
HTTPPort 8091
HTTPBindAddress 0.0.0.0
MaxHTTPConnections 1000
MaxClients 10
MaxBandwidth 333000
CustomLog -

<Feed feed1.ffm>
File /tmp/feed1.ffm
FileMaxSize 400K
ACL allow 127.0.0.1
launch ffmpeg -f v4l2 -i /dev/video0 -f alsa -ac 2 -i pulse
</Feed>

<stream live.flv>
Format flv
Feed feed1.ffm
VideoCodec libx264
VideoFrameRate 30
VideoBitRate 800
VideoSize 426x240 #854x480 #1280x720 #426x240
VideoGopSize 30
VideoBufferSize 1000
AVOptionVideo crf 23
AVOptionVideo preset fast profile auto
PixelFormat yuv420p
AVOptionVideo flags +global_header
       AudioCodec aac
Strict -2
AudioBitRate 128
AudioChannels 2
AudioSampleRate 44100
AVOptionAudio flags +global_header
</Stream>

<Stream stat.html>
Format status
ACL allow localhost
ACL allow 192.168.0.0 192.168.255.255
</Stream>

<Redirect index.html>
URL http://www.ffmpeg.org/
</Redirect>

A questo punto è bastato utilizzare un'altra macchina su un nodo
direttamente collegato alla fibra 30/3 con un ffmpeg che richiedeva al
ffserver il flusso e lo "copiava" sui server youtube. Questa è la riga di
comando:
ffmpeg -i http://10.150.22.xxx:8091/live.flv -codec:copy -f flv "rtmp://
a.rtmp.youtube.com/live2/nome.utente.aaaa-bbbb-cccc-dddd"

Questa ci è sembrata la soluzione ideale, anche se perfezionabile, per
sfruttare la rete ninux ad alta velocità e uscire da una fibra per l'upload.
Anche se tecnicamente tutto ha funzionato, i risultati in termini di
qualità non sono stati all'altezza delle aspettative a causa della rete
attualmente non in perfetta efficienza, ma abbiamo già programmato una
serie di test per individuare i nodi deboli da potenziare.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/firenze/attachments/20150919/9ef85416/attachment-0002.html>