DevImpress

Обработчик сообщений на JavaScript при участии jQuery

Максим Крентовский — Mon, 16 Aug 2010 10:51:08 +0000

Представим себе web-приложение, которое взаимодействует с серверной частью посредством сообщений в формате JSON. Ответные сообщения, так же в виде кортежей, обернутых в JSON, передаются на сторону клиента, где декодируются и, в зависимости от содержимого, происходит то или иное действие.

В возвращаемом со стороны сервера кортеже (точнее, списке кортежей, но это на данный момент не играет роли) присутствует идентификатор события в виде поля action. Самый простой и незатейливый способ написать обработчик сообщений при помощи switch/case:

1
2
3
4
5
6
7
8
9
10

$.vico.dispatchMessage = function(p) {
var res = true;
switch(p.action) {
case('noauth') : {
...
break;
}
}
return res;
}

Разумеется, этот способ хоть и наглядный, но не самый приятный для чтения, поскольку предполагает простыню кода в случае наличия более 10 типов сообщений. Поэтому я запросил совета в твиттере, а пока реализовал более простую схему при помощи eval.

1
2
3
4
5
6
7
8

$.vico.dispatchMessage = function(p) {
var re = new RegExp('^[a-z0-9]+$', "g");

if(re.test(p.action)) {
eval("var fn = $.vico.cb_" + p.action + ";");
if(fn) return fn(p); else return false;
} else return false;
}

В этом случае для написания обработчика нового события потребуется только добавление новой, специально именованной функции. Поскольку eval потенциально ненадежное средство, кодификатор сообщения проверяется при помощи регулярного выражения (никому веры нет).

Тут в твиттере опытные товарищи напомнили про вариант с массивом, когда обработчик берется из таблички соответствия:

1
2
3
4

var m_cb = new Array();
m_cb["noauth"] = $.vico.cbNoAuth;

if(m_cb[p.action]) m_cb[p.action](p);

Этот вариант не использует потенциально опасный eval, однако требует, чтобы в процессе написания кода обработчика изменения производились в двух точках – в массиве и в самой декларации функции.
Чтобы еще больше усложнить эту процедуру, было решено написать небольшой «класс», позволяющий добавлять/убирать из массива произвольное количество обработчиков события, что позволяет в дальнейшем расширять систему не только вглубь, но и в ширь.

Код выглядит примерно следующим образом:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

Использовать его тоже несложно:

1
2
3
4
5
6
7
8
9
10
11

$.AEvents();

$.AEvents.bind("noauth", $.vico.noAuth);
$.AEvents.bind("authok", $.vico.authPassed);

$.vico.dispatchMessage = function(p) {
var r = $.AEvents.pass(p.action, p);

if(r && r.length > 0) return true;
else return false;
}

Разумеется, следующий шаг – привнесение в этот класс функционала обмена сообщениями с сервером. В итоге получается что-то (не побоюсь громкого слова) отдаленно напоминающее gen_server в Erlang.

Система обмена файлами

Максим Крентовский — Wed, 07 Jul 2010 14:40:15 +0000

После длительного перерыва и работы над своими проектами постараюсь возобновить написание статей в этот блог. Начну, пожалуй, с небольшого, но простого проекта, сделанного специально для Центра новых медицинских технологий.

Порой необходимо передавать файлы большого объема, для чего применение почты может быть не совсем удобным вследствие многих ограничений на размер письма и общую емкость ящика. Именно для решения этой задачи была реализована система обмена файлами. Каждый участник обмена, получив свой индивидуальный логин и пароль, может заливать на сервер файлы. Каждый файл помещается в отдельную папку, которые доступны для общего обзора администратору системы. Так же пользователи могут удалять файлы, которые уже не нужны.

Ничего сложного, но в целом имеет право на существование.

Как сделать свой онлайн-кинотеатр с пользователями и приглашениями

Максим Крентовский — Fri, 12 Mar 2010 16:23:53 +0000

Поскольку HDin.TV как онлайн-кинотеатр популярных сериалов в 720p-разрешении прекращает свою деятельность 1 апреля 2010 года, поделюсь рецептом создания подобных ресурсов (как и обещал в заключительном обращении). На самом деле все это фрагментами уже освещалось в данном блоге, поэтому постараюсь выстроить приведенные знания в единую цепочку, при этом попробую описать проект, как если бы его делал с нуля.

Итак, начнем, пожалуй, с мира материального.

Для работы нам потребуется как минимум один сервер (для размещения контента) и одна рабочая станция (для перекодирования видео). При этом сервер для вещания может быть не самый производительный на данный момент – основная его деятельность будет заключаться в том, чтобы быстро отдать видео большому числу пользователей. Замечу, что в данном случае видеофрагменты достаточно большие и кешировать их целиком в оперативной памяти, как бы последняя не была дешева, смысла не имеет. Рабочая станция, наоборот, должна быть максимально производительна (процессоры с количеством ядер меньше четырех рассматривать вряд ли стоит), поскольку при перекодировке процессорные ресурсы очень востребованы.

Примерная конфигурация сервера
Intel 1U SR1530HSH (LGA775, i3200, SVGA, SATA RAID, 3xHotSwap SATA, 2xGbLAN, 4DDR-II, 350W)
CPU Intel Core 2 Duo E8500 3.16 ГГц/ 6Мб/ 1333МГц LGA775
Kingston ValueRAM KVR800D2N5/2G DDR-II DIMM 2Gb PC2-6400 CL5
HDD 160 Gb SATA-II 300 Seagate/Maxtor Barracuda 7200.11/DiamondMax 22 3160813AS 7200rpm 8Mb
2 х HDD 1.5 Tb SATA-II 300 Seagate Barracuda 7200.11 ST31500341AS 7200rpm 32Mb

Стоимость такого набора может составлять примерно 40 000 рублей из расчета розничных цен. Основную погоду делают, конечно же, жесткие диски, места на которых постоянно будет не хватать.
В данной конфигурации предполагалось, что 1.5Тб-е диски будут включены в зеркало посредством software-RAID, а на 160Гб будет располагаться система.

