Це я відкрив для себе офігезний проект MediaMTX. Там в документації вже є все потрібне. Але про всяк випадок зберу докупи свої знахідки, щоб не забути.

Загальна концепція: є передавач відеопотоку, є отримувач, між ними є медіасервер. Це може бути три різних компа. Може два, якщо медіасервер запустити там же, де й передавач. Для перших експериментів, нехай це буде один localhost.

Моя мета: дивитися через веб-камеру на блимаючий світлодіод, ха-ха.

Запуск сервера

Запускаю MediaMTX в Docker, якось так, як описано в документації. (Звісно, замість 192.168.xx.xx вказую свою IP-адресу в локальній мережі). Це достатньо надійний варіант.

docker run --rm -it \
  -e MTX_RTSPTRANSPORTS=tcp \
  -e MTX_WEBRTCADDITIONALHOSTS=192.168.xx.xx \
  -p 8554:8554 \
  -p 1935:1935 \
  -p 8888:8888 \
  -p 8889:8889 \
  -p 8890:8890/udp \
  -p 8189:8189/udp \
  bluenviron/mediamtx:1

Або, якщо можу собі дозволити, то запускаю ось так:

docker run --rm -it --network=host bluenviron/mediamtx:1

Також я запускав готові бінарники MediaMTX на своїй старенькій Raspberry Pi Model 2. Ок норм.

Трансляція RTSP

Штатна документація пропонує запускати ffmpeg прямо під час запуску MediaMTX. Мені більше до смаку тримати медіасервер постійно запущеним, а трансляції розпочинати окремою командою.

Ось варіант команди, який транслює відео з веб-камери, використовуючи кодек H.264:

ffmpeg -f v4l2 -framerate 30 -video_size 640x480 -i /dev/video0 \
  -pix_fmt yuv420p -c:v libx264 -preset ultrafast -b:v 600k \
  -tune zerolatency -bf 0 -g 15 -keyint_min 30 \
  -f rtsp rtsp://localhost:8554/mystream

Або те саме з апаратним прискоренням через VAAPI:

ffmpeg -f v4l2 -framerate 30 -video_size 640x480 -i /dev/video0 \
  -c:v h264_vaapi -vaapi_device /dev/dri/renderD128 \
  -vf 'format=nv12,hwupload' -qp 24 -quality 1 -bf 0 -g 30 \
  -f rtsp rtsp://localhost:8554/mystream

Тут всюди 640×480, бо звичайні веб-камери майже ніколи не дають 30 кадрів на секунду на більших розмірах картинки. Чесно, мені для моїх задач той HD чи FullHD не дуже потрібний, а от відсутність гальм справді важлива.

Звісно, замість localhost може бути потрібна IP-адреса. Також шлях /mystream — це на ваш вибір, щоб якось вказати даний конкретний відеопотік. Через один медіасервер може одночасно йти декілька різних відеопотоків з різними шляхами.

Можна робити трансляцію з VP8, але не сьогодні, бо моя відеокарта не робе апаратне прискорення кодування саме для VP8 (ну або я не знайшов як), а софтварний енкодер жере проц. Після експериментів і роздумів, я вирішив зупинитися на H.264 як на оптимальному варіанті.

Перегляд RTSP

Ну, наприклад, можна якось так:

ffplay \
  -fflags nobuffer \
  -flags low_delay \
  -framedrop \
  -probesize 32 \
  -analyzeduration 0 \
  -sync ext \
  -rtsp_transport udp \
  rtsp://localhost:8554/mystream

Або так:

mpv rtsp://localhost:8554/mystream --profile=low-latency --untimed

Перегляд WebRTC

Просто відкриваю в браузері http://localhost:8889/mystream/ і бачу там відео. Магія!

Є певний нюанс з кодеками. Chrome/Chromium нормально грає H.264, а Firefox його грати не хоче. Треба полізти в about:config, знайти там media.webrtc.hw.h264.enabled і увімкнути його. Саме через це я експериментував з VP8, але вирішив що не на часі.

