View source for Как правя streaming-а и записите

Първия път, когато писах [http://vasil.ludost.net/blog/?p=666 подобно нещо], беше преди 8 години, от тогава много неща се промениха.


== Хардуер ==

=== Видео източник (камера) ===

По принцип използвам видео камера с firewire изход. Предимствата са, че е сравнително стандартно, има поддръжка в linux, windows и какво ли не още, работи стабилно (т.е. използва се) и може да вкарва лесно и звука и картината в синхронизиран файл. Първо ползвах една Sony DCR-TRV33E (720x576), сега ползваме Cannon Legria HV40, която може да прави 1080p (FullHD) записи. Двете камери вадят еднакви по размер файлове, като втората използва mpeg2/aac като кодеци.

* Legria-та по принцип има автоматичен gain control на входа за звук, който трябва да се спре и нивото на микрофона да се настрои на ръка, понеже иначе усилва всякакви минимални шумове.

Може да се използва и нормална usb камера през v4l2 интерфейса (или каквото-е-там под windows), отбелязал съм по-долу къде би трябвало да има разлики.

Камерата има нужда от статив или някакъв друг начин, по който да се стабилизира.

=== Encoder/streamer ===

Един добър лаптоп с интерфейс към камерата (ако не е firewire, и към звука), който да може да смята достатъчно бързо video/audio codec-ите (за streaming) и диск, на който да може да прави записите (за записа). "Некомпресираното" видео от DV/HDV камера, което идва по firewire е около 24mbps, съответно час и половина са 19GB (целият запис от VarnaConf например беше 100GB, един ден и около 8-9 часа). Също така за stream-ване силно препоръчвам да се ползва жичен ethernet, вместо wireless, поради буферните проблеми, които wireless-а може да направи.

=== Звук ===


==== Микрофони ====

По принцип за конференциите са нужни два типа микрофони - "брошки" (такива, които се закачат на лектора) и "нормални", които или да стоят стационарно, или да са безжични и да се разнасят из публиката. Аз лично препоръчвам всички да са безжични, понеже се спестяват много кабелни проблеми. От друга страна, при безжичните микрофони трябва да се внимава какви канали се използват и да не се получи колизия с друго такова оборудване наблизо.
(историята познава доста такива случаи, например как на openfest 2011 единия ден се чуваше нещо от събирането на някаква църква наблизо)

Поне част от местата, в които които се провеждат разни събития имат някакво количество такова оборудване.

Аз използвам един AKG WMS 40 FLEXX за брошка и HED Audio WMS-35DUAL за преносими микрофони.

==== Пулт/миксер ====

Всичкият звук има нужда да се събере на едно място, за да се изпрати към камерата и към озвучаването на залата. В общи линии всякакъв миксер с нужния брой входове, изходи и възможности за настройка върши работа (аз се справям с един Behringer Xenyx 802). Често се случва мястото, на което е събитието да има подобен пулт, към който са закачени техните audio неща.

==== Озвучаване ====

По принцип за да може да се чува добре какво се говори е добра идея това, което лекторите и т.н. казват да се усилва и чува от допълнителни източници. Почти всичко, което има усилвател и колони може да свърши тая работа, като повечето зали имат нещо подобно. В случаите, в които нямат съм открил, че кубе от бас (моето Fender Bass Rumble 15) вади добър звук като за човешки глас и има достатъчна мощност да озвучи зала за 100-200 човека (зала 200 на ФМИ на СУ). По същия начин сме използвали усилвател и две колони в ТУ-София за курса по linux (нямам спомен какви точно бяха, мисля, че се водеха 50-100W). Тестове може да се провеждат лесно и да се види колко добре се получава звукът.
(не препоръчвам да се ползват китарни кубета, понеже при тях кривенето на звука е feature)

==== Източник на звук, музика за паузите ====

Полезно е да има някакъв източник на звук, от който да се пуска (тихо) музика в паузите. Най-лесно става с лаптоп, но и телефон (който няма да звънне) или mp3 player биха свършили работа.

Музиката, която се пуска трябва да е под свободен лиценз или поне да имате по някакъв начин право да я пускате (за да не си създадете безсмислени проблеми за в бъдеще). Мога да дам няколко варианта:
* Първите три албума на Falik, които са под creative commons.
* Скоро записаното dvd на MusOpen: [http://archive.org/details/musopen-lossless-dvd]
* Колекцията записи на wikipedia (изпълненията не са от най-добрите): [https://en.wikipedia.org/wiki/Wikipedia:Sound/list]
* Creative commons поддържат списък сайтове, който могат да се погледнат: [https://creativecommons.org/music-communities]

=== Разни ===

* Всички нужни кабели и малко резервни
* Разклонители (и поне един с прекъсната маса)
* Мултицет (понякога трябва)
* Тиксо
* Слушалки
** Много са важни при тестването и наблюдаването на системата, понеже наоколо почти винаги ще е шумно
* Резервни батерии за всичко, което иска батерии
** например всички безжични микрофони
* Стойки за микрофони (ако са нужни и няма на място)

== Софтуер ==

Софтуерният процес изглежда по следният начин:

* dvgrab взима записа от камерата и го подава на ttee;
* ttee го пише в един named pipe (към vlc) и в един файл (за запис);
* vlc го чете от named pipe-а, encode-ва го и го праща до restreamer сървъра;
* restreamer сървъра поема потока пак с vlc и го дава на всеки, който си иска по http.

Възможно е да се каже на vlc да прави запис на потока (още при encoder-а), което вероятно и ще е вариантът, ако не ползваме firewire камера, dvgrab и ttee, но по принцип stream-вания поток трудно може да е с толкова добро качество, колкото записите.

За комуникация м/у encoder-а и restreamer-а използвам UDP протокола на vlc. Това създава малко security проблеми (т.е. някой друг може да бълва данни и да ми се меси в оригиналния поток, ако налучка няколко неща) и планирам да направя нещо по въпроса (RTP или подобен протокол, в краен случай VPN).

Решението ми е ограничено до един restreamer и съответно броят възможни клиенти е ограничен от неговата свързаност. Аз досега не съм минал 1gbps, в момента, в който това се случи и измисля решение, ще го добавя.

Подробности за streaming-а с vlc могат да се намерят на [[http://www.videolan.org/doc/streaming-howto/en/]].

=== Сървър ===

Използвам vlc за restreamer, командата изглежда по следния начин:

 <nowiki>
/usr/bin/vlc -I dummy --udp-caching 16000 udp://:UDPPORT --sout '#standard{access=http,{dst=:HTTPPORT/lab.ts}}'
</nowiki>

Където:
* 16000 е 16 секунди буфер на получения по udp поток. Много много добра идея, иначе клиентите се шашкат, като трябва да чакат да се съберат данни, а така директно получават 16 секунди и могат веднага да започнат да показват нещо.
* UDPPORT е UDP порта, на който слушаме за входящия поток. Може да слушаме и на определен ip адрес.
* HTTPPORT е порта, на който слушаме за клиентски връзки.
* /lab.ts е url-то, което клиентите трябва да заявят.
** По принцип използвам MPEG-PS за контейнер на данните, за да мога да stream-вам и да да не реенкапсулирам накрая. Ако искаме да може да се гледа stream-а през някакъв (мизерен) flash, можем в сървъра да пипнем данните и да ги обърнем в mp4 контейнер.

Понеже не ми се занимаваше да пиша странния команден ред на vlc за слушане на специален адрес, на v4 и на v6, използвам socat за да пренасочвам към този порт нормалния порт 80:

 <nowiki>
socat -d -d -lmlocal2 TCP4-LISTEN:80,bind=62.44.127.178,su=nobody,fork,reuseaddr TCP4:62.44.127.178:8787,bind=62.44.127.178
socat -d -d -lmlocal2 'TCP6-LISTEN:80,bind=[2001:67c:20d0:b0::3],su=nobody,fork,reuseaddr' TCP4:62.44.127.178:8787,bind=62.44.127.178
</nowiki>

(не съм изтрил оригиналните адреси, но мисля, че лесно ще се ориентирате)

При мен streamer-а има едно име, което сочи и към ipv4 и към ipv6 адреса. Поради калпавостта на голяма част от ipv6 свързаността, бих препоръчал (и вероятно и аз ще го направя) да има още две отделни имена, само по v6 и само по v4, за удобство на клиентите и по-лесно debug-ване.

=== encoder/streamer ===

Това е малко по-криво. 

Използвам за codec-и h264 за видео и aac за аудио. Може дълго да се спори колко е лошо или колко е хубаво, моите причини са следните:
* h264 е най-новия и добре разработен codec.
* поддържа се от почти всичко (вкл. телефони).
* може да кодира добре голямо видео (720p) на 2mbps и дори на 1mbps.
* има свястна и много добре разработена реализация (x264) на encoder.

Понеже имах проблеми с оригиналната версия си компилирах наново x264 и vlc. Версията на x264 е x264-snapshot-20120710-2245 и е компилиран само с --enable-pic, версията на vlc е 2.0.2 и няма някакви специални опции. Направил съм си един отделен chroot, за да не пречи на системата и при заявка мога да го кача някъде и други хора да го ползват.

Поради липса на подходящ инструмент си написах сам [http://vasil.ludost.net/blog/?p=2961 ttee].

dvgrab е стандартен инструмент и трябва да го има във всички дистрибуции.

=== processing ===

Записите обработвам с ffmpeg и малко скриптове. Имам компилиран x264 само с 
 <nowiki>
./configure --enable-pic  --use-ffmpeg=no
</nowiki>
и ffmpeg, взет от git repo-то им на 14ти август 2012, компилиран с
 <nowiki>
./configure --enable-gpl  --enable-libx264 --enable-pic --enable-pthreads --enable-libfaac --enable-nonfree --enable-avfilter --enable-postproc --enable-shared
</nowiki>

Имам скрипт за нарязване на файл, който работи с два файла - списък от начална и крайна секунда на всяко парче, и видео файл. Скриптът се казва split.sh и изглежда по следния начин:
 <nowiki>
#!/bin/bash

if [ -z "$2" ]; then
        echo Usage: $0 tsfile avifile
        exit 3
fi

n=0
input="$2"

(while read beg end; do 
        let n=$n+1
        let sz=$end-$beg

        name=$input.$n.split.avi
        echo ffmpeg -analyzeduration 50000000 -v verbose -y -i "$input" -acodec copy -ss $beg -t $sz -threads 6 -vcodec copy $name

done) < $1
</nowiki>

За encode-ване ползвам следният скрипт:
 <nowiki>
#!/bin/sh

if [ -z "$4" ]; then
        echo Usage: $0 input output resolution rate
        exit 2
fi
set -x
set -e

#output
name="$2"
#output file bitrate
rate="$4"
#output file resolution
res="$3"
#input file name
input="$1"

rm -f "$name" x264_2pass.log*

ffmpeg -analyzeduration 50000000 -v verbose -y -i "$input" -ss 42 -an -pass 1 -acodec libfaac  -ar 48000 -ab 128 -threads 6 \
-vcodec libx264 -s $res -b $rate -qmin 10 -qmax 51 -qdiff 4 -filter:v yadif $name

ffmpeg -analyzeduration 50000000 -v verbose -y -i "$input" -ss 42 -pass 2 -acodec libfaac  -ar 48000 -ab 128k -threads 6 \
-vcodec libx264 -s $res -b $rate  -qmin 10 -qmax 51 -qdiff 4 -filter:v yadif $name

exit 0

</nowiki>

== Процес ==

=== инсталация/закачане ===

Това е твърде зависимо от залата, така че просто ще дам базовите идеи:

* Камерата се поставя така, че да вижда спокойно лектора и презентацията му, и доколкото е възможно без да хваща публиката.
* Пултът и "майките" на безжичните микрофони се поставят на място, което е най-удобно за окабеляването на залата.
** Колкото по-малко кабели газят хората, толкова по-добре.
* Звукът от пулта се извежда до озвучаването на залата и до камерата (по възможност).
** Възможно е да се кара на микрофонът на камерата, който да записва звука, който се чува в залата, но резултатите не са особено добри - шум от климатици и т.н. (който може да се филтрира), има шум от публиката (който е почти невъзможен за филтриране), разни ехота в залата се усещат, като цяло е неприятно.
** Не винаги може да се пусне кабел от пулта до камерата, за което планирам да взема нещо като Amphony L1500, което да пренася лесно звука.
* Правят се тестове да се види доколко се получава микрофония от лекторите, къде трябва да стоят и колко да бъдат усилени
* Правят се същите тестове за говоренето от публиката при задаване на въпроси (освен ако не се прави със стационарни микрофони на няколко места в залата).
* Прави се тест с камерата и колко добре се чува звука

* !!! Много често срещан проблем е да има шум от около 50hz, силен и дразнещ, който да изчезне, когато например захранването на лаптопа, който е закачен към камерата, се изключи. Това се решава чрез ground lift, който най-лесно се реализира като се залепи тиксо на масата на разклонителя.
** Понеже аз нищо не разбирам от ток, препоръчвам да не ме слушате и да имате с вас един човек, който да знае какво да прави в такива ситуации.

* Encoder/streamer-а (т.е. лаптопа) се закача към камерата и към мрежата.
** съответно encoder-а трябва да стои до камерата.
** мрежата се тества за загуби и bandwidth.
** добре е да има някакъв вариант да се погледне от друга машина как върви излъчването.


=== опериране ===

* При повече от един лектор за всеки се налага да се види колко силно говори и да се намали/усили микрофона му съответно.
** Обмислям да направя скала за оценка на силата на гласа на лектора, която започва от Радослав Борисов и Борис Филипов, минава през Стефан Кънев и свършва със Светлин Наков и Атанас Бъчваров.

* Добре е да се наблюдава stream-а и да се преслушват/преглеждат части от записите, за да се следи качеството.
** По принцип хората, които ще гледат събитието през stream-а се оплакват на разни места, намерете начин да ги следите. Например на varnaconf няколко човека ми предаваха какво се казва в twitter.

* Микрофоните "брошка" е добре да се слагат колкото се може по-високо (под брадата на лектора), така че да няма шум от силно вдишване/издишване
** особено ако пак изгубим ветробрана на микрофона

==== пускане на stream-а ====

Предварително съм изпълнил

 <nowiki>
mknod av.m2t p
</nowiki>

По принцип използвам два терминала. В единия пускам:

 <nowiki>
dvgrab --format raw - | ./ttee av.m2t log.`date +%H%M`.dv
</nowiki>

а в другия stream.sh, в който има
 <nowiki>
cvlc av.m2t --sout='#transcode{vcodec=h264,vb=2000,scale=0.6,acodec=mp4a,ab=128,channels=2,2amplerate=48000,threads=2,deinterlace}:std{access=udp{ttl=32},mux=ts,dst=RESTREAMER:UDPPORT}' --sout-keep --sout-x264-profile baseline --no-sout-x264-non-deterministic --sout-x264-preset ultrafast -v 1
</nowiki>

* RESTREAMER и UDPPORT трябва да си ги попълните
* vb=2000 значи 2mbps stream, което се оказва добре на задачата
* scale=0.6 прави от 1920x1080 (1080p) 1280x720 (720p)
* сложил съм deinterlace, понеже оригинално това, което идва от камерата е interlaced и се получава грозно
* ttl=32 е задължително, default-а е 1, което никаква работа не върши
* --sout-x264-preset ultrafast е нужно, за да може моя лаптоп (който е core i7) да се справи със сметката


Ако не се прави streaming, само за запис командата е
 <nowiki>
dvgrab --format raw --size 0
</nowiki>
която ще създаде един голям файл, който вече може да се обработва. Без --size 0 ще направи отделни файлове по 1GB, който после първо ще трябва да се лепят, после да се режат, което не е особено удобно.

* В някои случаи изглежда по-удобно да се направят отделни файлове по 1GB (които са по около 5 минути) и после да се налепят, но съм имал различни проблеми със софтуера, който прави слепването (най-вече разсинхронизация на звука) и за това не го препоръчвам.

==== Работа с камерата ====

По принцип в записите, които правим няма движение на камерата - настройва се веднъж в началото и само се гледа да не се е разместила. По принцип препоръчвам ако все пак някой има желание за операторско майсторство, да минимизира местенето и да е колкото се може по-плавно и малко, за да не се объркват зрителите.
* особено неприятно е ако се следи някой лектор, който има навика да ходи постоянно от единия до другия край на сцената и на моменти трябва да се фокусира на slide-овете му.
** историята познава хора, от които е имало оплаквания че от ходенето им напред-назад зрителите хващали морска болест

=== събиране/съхранение ===

Има много сайтове, които обясняват как се съхранява техника, как правилно се навиват кабели и т.н. - неща, които не съм чел и въпреки многото обясняване вероятно не съм схванал правилно. Базовите ми правила са:

* Кабелите трябва да са навити и вързани така, че да не се оплитат.
* Техниката трябва да може да преживее сътресения на кашона или каквото-там-се-ползва, в което се носи.
* Трябва да има в какво да се носи техниката, а не всеки компонент да се мъкне отделно.
* Много добра идея е да има списък на техниката, по който да се провери какво е забравено.
** Моята е достатъчно малко за да си мисля, че мога да помня всичко.

== Обработка ==

(Това е как аз правя нещата, а аз съм пословично мързелив. Вероятно може да се направят повече и по-хубави неща)

Първото действие е да се изгледа записа и да се отбележи от къде до къде трябва да се изреже. Форматът, който приема script-а е многоредов файл с по две числа на ред - начална и крайна секунда на парчето. Секундите са абсолютни спрямо началото на файла (с файловете, генерирани от dvgrab по принцип показвания timestamp е от моментът на пускане на камерата, не от началото на файла и трябва да се види с колко секунди трябва да се коригира). Примерен файл изглежда така:
 <nowiki>
1146 1265
1265 3002
3858 5763
6943 9713
10228 13598
13598 13692
</nowiki>

След това се пуска split.sh, който да нареже файла (което отнема някакво време). В момента скриптът има проблем с return code и изяждане на stdin, поради това генерирам команди (с echo), които после да се пуснат. Пример:

 <nowiki>
vasil@lain:/home2/encoder/home/vasil/varnaconf$ bash split.sh split.1022 log.1022.dv
ffmpeg -analyzeduration 50000000 -v verbose -y -i log.1022.dv -acodec copy -ss 670 -t 1890 -threads 6 -vcodec copy log.1022.dv.1.split.avi
ffmpeg -analyzeduration 50000000 -v verbose -y -i log.1022.dv -acodec copy -ss 3306 -t 1999 -threads 6 -vcodec copy log.1022.dv.2.split.avi
ffmpeg -analyzeduration 50000000 -v verbose -y -i log.1022.dv -acodec copy -ss 6010 -t 1860 -threads 6 -vcodec copy log.1022.dv.3.split.avi
ffmpeg -analyzeduration 50000000 -v verbose -y -i log.1022.dv -acodec copy -ss 8864 -t 2684 -threads 6 -vcodec copy log.1022.dv.4.split.avi
ffmpeg -analyzeduration 50000000 -v verbose -y -i log.1022.dv -acodec copy -ss 12525 -t 2375 -threads 6 -vcodec copy log.1022.dv.5.split.avi
ffmpeg -analyzeduration 50000000 -v verbose -y -i log.1022.dv -acodec copy -ss 14900 -t 350 -threads 6 -vcodec copy log.1022.dv.6.split.avi
</nowiki>

След това с fenc.sh може да се encode-нат до нужния формат:
 <nowiki>
bash fenc.sh log.1022.dv.1.split.avi finished_log.1022.dv.1.split.avi 1280x720 2000k
</nowiki>

Ако се наложи да се обработва звука, той първо може да се извади от файла с 
 <nowiki>
ffmpeg -i FILE.avi -vn out.wav
</nowiki>
, след това да се обработи out.wav и да се mux-не обратно с
 <nowiki>
ffmpeg -i tmp2.wav -i INPUT.avi -acodec libfaac -ar 48000 -ab 128k  -vcodec copy OUTPUT.avi -map 0.0 -map 1.0
</nowiki>
(INPUT.avi приемаме, че вече е encode-нато до h264 и няма нужда да му се пипа видеото)

Документация за ffmpeg може да се намери на страницата на проекта, и е препоръчително да се прегледа. Проектът е ужасен, но няма заместител.


=== Обработка на звук ===

(това па изобщо не го разбирам)

Използвам audacity, за да махна шума, да нормализирам/усиля звука, ако е нужно, и да го направя същия на двата канала (ако по някаква причина записът е само на единия канал, което се случва, ако например не ползвам миксер, а микрофон директно в камерата).

* Махането на шума става просто - намира се отрязък от време (кратък), който е само шум, select-ва се, дава се на noise removal-а да профилира, след което се select-ва целия звук (или там, откъдето искаме да изчистим шума) и му се дава noise removal.
* Останалото става още по-лесно с малко четене в google.

== Няколко setup-а ==

Това са няколко различни setup-а, които съм правил:

=== initlab ===

В initlab изходът на звука е свързан към озвучаването на голямата стая, а сървърчето там (cassie.ludost.net) е закачено към миксера, съответно може да се пуска музика в паузите и може да се чува добре в стаята. Камерата стои отзад (до библиотеката) заедно с цялата техника, и има в общи линии нужда само от микрофон за лектора и понякога някой от другите преносими за задаване на въпроси. Звукът се получаваше сравнително добре и като се записваше директно от микрофона на камерата.

=== varnaconf ===

В залата имаше една JBL колона, която по принцип беше директно вързана към микрофона на катедрата. Свързахме и двете към пулта, след което в пулта включихме и нашите микрофони. Камерата се намираше отзад и записваше с нейния микрофон, което доведе до много шум и проблемен звук, който после едвам докарахме до поносимо ниво. Мрежовата свързаност излизаше точно при камерата и беше независима от публичния wireless там, та с това нямаше проблем.

== Малко история ==