8 нояб. 2022 г.

MacBook Pro (2015) Linux Debian SD card reader and Bluetooth fix after a suspend

To fix those I've created a script in /lib/systemd/system-sleep/ with the following contents:

 

#!/bin/sh

case "$1" in
        pre)
            echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
            echo -n "1-3:1.2" |tee /sys/bus/usb/drivers/btusb/unbind
            ;;
esac


case "$1" in
        post)
            echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/bind
            echo -n "1-3:1.2" |tee /sys/bus/usb/drivers/btusb/bind
            ;;
esac

Of course, the values are not random and should be checked first on your machine with lspci -v and by looking into /sys/bus/usb/drivers/btusb


28 дек. 2021 г.

AIS receiver из Raspberry/Orange/Banana Pi и RTL SDR для Marine Traffic и ему подобных

Marine Traffic со товарищи и FlightRadar24 получают данные для своих сервисов от энтузиастов.

Энтузиасты обычно получают данные с соответствующих приёмников. Для морских и речных судов это приёмники AIS, для самолётов — ADS-B. AIS работает на паре каналов, называемых A и B, которым соответствуют частоты 161.975 и 162.025 MHz соответственно. ADS-B использует частоту 1090 MHz. Эта статья вкратце рассматривает процедуру настройки приёмника и антенного тракта для получения сигналов AIS.

Итак, чтобы построить сенсор, передающий данные в MarineTraffic, нам потребуется:
  • Raspberry Pi или какой-нибудь его аналог. Я использую Orange Pi Zero (256 MB RAM, четырёхъядерный ARMv7 процессор с частотой 1.2 GHz), его вполне достаточно. Важно, чтобы на нём был какой-нибудь линукс. Цена — от 10 до не знаю скольки долларов. Продаются на амазоне, алиэкспрессе, ебее, сайтах производителей.
  • Собственно приёмник — RTL SDR. Лучше не прямо совсем любой, а вот тот, который продаётся на сайте или хотя бы его клоны на Алиэкспрессе. Дело в том, что прямо стоковый DVB-T адаптер продаётся (если ещё вообще продаётся) с разъёмом MCX и рассчитан на кабель с волновым сопротивлением 75 Ом, а мы же тут типа крутые радиолюбители и хотим всё делать под 50-омный кабель и антенны. Поэтому лучше искать по словам «RTL-SDR Blog V3 R820T2». У него и разъём SMA, и вроде как он почувствительнее и поменьше шумит. Цена — от 15 до 30 долларов.
  • 50-омный кабель (RG-58 или лучше, но всё равно 50-омный). У ВЧ-кабеля немаленькое затухание, и чем выше частота, тем сильнее затухание. Не рекомендуют использовать RG-58 длиной больше 10 метров, и общее правило — «чем короче, чем лучше». Цена RG58 — от меньше чем доллар до полутора долларов за метр.
  • Коннектор для антенны. Я сделал четвертьволновый ground plane (1/4λ GP) с четырьмя противовесами, это очень хорошо делается на N-коннекторе с фланцем.
  • Пара коннекторов на кабель, соответствующих коннектору на приёмнике и на антенне. В нашем случае потребуется SMA male (к приёмнику) и N male (к антенне).

Это минимум. Для настройки антенны под частоту неплохо бы иметь друга-радиолюбителя или какой-нибудь прибор для анализа параметров антенного тракта. Для приделывания разъёмов к кабелю так или иначе потребуется обжимка для коаксиального кабеля и паяльник. Но минимум таков.








Главная сложность для меня заключалась в изготовлении антенны. Хороший антенный тракт — главное условие чувствительности системы. Я сделал свою антенну как описано здесь, естественно, с поправкой на используемые коннекторы и рабочую частоту. Использовал медную проволоку толщиной около 1 мм длиной в соответствии с этим расчётом. Длина штыря получилась около 445 мм, длина противовесов — около 490 мм. Первоначально изготовил антенну с некоторым запасом по длине, настраивал с помощью NanoVNA, откусывая по нескольку миллиметров бокорезами, пока не добился нужных параметров.

Настройка софтовой части не представляет особых сложностей. Как я уже написал, вам необходим работающий на вашем Pi линукс. Всё, что требуется — это собрать на нём rtl_ais, который принимает и обрабатывает сигнал и посылает полученные NMEA sequences на указанный адрес по UDP. Установка rtl_ais подробно описана на его странице, я вкратце рассмотрю параметры его запуска:

