татко Крокодил

Today was a normal day – I wrote some stuff for the network security course, read my mail, and found out how absent minded I’ve been, because I kept on wondering why doesn’t gaim put its icon in the taskbar, and it turns out that I haven’t started icewmtray. I finally asked google, and it answered my stupid question.

IBB followed, which was pretty interesting – Chorbadzhiyski brought his new laptop, and got away without it being stolen (wonderful machine, my hands were itching). Then there was a conversation with Kalin Nakov from Sciant, who’s working on the idea for something like a Bulgarian SourceForge (you can see the current status at sciforge.org). It could be something good, we’ll see FSA’s opinion on it.

The beering finished after a serious lecture by Kavlakov on the Bulgarian history. I’ll look into the sources, that he mentioned…

Soon marla will be 2 years old, I’m trying to remember when we put it in Lirex with Boyan (isn’t it written somewhere?)…
Damn. I checked – it was bought at 5th of June 2002, and the oldest file there is from 6th of June 2002. So officially the second date is the birthday, so it’s two years and some months old.
(Doesn’t matter, we’ll celebrate it next year :) )
I think that I’ll do lecture on marla, how is such project done and how to support it – it should be interesting for a lot of people.

And now I’ll go to sleep, because tomorrow will be a busy day – some stuff at the project, lecture on network security, and some other things that I’ll probably remember then…

Днес в общи линии деня си беше нормален – писах малко неща за мрежовата сигурност, четох си пощата, и открих колко загубен съм бил, защото се чудех защо gaim-а не се скрива долу в taskbar-а, а аз не съм бил пуснал icewmtray. Добре, че най-накрая се сетих да проверя защо става така, и питах google.

Последва IBB, което беше доста интересно – Чорбаджийски си домъкна новия laptop, и му се размина отмъкването (страхотна машинка, направо ме сърбяха ръцете). След това имахме един разговор с Калин Наков от Sciant, който работи в/у идеята за портал в България, който е подобен на SourceForge (за момента може да се види на sciforge.org). В крайна сметка може да се получи нещо хубаво, да видим какво ще каже и ССС.

Пиенето на бира приключи след сериозна лекция от страна на Кавлаков на тема история на България. В крайна сметка мисля да намеря източниците, за които той говореше, и да почета малко…

Скоро marla ще навърши 2 години, опитвам се да си спомня кога я сложихме в Lirex с Боян (дали не пише някъде?)….
А, по дяволите. Проверих – купена е на 5 юни 2002, и най-стария файл там е от 6 юни 2002. Така че официално мога да кажа втората дата за рожден ден, и да кажа, че вече е на 2 години и малко.
(Нищо, догодина ще се отпразнува :) )
Смятам някоя от следващите ми лекции да е на темата ‘marla’, и изобщо как се прави и поддържа един такъв проект – предполагам, ще е интересно за много хора.

А сега мисля да поспя, че утре имам тежък ден – няколко неща в проекта, лекция по мрежова сигурност, и няколко други работи, за които ще си спомня в движение…

The lecture was good – I didn’t get tangled in something, some things I explained multiple times, and the students were asking some really good questions – there was contact, and (looks like :) ) they understood what was I talking about. I almost forgot to talk about Syn Flood, but desync reminded me. I also promised to upload something at the site, a student mentioned it, but I can’t remember what was it…
The gestures that I make while giving the lecture don’t go very well with recently dislocated arm.
(I thought I should mention one detail from my personal life, that I thought will obstruct the lecture, but it in fact helped. But it’s too personal :) )

We finished the evening in “Toronto”, again it the dark beer season :) Really nice to drink, but gets me easily …
We discussed the course papers, they should be ready (please, god (of servers) until the end of the week.

In fact, it’s good that the bolt that the small boxing bag was hanging on today got ripped – I’ll rest until next week, and my arm will heal (but enough about it, even I got weary).

Лекцията се получи добре – не направих някое сериозно забъркване, някои неща обяснявах по няколко пъти, и хората задаваха много хубави въпроси – получи се контакт, а и хората (изглежда :) ) разбраха за какво им говоря. Накрая за малко да изтърва SYN Flood-а, но desync ми го напомни. Щях и да качвам нещо на сайта, някой от студентите го спомена и обещах, ама като не помня какво беше…
Многото жестове, които правя по време на лекцията не се комбинират добре с прясно вадена ръка.
(тук мислех да спомена една подробност от личния живот, която мислех, че ще попречи за лекцията, ама всъщност помогна. Но е лична, така че без нея:) )

Довършихме вечерта в “Торонто”, пак е сезона на тъмната бира :) Много приятна за пиене, ама що ли така ме хваща…
Обсъдихме и темите, дето ще даваме на студентите, до края на седмицата (дай боже(на сървърите)) ще са готови.

Всъщност добре стана, че се изкърти днес винта, на който ми беше малката круша – до следващата седмица ще си почина, и ще ми мине ръката (но стига за нея, чак на мен ми писна).