Примерная конфигурация рабочей станции
HDD 1.5 Tb SATA-II 300 Seagate Barracuda 7200.11 ST31500341AS 7200rpm 32Mb
CPU Intel Core i7-920 2.66 ГГц/1+8Мб/4.8 ГТ/с LGA1366
ASUS P6T SE (RTL) LGA1366 X58 3xPCI-E+GbLAN+1394 SATA RAID ATX 6DDR-III
Kingston ValueRAM KVR1066D3N7/2G DDR-III DIMM 2Gb PC3-8500 CL7
1Gb PCI-E DDR-3 ASUS EN9800GT /DI/1GD3 (RTL) +DVI+HDMI+SLI GeForce 9800GT
Miditower ASUS TA9L1-SBB 90-PL9L1AV7T6-53CZ Silver&Black ATX 450W(24+4+6пин)
20″ MONITOR ASUS VH203D BK (LCD, Wide, 1600×900)

Стоимость рабочей станции колеблется так же в районе 40 000 рублей, при этом надо понимать, что приведенные выше конфигурации по большей части условность – можно воспользоваться и более дешевыми вариантами, и продукцией других вендоров и т.п.

Итак, железо есть. Что дальше? Дальше – операционные системы и ПО. В силу множества исторических факторов и наработанного опыта лично я склоняюсь к использованию Debian Linux на сервере и Ubuntu Linux или OpenSUSE на рабочей станции. Разумеется, это ограничение весьма условное и дело личных предпочтений, производственной религиозности и т.п. При этом если планируется использовать сервер для еще каких-либо функций помимо собственно ресурса, рекомендую сразу установить ядро с поддержкой контейнеров OpenVZ. Впрочем, это факультативный аспект, который оставим на самостоятельное изучение.

Теперь смело можно устанавливать сервер в стойку и подключать к магистрали. Все остальные операции на нем можно будет сделать удаленно.

Сразу отмечу следующие нюансы: поток в 2Мбит/с (на который ориентировались при создании HDin.TV) предполагает, что первой точкой потенциальных проблем станет пропускная способность канала, затем – свободное место на жестком диске. Поэтому надо предполагать, что если провайдер предоставляет вам канал на 100 Мбит/с, нормально смотреть видео смогут одновременно не более 40-50 человек, при этом с большой вероятностью пик будет приходится на 18:00-02:00, т.е. вечернее время. Это очень важно сразу обсудить с хостинг-провадером во избежание дальнейших претензий.

Сервер в стойке, на рабочей станции все установлено и настроено. Хорошо, теперь произведем разделение ролей. Сервер будет транслировать видео в сеть. Рабочая станция – перекодировать видео.

Начнем с рабочей станции. Для начала соберем и установим программу для видеоперекодировки ffmpeg и любимый торрент-клиент. С клиентом предлагаю разобраться самостоятельно, а вот про ffmpeg расскажу попробнее. Мое личное убеждение, что и ffmpeg, и x264 (библиотека для сжатия с применением кодека H.264) следует брать из систем контроля версий, собирать вручную и использовать. Причина тому проста – оба проекта весьма динамично развиваются, оперативно добавляются новые функции и устраняются ошибки, поэтому дистрибутивные пакеты, как правило, не успевают за этой динамикой. Впрочем, отрицать правильность пути с установкой пакетов из стандартной поставки так же не буду – как минимум не придется отслеживать зависимости и проверять обновления.

Устанавливаем x264

1
2
3
4
5

git clone git://git.videolan.org/x264.git
cd x264
./configure
make
make install

Устанавливаем ffmpeg (необходимые дополнительные библиотеки лучше взять из стандартной поставки)

1
2
3
4
5

svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
cd ffmpeg
./configure --enable-gpl --enable-nonfree --enable-postproc --enable-pthreads --enable-libdc1394 --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libvorbis --enable-libx264 --enable-libxvid
make
make install

Хорошо, ПО собрали и установили, торрент-клиент есть – можно качать любимые сериалы, перекодировать и выкладывать на сервер? Не все так просто. Во-первых, необходимо понимать, что сериалов много и уследить за выходом серий в каждом из них – сложно. Во-вторых, перекодировать целый сезон, набирая команды руками – непрактично. В-третьих, мы все еще не настроили сервер.

Начнем с отвлеченного. Как следить за выходом серий? Тут есть два очевидных варианта: а) воспользоваться сервисом для отслеживания сериалов; б) написать небольшого робота, который будет самостоятельно отслеживать изменения на страницах трекера и присылать вам уведомление об изменении (можно, конечно, заставить торрент-клиента скачивать по RSS, но мы же настоящие комсомольцы, правда?). Для себя я сделал такого робота на базе Jabber-клиента, уже упоминавшегося в данном блоге.

Скачать робота можно тут – bot.zip.

Перед запуском необходимо зарегистрировать аккаунт на jabber-сервере и подружить его с тем аккаунтом, которому наш робот будет посылать информацию об изменениях. Ну и конечно же, исправить файл конфигурации и список адресов для отслеживания. После чего запускаем и наш робот начинает работать в фоновом режиме.

Второй аспект – перекодирование сезонов. Не секрет, что многие сериалы уже идут не один год и по каждому из них набралось порядочное количество серий. Так же очевидно, что все это надо перекодировать – Adobe Flash понимает достаточно небольшое число видео и аудио-кодеков. Помимо всего есть еще один параметр, который надо подкорректировать – верхняя граничная величина скорости кодирования, которой определяется будет ли наш пользователь смотреть видео без проблем или ждать каждые пять секунд дозагрузки нового фрагмента. В случае 720p мы можем использовать значение максимальной скорости потока видео 1664 Кбит/с, для аудио – 192 Кбит/с (на канал, каналов обычно 2 штуки), что в сумме даст потребную пропускную способность в 2 Мбит/с (т.е. пользователи с тарифным планом, подразумевающим меньшие скорости, будет, вероятно, испытывать неудобства). Это обычно ниже того потока, на который рассчитаны размещаемые на трекерах файлы, и, разумеется, ведет к определенной потере качества, порой заметную на глаз, но, в тоже время, позволяет экономить место на диске – 40 минут серии будут занимать уже не 1.4 Гбайт в среднем, а 500 Мбайт. То есть выбор параметров сжатия в большей степени продиктован балансом между качеством и доступностью для пользователей / занимаемым пространством.

Другой аспект данного вопроса – формат контейнера. Можно использовать flv («родной» для Flash Player формат), но я предпочитаю mp4 – это продиктовано потенциальными сложностями, которые могут возникнуть в проигрывании flv у сетевых плееров и медиа-центров. Хотя, возможно, эти сложности и надуманные, и можно использовать любой контейнер, который поддерживает разворачиваемая на сервере система вещания.

