2004-11-01 13:43
by Vasil KolevИ сега за живото и мъртво видео…
Първо, техниката:
Камера с firewire (IEEE1394) изход (не помня точния модел);
Лаптоп с firewire порт, centrino/1.4GHz, и ethernet платка;
Сървър на сериозен bandwidth (marla);
Канал между laptop-а и сървъра с достатъчно bandwidth (сбора от потоците + ~25%), за да може да наваксва на предаването, грешките по линията и burst-овете след тях.
Защо firewire? Понеже може да извади много по-добро качество, и не товари процесора (което не може да се каже за v4l), и подкарването му е по-проста задача.
Софтуер:
dvgrab от Debian с един patch от моя страна, за да не пише по диска;
ffmpeg и ffserver, версия 0.4.8 (новите са много омазани), съответно за кодиране и за разпръскване, с patch, който да реши един проблем при пращането през мрежата (описан ето тук);
wget за архивиране;
Общ принцип на работа – ffmpeg изпраща няколкото (в нашия случай три) различни потока (в нашия случай два видео и един аудио) до сървъра, който си ги сглабя, и дава на различните клиенти при заявка.
Ситуация:
Laptop-а се намираше до камерата, и приемаше от нея видеото, кодираше го в няколко потока, и го пращаше до сървъра, откъдето хората го гледаха. От същия сървър с wget се теглеше текущия поток, с архивна цел (правеше се до zadnik.org, за да намаля малко натоварването по диска на marla, Велин, благодаря :) ).
Конфигурация, команди и т.н.:
Понеже dvgrab има собствено мнение по бая въпроси, трябваше да създадем един named pipe (FIFO) с командата
mknod p av.dv
, и да го пускаме по следния начин:
dvgrab --format raw --frames 0 --buffers 1500 --size 0 > av.dv
Опциите накратко значат raw формат (т.е. никакво прекодиране от негова страна), frames значи на колко кадъра да започва нов файл (т.е. да пише само в stdout), size е подобна опция, но в мегабайти, а buffers е колко кадъра да буферира – 1500 отговаря на ~62 секунди, което успя да се справи с доста ситуации.
От dvgrab видеото отиваше във ffmpeg, чрез следната команда:
ffmpeg -i av.dv http://marla.ludost.net:8090/feed1.ffm
Фактически нищо сложно, параметрите на потоците се определяха от конфигурацията на ffserver-а.
(не съм сигурен защо имаше проблем да направим dvgrab … | ffmpeg …, но все пак имаше, и за това използвахме named pipe)
На сървъра стоеше ffserver, чиято конфигурация може да се види на https://vasil.ludost.net/ffserver.conf. ffmpeg използва опциите вътре, за да определи какви потоци да изпраща. По самата конфигурация няма нищо специално, само трябва да се направи по такъв начин, че да се минимизира броя на потоците (например и трите използват един и същи audio поток, mp3/mono/64kbps). Препоръчвам да се пуска с по-голям приоритет, ако машината е натоварена. Също така тази настройка не работи за гледане на видеото от windows с windows media player, трябва да се пусне ASF поток.
Специфични моменти:
Тествайте всичко ден-два преди да пуснете реалното предаване (проблемите се усещат твърде лесно от потребителите, за разлика от други услуги).
Убедете се, че линията, използвана за излъчване, е достатъчно добра (и поддържайте връзка с хората, които отговарят за нея).
Убедете се, че процесорът на машината, която кодира, може да понесе натоварването и му изключете всичкия power saving.
Преконфигурирането на streaming сървъра по средата на живо предаване значи кратко прекъсване на предаването (сървъра няма reload, само restart).
Възможно е да се използва ffmpeg да чете директно от firewire, ако камерата се поддържа от ядрото (което не беше случая с нашата, и за това използвахме dvgrab (мисля, че не са много поддържаните)). Проблем ще е липсата на буфер в ffmpeg, ще има проблем с избягването на проблеми в линията.
Неща за правене в бъдеще:
Локално копие на чистия материал (сега не успяхме, понеже нямахме достатъчно дисково пространство).
Добре направен filler, който да се показва докато няма живо предаване.
Моментално достъпен архив.
Възможност за предаване по RTSP (може би чрез darwin streaming server?).
По-добър encoder, може би базиран на codec-ите на MPlayer.
ASF поток, за да може да се гледа от windows машини (с WMP).
Инструментариум за тест на поддържана за дълъг период постоянна пропусквателна способност на връзка.
Репликация на streaming сървъра, ако надминем 70 mbps трафик.