rtl_ais -g 35 -n -S 60 -p 54 -P xxxx -h aaa.bbb.ccc.ddd
  • -g 35 — усиление тюнера, в децибелах. Значение зависит от ваших условий. Для RTL-SDR Blog V3 может быть до 49. Подбирается опытным путём, т.к. тюнер сам достаточно шумный.
  • -n — выводить принятые NMEA sequences на stderr
  • -S 60 — выводить на stdout статистику принятых пакетов каждые 60 секунд
  • -p 54 — поправка частоты в PPM. Зависит от приёмника, подбирается, например, с помощью калибратора kal или rtl_test из комплекта librtlsdr, запущенного с ключом «-p».
  • -h — адрес хоста, на который отправлять получаемые данные. В случае с Marine Traffic получается от них при регистрации станции.
  • -P — порт, на который отправлять получаемые данные. В случае с Marine Traffic получается от них при регистрации станции.

Это всё. При использовании четвертьволновой антенны с RTL-SDR Blog v3 реальная дальность приёма сигналов — около 20 км без антенных усилителей сигнала.

26 нояб. 2019 г.

Лента с файловой системой (LTO5+, HP Ultrium, LTFS)

Начиная с LTO-5, стандарт ленты предусматривает её партиционирование, то есть разделение на части, в одной из которых, грубо говоря, хранятся адреса файлов на ленте, а во второй — собственно содержимое файлов.

Эта вещь позволила создание на ленте файловой системы (LTFS — Linear Tape File System), которая в линуксе монтируется через FUSE. Естественно, природа носителя накладывает свои ограничения, например, удаление файла не приводит к увеличению свободного места. Зато, как ни удивительно, поддерживаются sparse files, если это кому-то нужно на архивных носителях.

Конечно, доступ к ленте в режиме файловой системы интересен, потому что даже LTO-5 — это уже 1.6 терабайта, а такое количество данных не всегда единовременно доступно к бэкапу, а многосессионная лента с tar-ами — это не так чтобы очень удобно.

Короче, всё было за внедрение: наличествует HP half-height internal LTO-5 драйв и некоторое количество LTO-5 картриджей. Увага: несмотря на то, что LTO5-привод способен писать LTO4-ленты, создавать LTFS на этих LTO4-лентах нельзя!

Путём чтения Википедии выяснилось, что для линукса как бы существует несколько реализаций от разных вендоров. Плюс нашёлся ещё относительно живой проект на Гитхабе, с которого и решил начать. Быстро выяснилось, что начал в какое-то неудачное время, потому что собираться на Debian Buster оно не очень хотело из-за поломанного в этом релизе дебиана pkgdata и отсутствующего icu-config в ICU. Собрал на stretch, перенёс на целевую машинку с buster-ом и приводом (тупо скопировал руками три недостающих библиотеки) — запустилось, но ругнулось на неподдерживаемый привод. Пошёл читать issues — да, действительно, оказалось, что этот проект поддерживает только привода IBM.

Гугль упрямо продолжал говорить, что HP-шные устройства поддерживаются под линуксом. Увы, но сайт HP не позволяет скачать линуксовую софтину для LTFS «просто так», требуя логина и пароля, которых у меня нет. Получить их я не пытался, может быть, это просто, не знаю. Поэтому почитал ещё интернетов и попробовал поставить Quantum LTFS. Сразу скажу, до компиляции там даже не дошло, потому что стало очевидно, что у этого кода очень много общего с гитхабовским проектом, но в него добавлена пара квантумовских приводов. Попытки прописать в код идентификатор моего привода я оставил на чёрный день, а пока что поиски привели меня на сайт Оракла. Скачал 64-битный RPM версии 1.2.7 для Oracle server 7.2, сконвертировал его alien'ом, установил, попробовал запустить, нашёл в репозиториях седьмой центоси три библиотеки из ICU нужной (50-й) версии, опытным путём подредактировал ltfs.conf — ура! mkltfs покрутил ленту и сказал, что OK, а основной бинарник (он у Оракла не ltfs, а что-то там про singledrive) без проблем смонтировал ленту в каталог. А, нет, одна мелкая проблема была: им нельзя передать в качестве устройства /dev/st0 или /dev/nst0, потому что они не могут смапить его имя в /dev/sgX из-за отсуствия в дебиановском ядре поддержки SCSI_PROCFS и /proc/scsi как такового. Зато они замечательно принимают прямо generic device name, которое можно получить из вывода lsscsi -g.

Результат — примерно 55 мегабайт в секунду на запись через scp. Может, получалось бы и ещё быстрее, но процессор на машинке не ахти.

21 мая 2019 г.

Ограничение скорости отдачи файла nginx'ом

Иногда хочется ограничить скорость отдачи файла. Ну, например, если вы раздаёте видеоролики, то имеет смысл выставлять максимум скорости отдачи файла в зависимости от его битрейта. Оказывается, это можно сделать на стандартном nginx (не Plus) через Lua-модуль:

location / { # или какой нужен, например, по маске имени
    set $drate '';
    set_by_lua_file $sum /var/www/html/datarate.lua;

    set $limit_rate $drate;
}


# datarate.lua просто вызывает внешний скрипт и сохраняет его выдачу в переменную
function os.capture(cmd, raw)
  local f = assert(io.popen(cmd, 'r'))
  local s = assert(f:read('*a'))
  f:close()
  if raw then return s end
  s = string.gsub(s, '^%s+', '')
  s = string.gsub(s, '%s+$', '')
  s = string.gsub(s, '[\n\r]+', ' ')
  return s
end

local curPercent = os.capture ("/usr/local/bin/getnum", false)
print (curPercent)
ngx.var.drate = curPercent


getnum:
#!/bin/bash
echo -n 50k

Очевидно, что getnum в этом примере — просто заглушка, т.к. он даже не пытается анализировать, на какой файл устанавливать ограничения.

28 авг. 2017 г.

Интернет в Сербии (Бач, лето 2017)

rbc.ru:

                                       Packets               Pings
 Host                               Loss%   Snt   Last   Avg  Best  Wrst StDev   
 1. jetspeed.iad                     0.0%    64    0.6   1.8   0.6  27.3   4.6
 2. 212.200.177.200                  0.0%    63   24.8  26.4  19.7 110.1  18.2
 3. 212.200.177.201                  0.0%    63   19.8  23.0  19.1 132.4  14.9
 4. 212.200.7.78                     0.0%    63   47.6  54.0  47.5 135.5  17.4
 5. 212.200.7.75                     0.0%    63   53.1  54.6  51.2 136.2  10.6
 6. 212.200.5.109                    0.0%    63   63.0  43.6  32.7 131.7  23.0
 7. 212.200.5.53                     0.0%    63   44.3  48.3  43.8 110.9  11.6
 8. v4-de-cix-r1.cirex.ru            0.0%    63   91.0  95.5  89.6 168.3  13.2
 9. 74-231-9-185.host.cirex.ru       0.0%    63   89.9  93.8  87.3 181.0  16.1
10. redirector.rbc.ru                0.0%    63   90.5  94.2  87.4 171.4  15.1


amsix.eu:
                                      Packets               Pings
 Host                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. jetspeed.iad                     0.0%   111    0.6   2.8   0.6  69.6   9.6
 2. 212.200.177.200                  0.0%   110   20.6  33.6  19.4 503.0  62.8
 3. 212.200.177.201                  0.0%   110   20.2  31.8  18.8 505.4  61.2
 4. 212.200.7.78                     0.0%   110   21.4  33.7  20.8 510.6  59.1
 5. 212.200.7.77                     0.0%   110   20.6  42.3  19.8 502.7  63.9
 6. bpt-b4-link.telia.net            0.0%   110   51.7  60.3  48.4 496.7  50.5
 7. prag-bb1-link.telia.net          0.0%   110   46.6  54.8  46.0 452.0  46.9
 8. hbg-bb1-link.telia.net           0.0%   110   52.8  71.8  51.2 425.8  48.1
 9. adm-bb3-link.telia.net           0.0%   110   59.8  68.4  53.2 378.4  40.9
    adm-bb3-link.telia.net
    adm-bb3-link.telia.net
    adm-bb3-link.telia.net
    adm-bb3-link.telia.net
    adm-bb3-link.telia.net
    adm-bb3-link.telia.net
    adm-bb3-link.telia.net
10. adm-b3-link.telia.net            0.0%   110   61.2  69.8  59.7 328.4  37.9
11. leaseweb-ic-308104-adm-b3.c.tel  0.0%   110   59.5  69.0  58.8 462.0  47.0
12. te-4-1.ce22.ams-01.nl.leaseweb.  0.0%   110   60.1  69.9  58.6 430.6  44.1
13. te-5-1.ce26.ams-01.nl.leaseweb.  0.0%   110   54.6  69.4  53.7 595.9  65.2
14. ???


slashdot.org:
                                                      Packets               Pings
 Host                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. jetspeed.iad                                     0.0%    86    0.8   3.4   0.7  65.0  10.6
 2. 212.200.177.200                                  0.0%    86   20.2  22.1  19.6  34.3   2.7
 3. 212.200.177.203                                  1.2%    86   19.8  24.1  18.9 148.1  19.0
 4. 212.200.7.68                                     0.0%    86   21.8  24.9  20.7  88.5  11.1
 5. 212.200.7.67                                     0.0%    86   20.4  25.8  20.1  87.9  13.7
 6. 212.73.203.129                                   0.0%    86   44.0  51.3  43.4 138.1  20.9
 7. ???
 8. CenturyLink-level3-150G.Washington12.Level3.net  0.0%    86  135.6 139.0 134.7 209.2  11.4
 9. 63-235-40-90.dia.static.qwest.net                0.0%    86  137.2 142.1 136.6 299.1  23.6