Итак, вернемся к тому факту, что серий много. Соответственно, возникают следующие задачи: а) как перекодировать большое число серий пачкой (привести к нужному формату и скорости потока), б) как оформить большое количество серий для разового импорта в систему публикации.

Первая подзадача решается просто. По-хорошему, следовало бы создать систему, которая в пакетном режиме обрабатывала задачи на перекодирование, обходила каталоги, преобразовывала бы видео-контент и выкладывала результат деятельности на сервер. Наверное, так было бы правильно и хорошо. Если бы не единственный нюанс – порой исходный материал содержит несколько дорожек, дорожки могут быть перепутаны, в результате чего на выходе получается серия, где все герои говорят не на том языке, который хотел бы слышать посетитель (а в отдельно преобразованной звуковой дорожке, которую мы тоже будем выдирать для наших целей – как раз тот самый перевод). Поэтому контент после преобразования необходимо выверять. Что, впрочем, не оправдывает тот полурукопашный подход, который я применил для hdin.tv. Поскольку серии часто имеют в названии структуры типа s(номер сезона)e(номер эпизода), достаточно легко и просто написать простенький PHP-сценарий, который пробежится по файлам текущего каталога и при помощи ffmpeg сделает файлы требуемого формата, выдернет дополнительную дорожку с языком оригинала и сформирует стоп-кадр (на 10-й секунде видео), причем сделает это, давая результатам имена формата (номер сезона)-(номер серии).

Сценарий можно скачать здесь, он достаточно простой, чтобы не писать его самостоятельно.

Вторая подзадача решается тоже весьма просто, хотя автоматизировать ее я бы не рискнул. Допустим, в нашей системе управления сайтом есть база с сериалами и эпизодами, на основе которой будут формироваться страницы для доступа к контенту. Поэтому для массового импорта всего перекодированного достаточно написать сценарий, который, допустим, получит на вход csv-файл со списком номеров сезонов, номеров серий и названий, после чего благополучно загонит их в SQL-таблицу, по которой (в нашем случае) будет формироваться представление для посетителя. А сам файл легко создать при помощи OpenOffice Calc или еще каких альтернативных пакетов ПО на основе данных из о сериях из Wikipedia или IMDB. Данное техническое решение достаточно тривиальное, чтобы его публиковать, поэтому оставим это на самостоятельное обучение.

Итого, на данном этапе мы умеем получать контент и его описание в нужном формате, что позволяет нам перейти к самому интересному – настройке сервера вещания и разработки собственно ресурса, где будем этот самый контент публиковать. Сразу уточню, что в рассмотрении этого вопроса я не буду касаться двух аспектов – подсистемы авторизации пользователей и регистрации по приглашениям (поскольку это достаточно просто даже не для самого опытного вэб-разработчика) и способа доставки контента с рабочей станции на сервер (потому как это просто сделать множеством возможных методов, например, при помощи Samba, WebDAV, rsync или DRDB, и так же вполне тривиально).

Итак, доставлять видео на браузер посетителю мы може как минимум двумя основными способами – посредством RTMP или банально поверх HTTP. Для первого потребуется поднимать дополнительный сервис типа ErlyVideo или Wowza Media Server, за последний придется еще и заплатить. Но в определенной степени этот метод не самый удобный – а) в этом случае мы ограничиваем количество клиентов, позволяющих просматривать видео, браузером и AIR-приложением (медиа-центры, не поддерживающие интеграцию Flash Player-а, так же останутся за бортом), б) в некоторых случаях RTMP может быть просто банально заблокирован не в меру ретивым системным администратором. Поэтому в угоду универсальности и простоте будем отдавать контент посредством псевдо-потокового HTTP-вешания, для чего вполне сгодится вэб-сервер nginx, дополненный модулем h264-streaming.

Собираем на сервере nginx (можно в пакет, можно напрямую), с подключением дополнительного модуля, устанавливаем и конфигурируем согласно инструкции (nginx можно взять посвежее).

Следующий этап – создание сайта. На эту тему тоже можно долго рассуждать, спорить, какая система управления лучше и правильнее, поэтому углубляться в это, наверное, смысла особо не имеет. На hdin.tv применена моя старая наработка – самописная система управления, позволяющая конструировать структуру БД из-под себя на основе хранения метаинформации, а пользовательский интерфейс обеспечивался сгенерированными по запросу администратора статическими HTML-файлами. В этом случае для взаимодействия с пользователем достаточно nginx-а, который будет отдавать по сути дела статический контент (немного потеряли в динамике, но для сайтов подобного плана оно, наверное, не сильно критично).

Единственный нюанс в создании сайта – использование готового или самописного плеера (тут надо отметить небольшую путаницу в терминах – под плеером в данном случае подразумевают не Adobe Flash Player, являющийся плагином к браузеру, а некий созданный для него swf-файл, который может управлять параметрами вывода видео). Я для ресурса использовал JW Player, позволяющий нарастить функционал проигрывания (добавить субтитры и дополнительные дорожки, задействовать горячие клавиши), который достаточно просто конфигурируется через flashvars или вспомогательной JS-библиотеки типа SWFObject. Опять же, наличие у плеера JavaScript API позволило реализовать такую приятную мелочь, как затенение экрана в момент проигрывания:

1
2
3
4
5
6
7
8
9
10
11

В общем, хорошая штука, всячески рекомендую. Особо приятно то, что он поддерживает http-streaming «из коробки», впрочем, за остальные плееры не берусь утверждать, может быть они умеют это делать еще лучше.

Отдельно замечу на предмет двух вещей – Smooth streaming (возможность подстраивать поток видео под пропускную способность канала до пользователя) и HTML5 (который имеет встроенную в обход достаточно прожорливого до ресурсов на не-Windows платформах Flash Player-а подсистему для проигрывания видео). Первая штука чрезвычайно полезна, но в случае если вы захотите увеличить доступность ресурса для большего числа пользователей, в том числе и с низкоскоростными каналами. Но, увы, она требует как поддержки со стороны пользователя (что не страшно, поскольку версия 5.1 JW Player-а, по анонсам разработчиков, поддерживает эту опцию, сам я еще не проверял), так и предполагает наличие на сервере исходного контента, перекодированного как минимум под две скорости (бОльшую и меньшую), т.е. место на жестком диске будет расходоваться очень быстро. Впрочем, ничто не мешает сделать подобное в случае создания версии ресурса для iPhone, iPad и прочих мобильных устройств.
HTML5-браузеров c поддержкой h.264 не так много, поэтому я сделал такую простую проверку на JavaScript, позволяющую показать дополнительную кнопку переключения в этот режим на панель над проигрывателем:

1
2
3
4
5
6
7
8
9
10

if (supportH264()) {
$("#h5v").show();
}

function supportH264() {
var v = document.createElement("video");

if (!v || !document.createElement('video').canPlayType) { return false; }
return v.canPlayType('video/mp4');
}

К сожалению, встроенные в браузер видеопроигрыватели, как правило, достаточно бедны по функционалу, поэтому перед масштабной поддержкой HTML 5 лучше дождаться выхода какого-либо открытого плеера для данной технологии (например, openplayer).

После того, как все поставлено, настроено и оттестировано, и первые пользователи атакуют ваш сервис с целью посмотреть видео, поэтому осталось несколько моментов:

создать средства, позволяющие отслеживать добавления новых серий. для начала достаточно RSS, который затем можно перенаправить в Twitter и социальные сети;
создать XML или JSON-выгрузку данных для ресурса. Это очень полезно, если в дальнейшем вы или ваши колеги захотят написать специализированное AIR-приложение или плагин для медиацентра;
подключить систему сбора статистики (рекомендую Google Analytics) и систему мониторинга (рекомендую Cacti) для последующего упрощения поддержки ресурса;
протестировать взаимодействие с различными плеерами типа VLC или WMC – порой смотреть через них удобнее, нежели через браузер.

Если все прошло успешно – мои поздравления, теперь вам предстоит долгая и кропотливая работа по подбору сериалов, их перекодированию, описанию и оформлению. Если нет – напишите комментарий к данной заметке, попробуем разобраться.

JW Player, ActionScript и тройка маленьких плагинов

Максим Крентовский — Thu, 28 Jan 2010 13:03:54 +0000

Как известно, видео на стороне клиента можно проигрывать большим количеством вариантов:

через Flash-проигрыватель – наверное, самый распространенный вариант;
через Silverlight-проигрыватель;
через ActiveX-элемент, реализуемый каким-либо установленным проигрывателем в системе (Windows-метод);
через тег video согласно стандарту HTML5 (если браузер поддерживает);
через системный видео-проигрыватель (например, VLC);
посредством медиа-центра (например, Plex и XBMC).

Соответственно, чем больше средств предоставлено пользователю на сайте, тем больше вероятность, что он с комфортом посмотрит интересующий его видеоролик (сейчас мы сознательно упрощаем вопрос, игнорируя тот факт, что пользователь может хотеть смотреть видео на нетбуке, таблетке или смартфоне). Однако в крайнем случае можно использовать Flash-проигрыватель, как самый распространенный вариант.

В процессе работы над hdin.tv я использовал проигрыватель JW Player компании LongTail Video. Достаточно функциональный, с системой дополнительных модулей и легко настраиваемый через параметры встраивания.

По мере развития ресурса пользователи добавили в список пожеланий возможность управлять проигрывателем при помощи клавиатуры (что очень удобно, неоднократно сам замечал), подключать субтитры и оригинальные звуковые дорожки. Весь ожидаемый функционал был реализован в виде отдельных модулей, расположенных на сайте разработчика, поэтому проблем, как мне показалось, быть не должно.

Однако не все так просто. Дело в том, что достаточно недавно JW Player сменил цифру в начале именования версий с 4 на 5. С новым API для плагинов, почти полностью переписанный, он сохранил совместимость со старыми модулями, но не со всеми и не всегда на очень хорошем уровне. Т.е. при подключении возможны были сбои в работе как плагина, так и плеера. В результате пришлось хорошенько потрудится над кодом модулей, благо они весьма благополучно могли собираться при помощи Flex SDK, доступной под Линукс, а про ActionScript я что-то помнил, когда занимался Flash-элементами для сайтов. Поскольку исходный код модулей распространялся под лицензией GPL, соответственно, было бы неправильным держать код в тайне, тем более что и тайны никакой нету, и моего труда в нем мало.

Как собирать плагины
Потребуется Flex SDK (берется на сайте Adobe, прямую ссылку не даю, поскольку оно там неплохо разбросано). Далее, пишем Shell-сценарий для упрощения процедуры.

1
2
3

#!/bin/bash
FLEXPATH=/home/mkrentovskiy/Flex/sdks/3.0.0
$FLEXPATH/bin/mxmlc ./com/jeroenwijering/plugins/Captions.as -sp ./ -o ./captions.swf -use-network=false

Тут одна особенность – для компиляции вам лучше всего взять все исходники плеера, поскольку код модулей содержит ссылки на классы проигрывателя. В некоторых случаях могут потребоваться начальный код плагинов, который так же можно взять с репозитария.

Shortcuts
Этот модуль отвечал за управление плеера горячими клавишами, превосходно работал на 4.х, но категорически отказывался на 5-й. В результате, его пришлось переписать полностью и выкинуть вспомогательные фишки наподобие пошагового проигрывания. В результате осталось только управление процессом проигрывания (пуск, пауза, стоп), перемещение по плейлисту, включение/выключение полноэкранного режима и управление уровнем звука.

Shortcuts.as

Captions
Модуль субтитров практически не изменился, за исключением того, что я убрал кнопку включения / выключения модулей (на сайте это сделано через JavaScript) и подвинул повыше отображаемые субтитры – в случае, когда панель управления воспроизведением автоматически убиралась с экрана, модуль неправильно рассчитывал позицию, в результате чего субтитры блокировали управление воспроизведением.

Captions.as

Audiodescription
Модуль наложения дополнительной звуковой дорожки также подвергся незначительным изменениям. Во-первых, было отключено автоматический запуск звука до начала воспроизведения (возможно, это не было ошибкой, но явно не входило в логику работы проигрывателя). Во-вторых, также были удалены кнопки управления включением / выключением плагина, поскольку эта функциональность реализовывалась при помощи JavaScript. В-третьих, было добавлено выключение основного звука, поскольку в случае незначительной рассинхронизации дорожек могло появляться неприятное эхо. По-хорошему надо было сделать отдельный элемент управления, позволяющий пользователю управлять громкостью воспроизведения дополнительной дорожки, но, увы, мои познания в Flash не столь значительны, чтобы сделать это.

Audiodescription.as

В целом, JW Player – на редкость удобный инструмент, а новое API для плагинов – простое и понятное. Думаю, рано или поздно авторы плагинов приведут свои разработки к новому API и тогда сделанные мной «костыли» не потребуются.