I have no idea how many times I have to dislocate my shoulder, to get used to the pain. Well, at least I got used to the relocating.

Last night I fell asleep early, around 21-22, and in the morning woke up almost with Velin (who was really surprised). In the last few days I mostly read books and relax, but now I’ll be working on the plan for today’s lecture, so it won’t be like the last one.

Не знам колко пъти трябва да си извадя рамото, че да свикна с болката. Добре поне, че свикнах с наместването.

Снощи заспах рано, някъде около 21-22, и сутринта станах в общи линии заедно с Велин (който бая се изненада). В последните няколко дни основно чета книги и си почивам, сега обаче сядам да си работя по плана за днешната лекция, да не стане като миналия път.

Some people are nostalgic about the past, never mind that this protocol was used when they were still using BBSes.

gopher://ftp.uni-sofia.bg/

Sick people, sick… What’s next – Veronica, Arhchie, WAIS ?

Някои хора ги гони носталгия по миналото, нищо, че като тоя протокол се е използвал, те още са висяли по BBS-и.

gopher://ftp.uni-sofia.bg/

Болни хораааааа, болни… Какво следва – Veronica, Archie, WAIS?

And now about the live and dead video…

First, equipment:
A camera with firewire (IEEE1394) output (I can’t remember the exact model);
Laptop with firewire port, centrino/1.4GHz, and ethernet port;
Server that has a good connectivity (marla);
A pipe from the laptop to the server with enough bandwidth (the sum of the streams + ~25%), to be able to catch up with the transmission, the errors and the bursts that follow.

Why firewire? Because it has better quality, and doesn’t use too much CPU (which can’t be said about v4l), and it’s usage is easier.

Software:

dvgrab from Debian with one patch by me, to make it not to write to the disk;
ffmpeg and ffserver, version 0.4.8 (the newer ones suck), for the encoding and broadcasting, with a small patch, that solves a problem when sending over the network (described here);
wget for archiving;

Principle of work – ffpmeg sends a few (in our case three) different streams (in our case two video and one audio) to the server which assembles them, and sends them to the different clients on request.

The situation:

The laptop stayed next to the camera, and was receiving the raw video, encoding it in some streams, and sending it to the server, where people were watching it. From the same server with wget there was a download of the current stream for archival (it was done to zadnik.org, to lower a bit the load on marla’s drive, thanks, Velin :) ).

Configuration, commands, etc :

Because dvgrab has its own opinion on a lot of questions, we created a named pipe (FIFO) with the command

mknod p av.dv

, and ran it in the following way:

dvgrab --format raw --frames 0 --buffers 1500 --size 0 > av.dv

The options in short mean rew format (e.g. no reencoding by it), frames means at how many frames to start writing a new file (e.g. to write only to stdout), size is a similar option, but in megabytes, and buffers is how many frames to buffer – 1500 is ~62 secs, which worked in most situations.
From dvgrab the raw stream went to ffmpeg, through the following command:

ffmpeg -i av.dv http://marla.ludost.net:8090/feed1.ffm

Nothing complex, it was taking the parameters of the streams from the configuration of ffserver.
(I’m not really sure what was the exact problem for doing dvgrab … | ffmpeg …, but there was, so we used named pipe)

On the server there was a ffserver running, which’s configuration cane seen at https://vasil.ludost.net/ffserver.conf. ffmpeg used the options inside, to know what streams to send. There isn’t anything special inside, only you should write it in a way that minimizes the number of streams (for example, all three streams use the same audio stream, mp3/mono/64kbps). I recommend running it with a higher priority, if the machine is loaded. Also this configuration doesn’t work if you want to view the video from windows with WMP, you’ll need an ASF stream.

Specific notes:

Test everything one-two days before making the real live broadcast (the problems are easily discovered by the users, not like the other services).
Make sure that the pipe used for sending the master stream is good enough (and keep in touch with the people that are responsible for it).
Make sure that the processor of the machine that does the encoding can withstand the load, and turn off all of its power saving.
The reconfiguration of the streaming server in the middle of the live feed means a short interruption of the broadcast (the server doesn’t have a reload, only restart).
It’s possible to use ffmpeg to read directly from firewire, if the camera is supported from the kernel (which wasn’t our case, so we used dvgrab (I don’t think that there are a lot of supported ones)). A problem will be the lack of buffer in ffmpeg, there will be a problem with the errors in the link.

Things for the future:

A local copy of the raw material (we weren’t able to make one this time, because of the lack of disk space).
A nicely made filler, which to be shown when there isn’t a live feed.
Momentarily accessible archive.
A way to transmit/broadcast over RTSP (may be through darwin streaming server?).
A better encoder, maybe based on MPlayer.
ASF stream, to be viewable from windows (WMP) machines.
Instruments for testing of the link, if if can sustain a given bandwidth for a long period.
Replication of the streaming server, if we make more than 70mbps traffic.

И сега за живото и мъртво видео…

Първо, техниката:
Камера с 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 трафик.