10. cr1-tengig0-7-2-0.washington.savvis.net          1.2%    86  157.9 162.7 154.8 263.6  18.5
11. 206.28.96.209                                    1.2%    85  155.6 155.6 150.1 237.6  12.1
12. 206.28.101.165                                   0.0%    85  157.4 156.9 153.2 287.6  15.2
13. das6-v3034.ch3.savvis.net                        0.0%    85  159.2 187.2 157.6 331.4  47.3
14. 64.27.160.198                                    0.0%    85  161.1 163.3 158.0 199.2   9.5
15. slashdot.org                                     0.0%    85  160.4 163.1 158.8 292.9  19.0


HKIX.net:
                                                      Packets               Pings
 Host                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. jetspeed.iad                                     0.0%    13    0.9   1.0   0.7   2.6   0.4
 2. 212.200.177.200                                  0.0%    13   27.7  22.3  19.8  27.7   2.6
 3. 212.200.177.203                                  0.0%    13   22.3  23.3  19.2  40.1   7.2
 4. 212.200.7.68                                     0.0%    13   33.7  34.4  33.7  35.9   0.3
 5. 212.200.7.65                                     0.0%    13   22.0  22.9  20.5  31.4   2.7
 6. 212.200.5.105                                    0.0%    13   34.3  38.3  33.5  70.6  10.5
 7. 212.73.203.245                                   0.0%    13   46.6  48.8  44.7  83.3  10.4
 8. ???
 9. 212.162.4.54                                     0.0%    13   46.8  47.6  46.4  50.0   0.9
10. tenge0-1-0-19.br02.hkg12.pccwbtn.net             0.0%    13  370.0 369.6 368.6 370.1   0.3
11. ???

26 окт. 2016 г.

Изменения в конфигурации системы стриминга видео

Около года назад я описывал самопальную систему стриминга live video с птичьей кормушки из говна и палок вебкамеры, ffmpeg и nginx.

Прошёл год, наука шагнула далеко вперёд, надо описать, что с тех пор изменилось-усовершенствовалось.

Во-первых, от использования ffserver получилось отказаться почти сразу же после написания прошлогодней статьи. «Получилось» — потому что связка ffmpeg+ffserver в настройке и работе, мягко говоря, хрупковата. Поэтому сразу после реализации механизмы были перепилены в сторону упрощения. В качестве сервера дистрибуции потока вместо ffserver стал использоваться nginx. Для этого nginx пришлось пропатчить волшебным патчем, добавляющим поддержку RTMP, HLS и MPEG-DASH. После этого nginx обретает умение принимать видеопоток по RTMP и раскидывать его в файлы, которые потом сам же nginx отдаёт браузерам, понимающим MPEG-DASH либо HLS. Точнее, в случае десктоп-устройств в качестве веб-клиента выступил flash-плеер Bitdash, который в то время (в версии 3.2.0) был доступен бесплатно с некоторыми ограничениями по трафику, которые меня вполне устроили.

Настройки Nginx в части обслуживания потока у меня имеют следующий вид:
nginx.conf:
rtmp {
    server {
        listen [::]:1935;
        application live {
            allow publish <my-source-IP>;
            allow publish <my-backup-source-IP>;
            deny publish all;
            allow play all;
            live on;
            publish_notify on;
            play_restart on;
            hls on;
            hls_path /tmp/hls;
            hls_fragment 10s;
            dash on;
            dash_path /tmp/dash;
        }
    }
}


sites-enabled/myserver.conf:

location /hls {
    root /tmp;
    types {
        application/vnd.apple.mpegurl m3u8;
    }
    add_header Cache-Control no-cache;
}

location /dash {
    root /tmp;
    types {
        application/vnd.apple.mpegurl m3u8;
        application/dash+xml mpd;
    }
    add_header Cache-Control no-cache;
}
Сам поток по-прежнему формируется с использованием ffmpeg, берущего с вебкамеры raw YUV и преобразующего его в, прошу простить меня за это слово, FLV-контейнер с 10-bit H.264 потоком внутри и отдающего его nginx'у с помощью примерно следующей командной строки:

ffmpeg -s 640x360 -f video4linux2 -i /dev/video1 -c:v libx264 \
 -crf 27 -preset slow -bf 8 -g 100 -pix_fmt yuv420p10le -qmin 10 -qmax 43 -aq 1 \
  -b:v 450k -bufsize 1200 -r 20 -an -f flv \
  -vf "drawtext=fontfile=/usr/share/fonts/truetype/freefont/FreeSans.ttf:text='%{localtime} $(cat /tmp/temperature)':fontcolor=white@0.9:fontsize=10:x=510:y=348" "rtmp://birdfeeder.online/live/test.flv live=1"