Накопившееся

Максим Крентовский — Thu, 31 Dec 2009 14:27:45 +0000

За прошедшее время накопилось множество работ на ниве персонального труда, потому не буду презентовать их поодиночке, а расскажу о движении по всем фронтам одновременно:

cnmt-tula.ru

На сайт добавилась система заказов, позволяющая составлять список инструментов к покупке с выходом на первичные документы (договор, счет, спецификация).

hdin.tv

Ресурс потихоньку прогрессирует, добавляются новые серии и появляется новая функциональность. Так, как я уже ранее писал, появился интерфейс для пользователей iPhone. Запланировано так же много интересных мелочей для большего удобства использования ресурса.

tulavideo.net

Буквально считанные часы свет назад свет увидела вторая версия сайта. Он перенесен на новое оборудование, проведено обновление сетевых устройств до провайдера. В новой версии полностью ликвидирован раздел пользовательских роликов (по причине малой его популярности), добавлена обязательная регистрация, обновлен проигрыватель, разделы «Вещание» и «IPTV» объединены. Переработан (и, надеюсь, будет дальше улучшаться) дизайн разделов, в планах – пересмотр накопленного контента с последующим обновлением с упором на лучшее качество.

GuardCRM

Внутренний проект с моей постоянной работы стал основным полем деятельности в течении последнего полугодия. Первая версия системы после внедрения откровенно «забуксовала» – пользователям было сложно функционировать в терминах системы, поскольку перехода бизнес-процесса от as is к to be так и не произошло. Поэтому система была модернизирована с целью совмещения уже устоявшихся в повседневной деятельности терминов и предметов: добавлены электронная версия заявки (как документа, определяющего взаимодействие компании с контрагентами) с анализом на основании уже имеющихся в системе данных и автоматическим восстановлением задач согласно основному бизнес-процессу; у задач появился признак «успех/неуспех», влияющий на шаги развития бизнес-процесса; добавлены вспомогательные бизнес-процессы, инициируемые системой автоматически (например, отключение клиента из-за неоплаты); добавлены сущности «Лицензии» (для формирования печатных документов) и «Опросы» (для фиксирования телефонных переговоров). Помимо этого в систему были внедрены отчеты, позволяющие получить требуемые в повседневной работе данные, расширены критерии поиска клиентов, незначительно упрощен и улучшен интерфейс.

Модернизированная система успешно функционирует со значительно бОльшей степенью вовлечения сотрудников, чем было изначально.

В общем, вроде все. С наступающими!

Вещание видеопотока при помощи erlyvideo

Максим Крентовский — Thu, 17 Dec 2009 20:18:32 +0000

Каким бы хорошим не был Wowza Media Server, но у него есть одно очень неприятное (но вполне справедливое) неудобство – версия для разработчика ограничена 10 одновременными подключениями, а финансирование некоторых проектов не позволяет приобретать полноценную версию. Поэтому с самого момента работы с RTMP мною рассматривались различные варианты использования открытых разработок. Увы, более-менее рабочим решением до недавнего момента был Red5 – медиа-сервер, сделанный на платформе J2EE, который оставлял впечатление тяжелого и неповоротливого монстра, а остальное и вовсе не выдерживало никакой критики.

Прежде чем перейти к найденному решению, напомню задачу – посредством PBI DCH-4000P-42S в сеть ретранслируется ТВ-каналы со спутника SD-качества в MPEG-2. Каналы поступают на VLC-проигрыватель, который гонит MPEG-TS поток поверх HTTP (это сделано для того, чтобы успешно преодолевать многочисленные брандмауэры и трансляции адресов, за которыми ютятся конечные потребители). Задача же собственно состоит в том, чтобы вещать приходящие ТВ-каналы в сеть еще и поверх RTMP, т.е. доставлять до посетителя посредством Flash-проигрывателя, который, увы, предпочитает H.264.

Ранее это было сделано при помощи VLC и Wowza Media Server. VLC забирал данные с ретранслятора, перекодировал поток и отдавал данные поверх RTP на Wowza, которое благополучно оборачивала их в RTMP. К сожалению, опыт тут же показал, что на используемый сервер вряд ли возможно повесить более одного канала – процесс сжатия в реальном времени довел уровень загрузки всех четырех ядер до 40-50%. Но и одного канала было достаточно для демонстрации технологии.

Новое решение, не ограниченное числом соединений, базируется на erlyvideo, на которое я наткнулся в поисках альтернативы. Проект был одним из многочисленных заброшенных проектов на Google Code, пока за него не взялся Максим Лапшин и не начал активно его развивать. В результате проект динамично обрастает функционалом и уже на данном этапе вполне может быть использован для вышеупомянутой задачи.

Erlyvideo написан на Erlang-е и требует установки соответствующей среды исполнения и библиотек. Помимо этого потребуется VLC, который и данном случает будет заниматься перекодированием потока. К сожалению, стандартный VLC поставки Debian Lenny ничего не знает о x264-кодировщике, поэтому пришлось собрать медиа-комбайн из исходников с добавлением требуемых библиотек.

Строка конфигурации для сборки VLC может выглядеть следующим образом:

1	./configure --enable-live555 --with-live555-tree=/usr/src/live --enable-libdvbpsi --disable-nls --disable-mozilla --disable-postproc --disable-dbus --disable-mad --disable-swscale --disable-glx --disable-fribidi --disable-qt4 --disable-skins2 --enable-x264 --disable-libtool

Далее, необходимо собрать erlyvideo прямо из git-репозитария:

1
2
3
4

git clone git://github.com/maxlapshin/erlyvideo.git
cd erlyvideo
mkdir ebin
make

Erlyvideo так же умеет принимать MPEG-TS поток и переоборачивать его в RTMP, но пока это делает в пассивном режиме – необходимо заставить VLC отдавать перекодированный поток поверх HTTP и при помощи специального сценария на Erlang-е из состава erlyvideo пробросить этот поток на сервис так же поверх HTTP при помощи метода PUT.

Перекодирование с выходом на вещание поверх HTTP в VLC делается следующей командой (поскольку мы делаем все автономно на сервере, используем опцию –daemon, при отладку лучше применять -vvv):

su vlc -c "/usr/local/bin/vlc --daemon http://vlc-tv:8001/ '--sout=#transcode{vcodec=h264,venc=x264{me=dia,merange=16,subme=1,analyse=none,direct=spatial,pbratio=1.5,bframes=1,vbv-maxrate=400,vbv-bufsize=400,ratetol=400.0},vb=400,deinterlace=yes,nohurry-up,acodec=mp4a,ab=64,channels=1}:std{access=http,mux=ts{pid-video=101,pid-audio=100},dst=127.0.0.1:8090}'"