Вбудувати стрім у довільну веб-сторінку

Теж все робиться просто і зрозуміло, як в документації:

<iframe src="http://localhost:8889/mystream" scrolling="no"></iframe>

Можна додати CSS за смаком:

<iframe
 src="http://localhost:8889/mystream"
 style="border: none;
        aspect-ratio: 4 / 3;
        width: 100%;
        height: 100%;
        max-width: 100vw;
        max-height: 100vh"
 scrolling="no"></iframe>

Для дашборда Node-RED можна створити UI Template node і прямо туди це все покласти. Власне, саме задля цього я занурився у ці нетрі: дуже захотілося поєднати телеметрію та елементи керування моїх саморобних IoT проектів з живим відео. І це заслуговує окремого поста.

Додаткова краса

Коли трансляція не ведеться, можна показувати щось красиве, наприклад телевізійну тест-таблицю SMPTE чи Philips. Для цього треба з картинки зробити відео довжиною, гммм, 1 секунду.

wget https://upload.wikimedia.org/wikipedia/commons/6/66/SMPTE_Color_Bars.svg
rsvg-convert SMPTE_Color_Bars.svg -w 640 -h 480 > smpte.png
ffmpeg -loop 1 -framerate 30 -t 1 -i smpte.png -c:v libx264 -pix_fmt yuv420p smpte.mp4

Або так:

wget https://upload.wikimedia.org/wikipedia/commons/a/aa/Philips_PM5544.svg
rsvg-convert Philips_PM5544.svg -w 640 -h 480 > pm5544.png
ffmpeg -loop 1 -framerate 30 -t 1 -i pm5544.png -c:v libx264 -pix_fmt yuv420p pm5544.mp4

Власне, далі треба буде лізти в конфігураційний файл mediamtx.yml, і якщо у вас MediaMTX все ще запускається через Docker, то вам доведеться з цим розбиратися окремо.

Просто дописую в кінець таку секцію:

paths:
  mystream:
    alwaysAvailable: true
    alwaysAvailableFile: "pm5544.mp4"

Проброс портів

Якщо є бажання поділитися своєю трансляцією в WebRTC з усім світом, то треба буде десь на роутері налаштувати port forwarding:

• 8889/TCP → 192.168.xx.xx:8889
• 8189/UDP → 192.168.xx.xx:8189

Далі дивлюся трансляцію так само, тільки в якості хоста вказую реальну IP-адресу.

Відкриті питання

Треба буде розібратися з питаннями безпеки:

1. Обмежити можливість трансляції, дозволити лише «кому треба»
2. Обмежити можливість перегляду (JWT?)
3. Убезпечити транспорт WebRTC від MitM (https?)

Треба більше RTFM.

Треба всерйоз подумати, як би то його точніше виміряти затримку. Візуально бачу що вона відрізняється для різних конфігурацій, зокрема для різних кодеків і різних транспортів. Можливо, параметри запуску ffmpeg та ffplay можна ще вдосконалити.

Висновки

Маю офігенний інструмент в своєму арсеналі, от!

Сказати мені нічого. Ну тобто насправді багато чого можу сказати, але не хочу. У мене в житті останнім часом багато подій, турбулентність.

Закинув свої хобі-проекти.

Одна з останніх штук, яку я колупав заради розваги та душевного спокою, була якась «читалка» тексту на мікроскопічних екранчиках SSD1306, типу 128×32 пікселів чи щось подібне; наразі з цієї «читалки» мало що є, окрім шрифта. (Насправді це мав бути переважно апаратний проект, але якось не склалося). Є фото читалки у мене в Mastodon. Може колись я продовжу цей проект.

Колись один мій друг зробив сам для себе книжкочиталку на J2ME. Він читав усякі книжки на чорно-білих кнопкових телефонах в ті часи, коли смартфони ще не винайшли, а КПК були дорогими і незручними. Мій проект частково натхненний тим його досвідом.

По приколу пишу ці рядки через вбудовану у GitHub веб-версію VS Code, та що запускається по натисканню на кнопку . і це по-своєму прикольно.