Upd: как выяснилось, десятибитный поток не понимает никто, кроме хрома. Поэтому вернулись к стандарту:
ffmpeg -s 640x360 -f video4linux2 -i /dev/video1 -c:v libx264 \
 -crf 27 -preset slow -bf 8 -g 100 -pix_fmt yuv420p -qmin 10 -qmax 43 -aq 1 \
  -b:v 450k -bufsize 1200 -r 20 -an -f flv \
  -vf "drawtext=fontfile=/usr/share/fonts/truetype/freefont/FreeSans.ttf:text='%{localtime} $(cat /tmp/temperature)':fontcolor=white@0.9:fontsize=10:x=510:y=348" "rtmp://birdfeeder.online/live/test.flv live=1"

Результирующий поток имеет битрейт в пределах от 200 до 350 килобит в секунду. Файл /tmp/temperature формируется независимо по крону и, увы, для отображения изменений в нём весь ffmpeg приходится периодически перезапускать.


Во-вторых, перед началом нового сезона было решено вновь проверить возможность отказа от использования Adobe Flash. Это, как кажется, вполне удалось. Теперь для показа используется VideoJS-contrib-HLS, а соответствующий код в HTML-файле выглядит так:

<HEAD>
 <link href="https://vjs.zencdn.net/5.8.8/video-js.css" rel="stylesheet">
 <script src="https://vjs.zencdn.net/ie8/1.1.2/videojs-ie8.min.js"></script>
</HEAD>
<BODY>

  <video id=example-video width=640 height=360 class="video-js vjs-default-skin" poster="/images/poster.jpg" controls>
    <source
       src="https://birdfeeder.online/hls/test.m3u8"
       type="application/x-mpegURL">
  </video>
  </center>
  <script src="https://vjs.zencdn.net/5.8.8/video.js"></script>
  <script src="videojs-contrib-hls.min.js"></script>
  <script>
  var player = videojs('example-video');
  player.play();
  </script>
</BODY>



Что не решено:

    1. Не получилось придумать, как выводить изменения температуры. Несмотря на то, что показания термометра фиксируются каждую минуту, обновлять их вывод в кадр приходится путём перезапуска кодировщика. Это делается ежечасно.
    2. Не получилось придумать, как отвадить от кормушки голубей. Несмотря на качающийся подвес конструкции, несмотря на короткий «насест», некоторые из них умудряются балансировать и выгребать из кормушки семечки вниз. Внизу подоконник и стая ждущих собратьев. Результат — к весне подоконник по залежам гуано сравним с лучшими чилийскими птичьими пляжами.

10 сент. 2016 г.

Про Burning Man как я его понял

В общем, Burning Man.

Спасибо, во-первых и в-главных,  +Konstantin Gratchev за серию его фотографий с Зе Мэна. Они может и получше тех профессиональных будут. Собственно, я из этих фоточек и узнал про существование этой штуки, пошёл почитать поподробнее и проникся масштабами. Рекомендую зайти к нему и посмотреть.

Насколько я улавливаю, в Штатах вообще больше нажимают на праздники осени и урожая, чем у нас. У нас как-то больше весенние прижились — Масленица, Первомай. Может, климат другой, поэтому больше поводов радоваться пережитой зиме (здесь как лыко в строку и Новый год — отмечание ещё одного пережитого года) и не отмечать урожай, а убрать его изо всех сил и свалиться. Как бы то ни было, День Труда и День Благодарения — большие осенние праздники, из которых День Благодарения явным образом является праздником Урожая, а День Труда — не знаю :)

Дальше, похоже, добрая традиция знатно запалить что-нибудь на праздник урожая имеет место быть и не уступит нашей масленице. Здесь дядька Кинг опять же со своим «Колдуном и кристаллом» встревает и подсказывает, что зажигали как надо. Чучелы дык чучелы, живую ведьму дык живую — привычка жечь имеется, а там уж что буйное воображение подскажет, да что под руку попадётся, то и спалим.

И вот все эти, возможно, существующие только в моей голове, факторы собрались в кучу и получился Burning Man. (Отступление: большое видится на расстоянии; но тут было бы уместно спросить какого-нибудь носителя культуры, в идеале со Среднего Запада, насчёт того, далеко ли я уехал от реального положения дел во вступлении. Но т.к. для этого явно надо было писать не на русском, то вся надежда на комментарии тех, кто.)

