Streamování audia separátně od videa (téměř howto)

15.7.2012 18:33 | Přečteno: 1400× | programování |

Člověk by si myslel, že s věcma jako ffmpeg/ffserver, vlc, pulseaudio, bluetooth, crtmpserver apod. by neměl být až takový problém dostat kopii audio streamu ze zvukovky na nějaké ± rozumné handheld zařízení. Že nastaví streaming na některý podporovaný protokol/kontejner/formát a pak možná už jen bude řešit latenci. V případě Androidu (staršího) to byl ale pořádný oříšek a to jsem zkoušel i věci jako zbuildit komplet patchnutý AOSP s alpha portem pulseaudia.

Nejprve napíši HOWTO, nadávat co kde proč nešlo budeme později. Na získaní audia budeme používat pulseaudio, takže nahrávací aplikace musí podporovat pulseaudio (nejjednodušší test: ldd binárka | grep pulse). Teoreticky by mělo jít i nahrávaní s alsou, když si člověk vytvoří loopback device kopírující zvukovku, ale u mně to nechtělo fungovat (a mute-nutím to nebylo, loopback neměl žádný mixer). Případně viz příklad vytvoření alsa loopbacku přes snd-aloop modul.

HOWTO s pulseaudio, ffmpeg a ffserver

Vytvoření pulseaudio monitoru pro audio které chceme nahrávat/streamovat

Pulseaudio má základní koncepty: source, sink, sink-input a source-output (odkud zvuk leze, kam leze a propojení od aplikace generující zvuk nebo třeba mikrofonu). Sink-input a source-output lze za jistých okolností přesouvat mezi sinkama, sinky lze "nacpát" jeden do druhého. Hlavní utility na ovládání pulseaudia jsou commandlinové pacmd, pactl a pak nepříliš užitečné GUI udělátka pavucontrol a paprefs.

Speciální "tajný trik" je, že každý sink má monitor, který je ale source. Napojením na monitor lze pak třeba nahrávat celý výstup pulseaudia, nebo jenom některý sink. Pro nahrávání celé zvukovky musíme zjistit jméno monitoru (pozor pokud je zvukovek víc, na tom se běžně rozbíjí skripty povalující se po netu), un-mute-neme ho a můžeme z něj nahrávat:

#vypise nazvy monitoru a par radek kolem s indexem zdroje
#u mne se treba monitor pro alsa zvukovku jmenuje alsa_output.pci-0000_00_1b.0.analog-stereo.monitor
pactl list | grep -C 3 'Name: .*\.monitor$' 

#ulozime si jmeno do promenny, at porad nemusime copypastovat a un-mute-neme
export MONITOR=paste_above_monitor_name_here
pacmd set-source-mute "$MONITOR" false

#nahrani sample fajlu, encoding do mp3
ffmpeg -y -f pulse -i "$MONITOR" -ar 44100 -ab 96k -ac 2 file.mp3

Pro nahrávání jenom jedný nebo několik specifických aplikací můžeme vytvořit manuálně sink loadnutím modulu (v pulseaudio terminologii se snad všechno nazývá modulem, asi kvůli přehlednosti). V závislosti od toho, jestli nahrávaná aplikace podporuje určení sinku jsou dva možné moduly - module-combine a module-null. Např. mplayer dovoluje specifikovat sink přes mplayer -ao pulse::combined file, kde "combined" je název sinku. Příklad pro null a combined sink moduly:

#####Priklad combine-sinku
#podle pulseaudia verze se jmeno mirne lisi
pacmd load-module module-combine sink_name=combined #pulseaudio < 1.0
pacmd load-module module-combine-sink sink_name=combined #pulseaudio >= 1.0

#monitor sinku "combined" se bude jmenovat "combined.monitor", ale pro jistotu
#to muzete otestovat vyse uvedenym pactl-grep-magicem
#opet un-mute-neme, pustime tam nejake audio a muzeme nahravat
pacmd set-source-mute combined.monitor false

#pustime si tam jeden az vice zdroju, at mame co nahravat
mplayer -ao pulse::combined file 
ffmpeg -y -f pulse -i combined.monitor -ar 44100 -ab 96k -ac 2 file.mp3