Хоча і тупо. Я міг би без гальм і без споживання зайвого трафіку написати цей текст у Vim на найменшому зі своїх ноутів, і теж було б непогано.

Гм. Треба буде якось написати пост про економію ресурсів. Щось у цьому є таке, що складно висловити словами. Мені не важко запустити VSCode в браузері і не важко запустити його локально. Зазвичай я пишу текст і код в Geany. Але часто буваю в Vim. Чому так?

Це не тільки питання зручності. Я відчуваю, що Vim мене може врятувати, умовно кажучи, «на пустельному острові». (Або навіть не повноцінний потужний Vim, а його злий брат-близнюк busybox vi, у якого не все добре з Unicode). О, до речі, про свої експерименти з Debian-Live теж треба написати.

Колись про все це напишу.

Оновлення 12:07. Щодо економії: іноді кількість переходить в якість. Можливість досягати мети різними шляхами, в тому числі короткими і мінімалістичними, дає свободу вибору.

Одразу уточнюю: 1) не через OBS Studo, 2) не на YouTube.

Я просто хочу дивитися відео зі своєї веб-камери з мінімальною затримкою. Комп з камерою і комп для перегляду обидва знаходяться в локальній мережі. Ніякого інтерактивного GUIшного софта, тільки ffmpeg та інші scriptable консольні програми.

Раніше я знав лише один супер-простий метод, про який писав колись:

ssh -Y foohost mplayer -vo x11 tv://

(Не робіть так, це страшенні гальма + великий overhead).

Як можна зробити краще

Погнали.

В принципі у нас може бути три різних хоста: комп з камерою, комп для перегляду і проміжний хост з RTMP-сервером. В моєму випадку RTMP-сервер може бути там же, де знаходиться камера.

Сервер

Перше, що нам треба — запустити сервер RTMP. Можна зробити RTMP-сервер через Nginx та mod_rtmp. А у найпростіших випадках (і щоб погратися) достатньо взяти готовий контейнер:

docker run --rm -p 1935:1935 tiangolo/nginx-rtmp 

Йому треба лише 1935 порт.

Припустимо, що це хост з адресою 192.168.0.99, тоді адреса нашої трансляції буде rtmp://192.168.0.99/live/123 (де /live/123 це довільний обраний мною шлях).

Камера

Мені потрібна трансляція без звуку. Нехай це камера /dev/video0. Тоді на компі з камерою запускаємо таку магію, де крім /dev/video0 та адреси трансляції для початку краще нічого не чіпати:

ffmpeg -f v4l2 -i /dev/video0 -c:v libx264 \
  -pix_fmt yuv420p -framerate 15 -g 30 -b:v 500k \
  -preset ultrafast -tune zerolatency \
  -f flv rtmp://192.168.0.99/live/123

Я нагуглив перший-ліпший випадковий howto і прибрав згадки про звук. Якщо вам буде треба звук (і якщо у вас ALSA), то йдіть подивіться оригінальний пост.

Перегляд

Ну найпростіше, що можна зробити, це щось типу такого:

mplayer rtmp://192.168.0.99/live/123

Воно працює. Але ну його до біса! Затримка більше 10 секунд мені абсолютно не підходить. Ось кращий варіант:

mpv --no-cache --untimed --no-demuxer-thread \
  --video-sync=audio --vd-lavc-threads=1 \
  rtmp://192.168.0.99/live/123

або такий:

ffplay -autoexit -flags low_delay -framedrop \
  -strict experimental -vf setpts=0 -tcp_nodelay 1 \
  rtmp://192.168.0.99/live/123

І от тут, нарешті, я починаю бачити в цьому всьому профіт. Я можу дивитися в камеру+екран як в дзеркало і не відчувати затримку.

P.S. Що я не знайшов, так це нормального рішення для перегляду стріму на Android. Запускаю там VLC, воно все працює, але лаг 15 секунд (upd.: вони про це знають і їм похуй). Може хтось порадить рішення краще.