Дык ага! Burning Man — фестиваль искусства. И прямо отсюда надо и уточнять, и обобщать. С одной стороны, фестиваль, с другой стороны, движение, потому что хоть и проводится раз в году, но у него немалая постоянная аудитория. «Аудитория» тоже слово само по себе не совсем правильное, потому что утверждается, что там нет зрителей и посетителей, только участники. «Искусства» — тоже не уверен, что точное слово. Съезжаются люди into the middle of nowhere, в Неваду, на кусок пустыни в окружении гор, в индейскую резервацию в центре чуть ли не заповедных земель, и за несколько дней разворачивают там город. Вот именно так оно на сегодняшний день себя и видит: «Город в пустыне. Культура возможностей. Сеть мечтателей и тех, кто делает». Разворачивают рядом аэропорт (!), радиостанцию и строят всякие красоты (см. опять же у +Konstantin Gratchev с конца августа до конца первой декады сентября).

В последнее воскресенье августа заезжает основной народ. Тысяч пятьдесят-семьдесят. Тут есть два интересных обстоятельства-условия: 1) за деньги можно купить только кофе (который, утверждают, на кофе мало похож) и лёд, причём всего в паре точек. Всё остальное — либо с собой, либо меняться, либо получать в подарок. 2) После сворачивания города следов остаться не должно. Совсем. Вообще. Поэтому в руководствах не раз и не два обозначается: маслом и бензином из машины на землю не капать, воду после мытья посуды, рук, душа и т.д. на землю не сливать, пепел от сигарет не стряхивать, на земле ничего не жечь и т.п. правила, сотни ихъ.

Приезжают и начинается тусовище (см. «Слайды»)
Тусовище своеобразное в том плане, что это пустыня и лето и высокогорье (я так понял, около двух километров над уровнем моря). Поэтому до плюс сорока пяти днём, может упасть ближе к нулю ночью (упоминают в температурах в районе 40°F, что около пяти по Цельсию). Пыльные бури/шквалы, похоже, совсем не редкость. Пейте воду! — предупреждают в BM survival guide и говорят, что полтора галлона (5.67 литра) питьевой воды на человека на день с собой привозить просто необходимо.

Ага, собственно принципы, на которых это всё стоит. Их десять, я переводить целиком не буду, только самую суть (оригинал http://burningman.org/culture/philosophical-center/10-principles/)
  1. Radical inclusion. Каждый может быть частью BM.
  2. Gifting. BM — это про подарки (!)
  3. Decommodification. Я не знаю этого слова, но этот принцип подразумевает отсутствие коммерциализации (спонсоров, продаж, рекламы, культуры потребления)
  4. Radical Self-reliance. Всё своё приношу с собой.
  5. Radical Self-expression. Каждый самовыражается как он хочет. Здесь ещё говорится про уникальность талантов каждого.
  6. Communal Effort. BM - это про comunity. Отличное опеределение community видел там же рядом: You know you're in a community when you hear a laughter and singing around. Запало в душу.
  7. Civic Responsibility. Ну, это понятно при такой куче народа.
  8. Leaving no trace - не оставлять следов. На этом деле там мощный упор.
  9. Participation. Все участвуют. Зрителей нет.
  10. Immediacy. Вот тут дам полную цитату, чтобы не потерять в переводе: Immediate experience is, in many ways, the most important touchstone of value in our culture. We seek to overcome barriers that stand between us and a recognition of our inner selves, the reality of those around us, participation in society, and contact with a natural world exceeding human powers. No idea can substitute for this experience.

Насколько понимаю по откликам, BM — это такой Woodstock в смысле «трёх дней мира и музыки», только не про музыку, а больше про строительство (или изобразительное искусство? или инженерию? ну, короче, про то, что видно глазом), и малость покомфортнее (хотя тут кто как сам себе сделает), и не три дня, а неделю, и с легалайзом не совсем понятно.

Всё это «безобразие» продолжается неделю. А в конце всю (или не всю?) красоту сжигают!!11 прямо огнищщем! ночью!!11 и в следующие воскресенье-понедельник народ, постояв в десятичасовой пробке, разъезжается.


P.S. Сто́ит эта радость от пятисот до двух тыщ долларов за входной билет. Плюс восемьдесят долларов за въезд машины. Плюс что там выйдет за бензин, манатки и еду. Ну плюс немного за трансатлантический перелёт, если уж про большинство говорить :)

P.P.S В этом тексте вообще ничего не оказалось про сам фестиваль :)  Да и не могло. Смотрите «слайды», читайте сайт, съездите сами и расскажите нам, если это вообще возможно :)

Слайды.

А вот теперь — слайды!©®™
http://journal.burningman.org/category/burning-man-arts/brc-art/

FAQ

Глагне

Сайт: http://burningman.org/

 Видосики

1.  https://www.youtube.com/watch?v=kbIaqkeRIGw (оказывается, можно было ничего и не рассказывать, просто дать эту ссылку :)