#####Priklad null-sinku
#vytvorime null-sink, coz je "ekvivalent /dev/null", ale ma monitor
pactl load-module module-null-sink sink_name=nullsink
#pustime prehravani audia, nalezneme index jeho sink-inputu (dale jako $INDEX)
pacmd list-sink-inputs
#unmute, presuneme prehravani sink-inputu do null sinku
pacmd set-source-mute nullsink.monitor false
pactl move-sink-input $INDEX nullsink
#a nahravame z monitoru
ffmpeg -y -f pulse -i nullsink.monitor -ar 44100 -ab 96k -ac 2 file.mp3

Nahrávání z "umělých" sink-monitorů má zvláštní vlastnost, že pokud do sinku nic nevysílá, tak se nahrávající aplikace uspí někde na čtení dokud tam něco zas nepoleze.

Streaming přes ffserver/ffmpeg

Na to je spousta návodů na netu, uvedu jen copypasta ffserver configy pro HTTP/mp3 a RTSP/aac. Podstatná část je zjistit, co klientská Android aplikace podporuje. Zjistíte, že téměř nic. Raw mp3/aac/ogg/whatever stream je velký problém, Android podporuje interně RTSP, ale všechny zkoušené RTSP streaming aplikace mi padaly.

Raw mp3 stream nejde přímo, musíte si vytvořit primitivní HTTP server vracející m3u playlist (jeden řádek s URL na mp3 stream v odpovědi, content-type by měl být asi audio/x-mpegurl). Pro tento účel jsem si zkopíroval někde z netu pythoní BaseHTTPServer example. Takže ty dva sample configy pro ffserver:

Port 8090
MaxHTTPConnections 50
MaxClients 3
MaxBandwidth 1024
CustomLog -
NoDaemon

<Feed feed1.ffm>
File /tmp/feed1.ffm
FileMaxSize 100M
</Feed>

# MP3 audio

<Stream audio.mp3>
Feed feed1.ffm
Format mp2
AudioCodec libmp3lame
AudioBitRate 128
AudioChannels 2
AudioSampleRate 44100
NoVideo

#ACL allow localhost
</Stream>

Port 8090
RTSPPort 5454
MaxHTTPConnections 50
MaxClients 10
MaxBandwidth 1024
CustomLog -
NoDaemon

<Feed feed1.ffm>
File /tmp/feed1.ffm
FileMaxSize 100M
</Feed>


<Stream live.aac>
Format rtp
Feed feed1.ffm
NoVideo

AudioCodec libfaac
AudioBitRate 96
AudioChannels 2
AudioSampleRate 22050
AVOptionAudio flags +global_header
</Stream>

Pak už jen spuštění ffserveru a feedovat z vybraného sinku data ffmpegem:

#v ruznych terminalech
ffserver -f ffserver_mp3.conf
ffmpeg -y -f pulse -i 'combined.monitor' http://localhost:8090/feed1.ffm

Darkice mnoho lidí doporučovalo, taky podporuje pulseaudio nahrávání (nevím jestli lze určit source), má výstup jako m3u/mp3, ale nezkoušel jsem, protože největší problém je stejně na klientské straně.

Litanie nad tím co všechno nefungovalo

Předně streamovací aplikace pro Android jsou neuvěřitelná, ale skutečně neuvěřitelná bída. Buď padají, slibují něco co neumí, vyžadují vlastní closed-source server, z popisu často nepoznáte co mají umět (uvést protokol? co je to protokol?). Výsledky vyhledávačů jsou neuvěřitelně zamořeny katalogy, malwarem, podobně nazvanými kopiemi, takže ke každé aplikaci nejprve musíte nejprvě udělat "background check" a stejně zjistíte, že když už to skutečně nějaký streaming má, tak vlastní URL můžete zadat jenom v placené verzi.

Těch pár dolarů by mi ani nevadilo, ale jak má asi člověk poznat jestli to bude mít rozumnou latenci? Na free verzi může zkusit třeba dekompilaci nebo MitM na předdefinované stream URL; nebo zaplatit, zkusit a nechat vrátit peníze (myslím že market to do N dnů dovoluje). Jedno horší než druhé - jen zkoušení nějakých cca 15 aplikací, které vypadaly že by už moohly fungovat, byla neskutečná pruda.

Jiné vyzkoušené alternativy