Upd.: ще я нагуглив якийсь стрьомний Larix Player, це дуже мерзенний freemium з обмеженням у 5 хвилин перегляду відео на безкоштовній версії. З того, що я спробував і що вдалося змусити працювати на burner phone, у цього додатку поки що виявився найменший лаг. Треба ще пошукати.

Так, це анахронізм часів PHP4. І так, за замовчанням кольори там розраховані на світле тло. Якщо у вас сайт з темним фоном, то можна поміняти кольори на щось відповідне, але це все трошки бісить.

А що як у нас сучасна адаптивна кольорова схема?

<meta name="color-scheme" content="light dark">

Тоді у нас взагалі не може бути фіксованих кольорів, бо має одночасно існувати і варіант для темної схеми, і варіант для світлої.

Спробував через змінні CSS. Погнали.

Пишемо в php.ini щось таке:

highlight.default = "var(--php-default)"
highlight.html = "var(--php-html)"
highlight.keyword = "var(--php-keyword)"
highlight.string = "var(--php-string)"
highlight.comment = "var(--php-comment)"

Або, якщо змінювати php.ini незручно, робимо це в runtime в PHP:

foreach (['default', 'html', 'keyword', 'string', 'comment'] as $key) {
    ini_set('highlight.' . $key, 'var(--php-' . $key . ')');
}

І тепер нам треба приблизно отакий CSS:

:root {
  --php-comment: #f80;
  --php-default: #00b;
  --php-html: #000;
  --php-keyword: #070;
  --php-string: #d00;
}

@media (prefers-color-scheme: dark) { 
  :root {
    --php-comment: #860;
    --php-default: #66f;
    --php-html: #ccc;
    --php-keyword: #0f3;
    --php-string: #fc0;
  }
}

Всьо, пофарбували, порядок :)

Вбудований світлодіод Raspberry Pi Pico світиться, якщо подати на відповідний GPIO високий рівень сигналу, і не світиться якщо встановити низький рівень сигналу. Поведінка ESP8266 протилежна: високий рівень сигналу там вимикає світлодіод.

Тобто, клас BlinkingLED з попередьного посту в режимі «не блимати» має різну поведінку на Raspberry Pi Pico та ESP8266: для RP2 вимикання режиму блимання робить світлодіод неактивним, а для ESP8266 вимикання режиму блимання врубає світлодіод на повну. (В режимі «блимати» вони все ж виглядають однаково). Тож треба з цим щось зробити, чи не так?

Окей, давайте і тут зробимо щось сумнівне…

class InvertedPinOut:
    def __init__(self, pin):
        self.pin = pin

    def value(self, new_value):
        self.pin.value(1 - new_value)

Об’єкт цього класу можна передавати в BlinkingLED замість machine.Pin. Норм чи крінж?

Альтернативно, ми можемо додати в клас BlinkingLED властивість is_inverted і додаткову логіку:

     async def main(self):
         while True:
-            self.pin.value(int(self.blinking))
+            self.pin.value(int(self.blinking ^ self.is_inverted))
             await asyncio.sleep_ms(500)
-            self.pin.value(0)
+            self.pin.value(int(self.is_inverted)
             await asyncio.sleep_ms(500)

Це скоріше крінж.

Або так: зробити в класі властивості value_on та value_off (за замовчанням (для звичайних світлодіоів), значення 1 та 0, відповідно). Ще довше, але у певному сенсі наочніше.

     async def main(self):
         while True:
-            self.pin.value(int(self.blinking))
+            self.pin.value(self.value_on if self.blinking else self.value_off)
             await asyncio.sleep_ms(500)
-            self.pin.value(0)
+            self.pin.value(self.value_off)
             await asyncio.sleep_ms(500)

Зовсім крінж. Як же краще?

Увага, правильна відповідь, щойно випадково знайдена в документації: можна використати вже наявний в стандартній бібліотеці клас machine.Signal:

led = machine.Signal(machine.Pin(2, machine.Pin.OUT), invert=True)

Яка проста і прикольна штука!