27 февр. 2016 г.

Как я купил наушники Sven SEB-26BK. История одного разочарования.

Я вообще-то не из этих. Не из аудиофилов.
Но люблю, когда среди музыки слышны отдельные составляющие.
А ещё люблю, чтобы на халяву. Или хотя бы недорого.

Поэтому когда после некоторых поисков купил себе года три-четыре назад тогда за 310 рублей наушники Sven SEB-26 BK и обнаружил, что они реально качают (а за свои деньги качают нереально) звук, то радовался здо́рово. И многим их рекомендовал. И покупал с тех пор пару раз, потому что они, увы, недолговечны.

9 февр. 2016 г.

Asterisk/FreePBX и ISDN BRI через Cologne chips HFC-S

или Как я долбился в DAHDI.

Мысль поднять транк на ISDN BRI потоке мне вообще не приходила. Я просто хотел сконфигурировать SIP аплинк, и тут понеслось.

Короче, жил-был Trixbox с ISDN платой, воткнутой в NT по S/T интерфейсу. А потом хозяину этого триксбокса захотелось чего-то большего, и он позвал меня.

Триксбокс был страшен. Он жил на HP ML 110 G5 на пятой центоси с 2.6.18-м ведром. Не, я понимаю, что телефонистские интерфейсы могли бы и с 0.99pl12 жить не тужить, если бы оно их поддерживало, ничего в них за это время не поменялось. Но так как оно плохо понимало во всяких новомодных SATA-интерфейсах, то, например, HP-шный 7200RPM винт оно читало со скоростью 2-2.5 мегабайта в секунду, и пляски с hdparm'ом особого успеха не имели.

Поэтому, не мудрствуя лукаво, я сказал: «Ехать на VoIP? Есть ещё такая же машина и такая же ISDN плата для устрашения врага? Да нефик делать!» И всё заверте.

Так как Trixbox — это FreePBX, то и поднимать на новом месте решил тоже FreePBX — привычный заказчику функционал проще переносить. Ставил на Ubuntu 14.04LTS по мануалу с FreePBX'ного сайта, то есть asterisk, dahdi и libpri собирал из исходников. Ну, собралось, взлетаем!

Взлетели. Астериск работает, морда управляет. Хозяин, ставь свою плату! Поставили плату, и привет. Плата не видна в астериске: pri show spans ничего не выводит. Пошёл читать интернетов. Оказывается, плате в обед сто лет, когда-то, давным-давно, её поддерживал zaptel, потом кто-то портировал драйвера в DAHDI, но как-то патчей, совместимых с текущим DAHDI и ядром, на просторах не сохранилось. Попробовал ткнуться через mISDN — увы: та libmISDN, которая собралась, оказалась v2, у которой API не понимаемо астериском, а v1 собираться с ядром 3.19 наотрез отказалась.

Херня! — сказал я и поставил dahdi и dahdi-asterisk из репозитория убунты. «Вжик!» сказала японская лесопилка и показала, что модуль платы теперь загружен тот самый, который нужно (zaphfc, а не hfcpci, который идёт со штатным ядром, но не нравится DAHDI ни в какую). Более того, в морде FreePBX'а показалась некая интерфейсина, которую можно было сконфигурировать. Правда, после поступления первого же входящего звонка консоль астериска заполнилась бегущими сообщениями про short write и invalid argument.

Херня! — сказал я и снёс поставленный из исходников астериск и поставил штатный из репы и старенький FreePBX. Но не тут-то было. Сообщения не исчезали, звонки не шли.

В результате после многочасовой долбёжки выяснилось, что dahdi, идущий в штатном комплекте убунты 14.04 LTS, несовместим с ядром 3.16 (и позднее), также идущими в штатном комплекте убунты 14.04 LTS в части поддержки этой самой HFC BRI. После даунгрейда ядра на 3.13-lowlatency (есть в репозитории) проблемы с канальной частью разрешились практически полностью. Мелочи вроде непонимания телефонной компанией набираемых номеров, если pridialplan установлен в national, а не в unknown — это уже сущие мелочи.