Nejlépe vypadal ten port pulseaudia, ale na verzi AOSP menší než 4.0.2 se mi to nepodařilo přeložit (mimochodem, AOSP git repa mají tak 12 GB, celá zbuilděná věc asi 25 GB a při buildu to spolehlivě uswapuje mašinu s 4 GB RAM). Jiné realtime protokoly jako RTPM nemají implementaci, nepodporuje je ani flash pro android a navíc jsem chtěl mít co nejméně middleware, protože jinak se to hodně projeví na latenci. Bluetooth audio nelze použít, protože mobil nemá profil přijímače (jen vysílače). S DLNA už ani nevím co bylo.

Jednou jsem ze zoufalosti dokonce zkoušel hledat v Bingu. Zázrak se očekávatelně nekonal.

Dokumentace

U alsy a pulseaudia i s dokumentací a man stránkami se to zdálo víc jak reverse-engineering hrubou silou. Spousta věcí ma podivné vedlejší účinky, třeba pulseaudio TCP streaming chtělo zeroconf (avahi), což mi dočasně rozbilo síťování tak, až jsem v jednu chvíli debugoval net-tools/netstat (jehož zdrojáky a konfigurace je asi jak když na vás dýchnou 30-let starý kostlivci). Dohledat nějaké požadavky/očekávaní na RTSP stream u Android klientských aplikací je zhola nemožné (tam je člověk rád pokud je v popisu vůbec napsáno, že to má umět RTSP).

Závěr

Nejjednodušší by bylo koupit bluetooth sluchátka. Stejně je to jak z WTF-landu jak je možné že tak jednoduchá věc nemá po tak dlouhé době implementaci a místo toho se bastlí zbytečně složitejší protokoly.

       

Komentáře

[the.max]

Takze ve vysledku je fakt lepsi koupit ty BT sluchatka, jednak budou lehci nez telefon se sluchatkama a pak to asi i dele vydrzi na baterku ...nehlede o cene usetreneho casu

[Grunt]

Teď nechápu. To streamuješ z Androida na PC nebo z PC na Android? Jinak Zeroconf je potřeba pro automatický Discovery klientů PA. Jinak dvakrát neklikneš, ale musíš se srát s adresama, atd.

[limit_false]

Z PC na Androida. Zeroconf by měl být vyžadován jenom pro discovery, ale v průběhu zkoušení se mi nějak povedlo pulseaudio "odexperimentovat" do stavu, že to chtělo zeroconf i když bylo discovery pro klienty vypnuté a nějak sebou seklo.

Osobně zeroconf u drtivé většiny protokolů nesnáším, protože rychle vyprasené firmware u různých "krabiček" přináší často mnohem více problémů, než kdyby tam člověk zadával adresy ručně.

Pulseaudio se navzájem s alsou a výrobci HW (intel HDA typicky) obviňují navzájem třeba kdo může za neplynulý zvuk. Fakt je, že jsem ještě neviděl pulseaudio fungující vždy out-of-the-box bez občasného "zakuckání".

[Grunt]

Teda mi to fungovalo.

[elenril]

Ono taky někdo používá ffserver a doopravdy mu to funguje? No teda, jsem ohromen. Na to, že ten program už dlouhé roky nikdo neudržuje a všichni vývojáři ho nenávidí, je to docela zázrak.

[limit_false]

ffserver není v ideálním stavu, ale třeba na HTTP streaming mi vždy fungoval OK, s RTSP je to už trocha těžší. Různých streamovacích serverů je spousta, ale potřeboval jsem něco lightweight - kde by případně rychle dohackovat jednoduchou synchronizaci na snížení latence. Dokonce se mi zdá, že s ffserverem jsem zatím na streamování měl vždy víc úspěchu než s vlc.

Možná by ještě šlo vyzkoušet Darwin streaming server, ale na to jsem zatím neměl sil. Stejně zde je největší problém na straně klienta - člověk neví, co implementace v aplikaci skutečně umí, dokud na něj nenaháže náhodně protokoly a dívá se, co zůstane držet.

A jinak - vývojáři obecně nesnáší starý kód, protože časem stářím se začíná prasit - především pokud ze začátku šlo o nějakou jednoduchou věc na kterou se pak neplánovaně začaly nabalovat featury (BTW ty zdrojáky net-tools i s patchy jsou taky lahůdka).

[mimi.vx]

Z PC na androida ... DNLA ... např LG má apku SMARTSHARE ktera umí jak server  tak renderer ...