Особо отмечу, что параметры подобраны для обеспечения максимальной скорости перекодирования контента – в этом случае нагрузка на процессоры сервера не такая значительная, как при использовании конфигурации кодера, ориентированной на качество картинки.

После чего необходимо запустить erlyvideo. Отредактировав конфигурационный файл ebin/erlymedia.app, вписав наше доменное имя в один из виртуальных хостов, сделаем make start, что запустит сервис как демон (make run произведет запуск в Erlang-консоли с выводом всей отладочной информации). Теперь можно запустить утилиту проброса потока (первый параметр – откуда, второй – куда пробрасываем):

1 2	cd conrib ./reverse_mpegts http://127.0.0.1:8090 http://имя_хоста:8082/stream/название_потока

Однако мы запускаем утилиту на сервере и держать ради нее постоянную консоль было бы не «ком-иль-фо». Поэтому достаточно добавить опцию -detached в третью строку данного сценария – это позволит запускать ее отвязанной от терминала.

Если все сделано корректно – можно попробовать просмотреть поток при помощи JW Media Player (последняя, 5 версия как раз подойдет) – в качестве параметров необходимо указать streamer как rtmp://имя_хоста/, file – название потока (которое после stream в URL назначения). К сожалению, тут есть неудобство, в котором я подозреваю плеер – после начала проигрывания начинает проигрываться только звук без видео, если нажать на паузу, а потом снова на воспроизведение – все будет работать без проблем. Впрочем, это неудобство еще подлежит детальному изучению и устранению.

У меня на tulavideo.net erlivideo таким образом успешно ретранслирует канал РБК. Выглядит это примерно вот так:

Ограничения на воспроизведения видео на iPhone

Максим Крентовский — Thu, 03 Dec 2009 06:20:00 +0000

В предыдущей заметке я рассказал про то, как сделать видео для iPhone, которое можно передавать на гаджет с использованием принципа Smooth Streaming. И даже дал ссылку на собственный проект, где применил результаты своего знания. К сожалению, как оказалось – весьма поспешно: люди, проверившие ресурс на iPhone 3G, сообщили, что ничего не работает и выдается одна и та же ошибка, схожая с той, которую получал я на своем аппарате – «Формат видео не поддерживается».

То, что я посчитал ограничением первой версии аппарата, оказалось более системным. Сложилось так, что эмуляция iPhone в SDK, распространяемом Apple, строится на немного иных принципах, нежели традиционная эмуляция аппаратуры, как это делали в QEMU в проекте OpenMoko. Если во втором случае действительно эмулировался ARM SoC, то разработчики iPhone пошли по пути меньшего сопротивления – они просто пересобрали среду под традиционную платформу (которая x86), и когда запускался эмулятор – по сути дела работает родной для платформы код, но с ограничениями, налагаемыми эмулятором. А когда программу для гаджета необходимо перенести на устройство – используется кросс-компиляция и уже генерируется код для платформы ARM.

Разумеется, при первых испытаниях трансляции псевдо-потока я использовал iPhone первого поколения и результат был плачевен – устройство от казалось играть данный формат. Но попытка воспроизвести тот же самый фрагмент в эмуляторе оказалась успешной, что и привело к ошибочному выводу, позднее опровергнутому посетителями ресурса. Скорее всего, эмулятор использует мультимедиа-прослойку операционной системы, гораздо менее привередливую, нежели та, которая используется в iPhone OS (у которой ноги растут тоже из Mac OS X). Поэтому он беспроблемно показал то видео, которое мой телефон посчитал сбойным.

Причина же невоспроизведения видео кроется не в формате, а в кодеке видео h.264. В его реализации для мобильной платформы Apple внесло ряд ограничений, нарушение которых ведет к тому, что файл просто не воспроизводется. Поэтому правильно подобранные параметры из ссылки в предыдущей статье приводят к закономерно успешному результату.

Мне остается выразить благодарность всем тем, кто протестировал мой ресурс и указал на ошибку. Спасибо большое!

Потоковое видео на iPhone

Максим Крентовский — Mon, 30 Nov 2009 11:18:42 +0000

Как я уже ранее писал, вещать видео на iPhone можно было начиная с самых первых версий прошивки в псевдо-потоковом режиме, как, собственно, и делал популярный сервис YouTube. Т.е. через сеть поверх HTTP-протокола отдавался mp4-файл, а сервер умел отрабатывать параметры, передаваемые плеером и формировать заголовки формата в случае, если пользователь желал посмотреть ролик с середины.

В третьей версии прошивки появилось нововведение – трансляция видео стала возможна в потоковом режиме (но тоже поверх HTTP, по вполне очевидным причинам – этот протокол без проблем преодолевает многочисленные proxy-сервера и трансляции адресов по пути следования от клиента к серверу и в обратном порядке). Теперь для потоковой трансляции необходим MPEG-TS-контейнер, на который могут ссылаться m3u8-файлы, исполняющие роль плейлистов. Помимо этого в Safari появилась поддержка тега video, позволяющая встраивать ссылки на видео в специализированные для гаджета странички.

Помимо этого, в прошивке появилась возможность организации Smooth streaming потока. Напомню, что принцип подобного вещания весьма прост – на сервере вещателя хранится несколько версий видеоролика, сжатых с разными уровнями качества (для разной пропускной способности канала между клиентом и сервером и возможностей оборудования клиента). Каждый ролик разбит на множество фрагментов (например, по 2 секунды длительностью), что позволяет плееру автоматически переключаться между вариантами во время трансляции (в полноценных трансляционных протоколах типа RTP идет просто выпадение кадров). Такая возможность также появилась и для iPhone, причем реализовать ее достаточно просто:

перекодируем видео в нескольких вариантах под разную пропускную способность канала (например, под 3G-сеть и WiFi-сеть);
при помощи специализированной утилиты разрезаем полученный файл на фрагменты;
создаем для каждого варианта плейлист формата m3u8, содержащий список всех фрагментов (обычно эта задача так же может быть реализована при помощи утилиты порезки);
создаем общий плейлист формата m3u8, включающий оба варианта с указанием пропускной способности каждого варианта;
помещаем полученное на вэб-сервер и делаем страницу с тегом video, ссылающуюся на общий плейлист.