Итого рабочая конфигурация:
  • Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (vendor id 1397, device id 2bd0, 1397:2bd0 (that's for google));
  • Ядро 3.13.0-77-lowlatency #121-Ubuntu SMP PREEMPT
  • Asterisk 11.7.0~dfsg-1ubuntu1
  • DAHDI 2.7.0-1ubuntu1
  • asterisk-dahdi 11.7.0~dfsg-1ubuntu1
  • dahdi-dkms 2.5.0.1+dfsg-1ubuntu4~14.04.4
  • FreePBX 2.11 с сайта freepbx.org обновлён на месте.
  • NT: неизвестен.

Конфиги DAHDI и chan_dahdi.conf приводить не буду, их FreePBX регулярно перерисовывает, да и сильно зависят они от телефонной компании.

8 нояб. 2015 г.

Некоторые мысли по поводу стриминга видео своими силами

Идея сделать кормушку для птиц зрела давно. Года три.

Кормушку хотелось не в виде домика. Домик — это всегда одна и та же картина: четыре голубиных жопы, торчащих из него со всех четырёх сторон, а через пять минут — пусто. С другой стороны, построение футуристичных высокотехнологичных хавкоконвейеров с доставкой очередной порции пневмопочтой явно упиралось в осознание радиуса кривизны собственных рук.

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

Но, как оказалось, сделать кормушку — это только начало большого пути. Потому что в реальность вместо созерцания пасторали выглядела так: пришёл вечером с работы — давно темно — засыпал в бутылку семечки — повесил за окно — утром встал и ушёл на работу затемно. А птицы — ВНЕЗАПНО — ночью не летают!

Тема потокового видео была в целом неизвестна. Зато имелась USB-вебкамера с заявленным разрешением аж 720p и желание поглядеть вблизи на всяких дятлов. Почитал интернет, оказалось, что инструмент вещания существует, и это, хы-хы, опять ffmpeg, в комплекте которого для подобных дел есть ffserver.

Связка ffserver+ffmpeg работает следующим образом: ffmpeg берёт поток с источника (в моём случае с вебкамеры), перекодирует его и отдаёт перекодированный поток ffserver'у, который может находиться (и, в моём случае, находится) хоть на другой стороне Интернета. ffserver дальше полученный поток раздаёт клиентам. Между ffmpeg и ffserver данные всегда передаются в единственном экземпляре. Параметры кодирования видео определяются на ffserver'е. ffmpeg'у при работе с сервером в командной строке передаются только параметры, касающиеся вебкамеры, всё остальное он получает от сервера в начале работы.

Дальше два вечера ушло на понимание того, почему поток «заедает» и выбор оптимального сочетания кодеков и контейнеров. Здесь засада, потому что такового нет:
  • H.264 в MP4 контейнере не умеет live streaming (по крайней мере, ffserver'ом). Какие-то засады с требованием наличия возможности позиционирования по MP4 потоку, которое, понятно, невозможно в случае живого вещания. То есть отпадает.
  • H.264 невозможен ни в каком другом из контейнеров, допустимых для HTML5 тэга <video>
  • В WebM контейнере возможен только VP8/VP9 кодек. Кодирование в VP8 при сопоставимом уровне качества жрёт CPU в три раза больше, чем libx264, и создаёт поток в два с половиной раза больше. То есть отпадает из-за ограничений по процессору, каналу и хостингу.
  • Остался OGM контейнер с Theora в качестве видеокодека. Даже не пробовал. То есть отпадает.
Вот и получилось, что все нативные методы отображения видео в браузере на сей день для меня неприменимы. Что остаётся? Правильно, флэш + H.264 + FLV контейнер. Со всеми вытекающими в виде невозможности нормально смотреть на телефонах и необходимости дальнейшей некрофилии с flash-плагинами в браузерах.
 
Решений пока вижу два: первое моё — вещать во флэш с указанием ссылки, по которой идёт поток и которую можно просмотреть с помощью отдельного видеоплеера (VLC, mplayer, MX player, KMplayer и т.п.) — второе правильное — таки добить VP8 кодирование и WebM контейнер, чтобы он генерировал приемлемый по битрейту поток и не грел процессор как бешеный.

А, да. Результаты всего этого дела сейчас доступны (похоже, временно, и скоро придётся ехать на нормальный хостинг) по ссылке: Кормушка для птиц (живое видео)

Пояснения на тему "Ну ты лошара, кто ж так делает стриминг, надо вот так жы!" приветствуются. Только исходите пожалуйста из того, что поток должен быть ограничен 300 kbit/s при разрешении 640×360 и делаться под линуксом бесплатными инструментами.


Appendix A: текущие настройки потока.
 <Stream test.flv>
    Feed feed.ffm
    Format flv
    VideoCodec libx264
    VideoFrameRate 20
    VideoBitRate 600
    VideoSize 640x360
    AVOptionVideo crf 28
    AVOptionVideo preset medium
    AVOptionVideo me_range 16
    AVOptionVideo qdiff 4
    AVOptionVideo qmin 10
    AVOptionVideo qmax 51
    AVOptionVideo keyint_min 15
    AVOptionVideo bf 6
    PixelFormat yuv420p
    AVOptionVideo flags +global_header
    PreRoll 10
    Noaudio
    StartSendOnKey
</Stream>