Обобщенный плейлист может выглядеть следующим образом:

1
2
3
4
5

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=1024000
video_1M.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=512000
video_512K.m3u8

По умолчанию гаджет будет играть первый поток (нацеленный на пропускную способность в 1Мбитс), в случае, если производительности и/или ширины канала не хватит – переключится на следующий, которому достаточно 512Кбитс.

Подробную инструкцию по созданию видео можно почитать в статье iPhone HTTP Streaming with FFMpeg and an Open Source Segmenter, там все хорошо описано и приведены ссылки на утилиту порезки, которая потребуется дополнительно к традиционному ffmpeg. Кроме того, если вы привыкли пользоваться ffmpeg для перекодирования с применением h.264-кодека, думаю так же полезно почитать FFmpeg x264 encoding guide.

Ну и напоследок ложка дегтя в бочке меда – к сожалению, опыты показали, что на первых поколениях iPhone и iPod Touch данный подход может не сработать. По крайней мере на моем iPhone первого поколения с прошивкой 3.0 плеер выдал ошибку «Данный формат не поддерживается», при этом программный эмулятор платформы из комплекта iPhone Developer SDK без проблем проигрывал видео и даже переключался на более худшее качество, когда ему не хватило пропускной способности канала. Возможно, это уже исправлено в более новых версиях прошивки, что требует дополнительной проверки. Но не исключена ситуация, когда Apple отключила эту возможность в телефонах и плеерах первого поколения, посчитав, что производительности системы попросту не хватит.

Пример реализации вышеописанного принципа можно посмотреть на моем проекте сериалов в HD-качестве – краткая инструкция по использованию, собственно сайт для iPhone.

Как сделать гаджет для Google Wave

Максим Крентовский — Tue, 10 Nov 2009 21:51:42 +0000

Google Wave – новый инновационный сервис Google, призванный заменить одновременно электронную почту, чат и средство групповых обсуждений. В основе лежат волны (wave) и вейвлеты (wavelet), представляющие собой ветви дискуссии, посвященные какой-либо теме. Сообщения, или всплески (blip), могут создаваться и редактироваться в рамках волн как участниками обсуждения, так и роботами, следящими за дискуссией и дополняющие ее данными (например, автоматическим переводом фраз между языками). Помимо текста во всплески можно добавлять гаджеты – объекты, реализующие дополнительную функциональность, например, систему голосования, интерактивную карту и т.п. Изготовлением гаджетов и займемся в нашей статье.

Для начала рекомендую посетить описание Google Wave API – это полезное чтение, особенно если вы решили, что возможностей гаджетов недостаточно и нужно написать робота. В отличие от последних, гаджеты пишутся на традиционной для клиентской части вэба связке HTML + CSS + JS и представляют собой некий контейнер с данными, помещенный во всплеск через iframe.

Для начала уточним, что такое гаджет. Гаджет – это некий код, работающий целиком на клиентской стороне. Гаджеты в сервисах Google можно использовать не только в волне, но мы рассматриваем в данный момент вырожденный случай , поэтому не будем заострять внимание на собственно гаджетостроении.

Итак, гаджет представляет собой XML-файл, содержащий конфигурационные параметры и собственно код. Так, в нашем случае код гаджета будет выглядеть следующим образом:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

version="1.0" encoding="UTF-8"?>
>
title="YaMaps" height="400">
feature="setprefs" />
>
type="html">

]]>>
>

Что здесь нужно отметить? Ну, во-первых, что описание содержит две основных секции – ModulePrefs (конфигурационную секцию, которая задает, в частности высоту нашего гаджета) и Content (секцию, содержащую собственно код). Вид последней не сильно далеко ушел от html-файла – так же секция head, где перечислены вспомогательные файлы, и так же body, которая при загрузке документа создает объект $.ym (о нем чуть позднее), и содержит всего-навсего один элемент, куда мы будем прятать нашу карту. Стоит отметить, что аналогичный гаджет с Google Maps гораздо изощреннее, впрочем, сие не есть наша цель.

Пройдемся по подключаемым файлам. Поскольку наш гаджет может быть встроен абсолютно куда угодно, необходимо давать абсолютные ссылки. CSS-файл не представляет ничего сверхординарного и описывает стиль нашего единственного контейнера:

1
2
3
4
5

#map {
width: 99%;
height: 400px;
background: #eee;
}

Разумеется, такое простое описание можно было бы включить в код гаджета, но это не столь принципиально – мы пока пробуем и экспериментируем.

Далее, wave.js – это собственно и есть Wave API. О нем поподробнее позже. Следующим идет API Яндекс.Карт. Тут надо отметить любопытный момент – ключ на пользование API привязан к домену. Но поскольку гаджет будет встроен как iframe, а в качестве исходного домена будет мой же devimpress.com, то для того, чтобы ключ работал без проблем, вполне достаточно сгенерить его для домена размещения – и он будет без проблем встраиваться в волну.

javascript.gp – скрипт, выдернутый из GoogleMaps-гаджета, содержит результаты определения географического положения по IP с представлением их в виде переменных JavaScript. Думаю, достаточно один раз в браузере посмотреть на этот скрипт, чтобы понять, что именно он содержит.

Далее, идет подключение библиотеки jQuery (ее очень удобно использовать для написания приложений на JavaScript и Google, слава богу, это не ограничивает) и собственно yamaps.js, который и содержит код, реализующий функционал гаджета. Но предварительно стоит сделать лирическое отступление по поводу взаимодействия в волне.

Итак, гаджет в волне представляет собой элемент, который может находится в некотором состоянии по отношению к пользователю-участнику волны. Всего таких состояний несколько – режим редактирования (когда пользователь пишет всплеск), режим демонстрации (когда пользователь просматривает волну), режим воспроизведения истории (когда пользователь хочет знать как все развивалось в процессе, с использованием указателя времени). Соответственно, наш гаджет должен учитывать эти состояния и в зависимости от них давать возможность управлять картой или только отображать текущее выбранное положение.

К слову говоря, в момент чтения кодов у меня зародилась мысль, что есть еще и состояние администратора-владельца, поместившего гаджет в всплеск, но я этот вопрос не уточнял, потому как спешил написать эту заметку. Поэтому чтение документации в данном случае будет самым правильным.

Помимо состояний по отношению к пользователю, гаджет имеет возможность получить список всех пользователей на волне, а при помощи делегата – отслеживать их изменение. Получая список пользователей, можно добраться и до аватаров, и до имен пользователей, что, в целом несложно, но в данном примере это никак не используется.

Далее. Когда гаджет находится в режиме редактирования, предполагается, что пользователь делает над ним всякие нехорошие штуки, как, например, перемещает карту, увеличивает/уменьшает, сменяет тип отображения карты на вид со спутника или гибридный. То есть изменяет состояние самого гаджета, которое, согласно идеологии волны, должно быть а) запомнено для истории, б) передано на сторону других пользователей, дабы те наблюдали за редактированием в прямом эфире, в) сохранено с целью восстановления в случае последующих входов на волну этого и других пользователей. И тут в Google сделали просто и изящно – создателю гаджета необходимо прописать две процедуры: первая будет отслеживать изменение состояния гаджета, сериализовать его в JSON и отправлять в волну, вторая – служить делегатом в случае получения состояния, разворачивать данные о нем из JSON и применять их к гаджету. Соответственно, фиксируя на сервере смену состояний, они получают историю, пересылая изменения состояния между гаджетами на пользовательских компьютерах – синхронизацию и интерактив, а по последнему сообщению можно восстановить последнее состояние гаджета для тех, кто только присоединился к волне или отходил почитать другие волны. Просто и очевидно. Правда, по названию функции можно предположить, что все состояние объекта пересылать не нужно, достаточно дельту изменений, но, повторюсь, у нас вопрос познавательский, а структура, описывающая состояние гаджета, незначительная – координаты центра, уровень детализации и тип отображения карты – поэтому будем передавать состояние целиком, без рассчета дельт.

Собственно, код с комментариями, думаю, будет лучшей демонстрацией.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149

Счастливые обладатели учетной записи Google Wave (мои номинации кончились, если что) могут попробовать проинтегрировать гаджет в свои волны – http://devimpress.com/p/wave/yamaps/yamaps.xml. Всем читателям статьи рекомендую еще раз обратится к руководству по API Google Wave, дабы перепроверить мои сведения, основанные большей частью на анализе кода примеров. Буду много благодарен, если укажите на ошибки и неточности.

Git-репозитарий с доступом по HTTPS

Максим Крентовский — Tue, 10 Nov 2009 18:45:01 +0000

Время, когда правил только CVS, прошло безвозвратно, а посему сейчас много систем контроля версий, хороших и разных, централизированных и распределенных. Прелесть последних состоит в том, что каждая рабочая копия репозитария может также служить как сервер для создания других рабочих копий, поэтому даже если с основным хранилищем произойдет что-то нехорошее – можно воспользоваться рабочей копией.

Прелесть распределенных систем не ограничивается подобной «устойчивостью к отказам». Если проект очень сложен, требуется сложная и инвариантная разработка с последующей интеграцией изменений, без распределенных систем контроля версий приходится очень туго. В частности, Git, написанный Линусом Торвальдсом, используется для разработки ядра ОС Linux, сложность разработки которого можно себе представить, если поглядеть на размер кода. Git очень удобен, с учетом многообразия его возможностей, которые позволяют построить на его базе действительно распределенное хранилище данных. К сожалению, использование Git ограничено в основном не-Windows системами, для разработки в рамках гетерогенных сред следует использовать Mercurial и другие DSCM.

Особенность git-репозитариев (а каждая рабочая копия представляет собой полноценный репозитарий) является их равноценность. Т.е. мы можем сделать копию (при помощи git clone) репозитария, с которой можно делать традиционные операции типа checkout, update (в Git используется pull), commit, создавать ветки (branch) и маркировать срезы (tag), создавать и применять патчи, совмещать ветки и распространять изменения (merge). Но при этом все изменения будут происходить в рамках единственного репозитария. В случае, если же мы хотим работать по традиционной схеме, по аналогии с Subversion, используя некий серверный репозитарий в качестве основного хранилища, нам необходимо передавать (push) и принимать (pull) изменения, синхронизируя локальный репозитарий (который одновременно является и рабочей копией) и удаленный. Доступ к удаленному репозитарию можно организовать посредством множества вариантов, например, поверх ssh, ftp, http (WebDAV), так и при помощи специализированного сервиса (URL в этом случае носит префикс git:).

В общем случае вполне достаточно доступа по https с авторизацией. Настроить Git-репозитарий в целом несложно:

конфигурируем Apache для использования WebDAV с соответсвующей авторизацией по имени пользователя и паролю
1
2
3
4
5
6
7
<Location /myrepository.git>
DAV on
AuthType Basic
AuthName "Git access"
AuthUserFile /etc/apache2/htpasswd.git
Require valid-user
Location>
создаем пустой репозитарий
1
2
3
mkdir /var/www/myrepository.git
cd /var/www/myrepository.git
git --bare init
устанавливаем права доступа на репозитарий, чтобы http-сервис смог не только читать, но и писать
1
chown -R www-data:www-data /var/www/myrepository.git

Все. Теперь можно создать рабочий репозитарий при помощи команды git clone https://username@git.myserver.com/myrepository.git. Тут может произойти неприятность – если сертификат у вашего https-сервера сгенерирован при установке, то маловероятно, что он присутствует в локальном OpenSSL-хранилище. Поэтому можно отключить проверку сертификатов при помощи установки переменной среды окружения GIT_SSL_NO_VERIFY=»true». В этом случае проверка сертификата сервера производится не будет.

Хорошо, у нас есть локальная копия сетевого репозитория. Теперь мы можем делать git add и git commit (чаще используют команду git commit -a). Но все данные о версиях файлов будут сохранятся только в нашем локальном репозитарии, сетевой будет по-прежнему девственно чист. Для синхронизации репозитариев надо сделать следующее

добавить в конфигурацию ссылку на удаленный репозитарий (это достаточно сделать один раз для данной рабочей копии)
1
git-config remote.upload.url https://username@git.myserver.com/myrepository.git/
синхронизировать репозитарии при помощи команды
1
git push upload master

, где master – текущий локальный репозитарий, а upload – вышесконфигурированное удаленное хранилище.

На последней операции я словил неприятный глюк с OpenSUSE 11, установленной у меня на рабочем компьютере. Git усиленно утверждал, что ментод http-push ему неведом, поэтому потребовалась ручная сборка из исходников с предоставлением требуемых библиотек. Сборка под домашний Mac не была столь избирательной и работала из коробки.

Много полезной информации по Git можно почерпнуть на официальном сайте. Там же есть шпаргалка с основными командами.