SavePearlHarbor

Как я написал свой клиент Miracast для шаринга экрана под Linux в 2026 году и погряз в войне за проприетарные байты

—

от автора

admin

Введение: Почему в 2026 году это всё ещё боль?

Меня зовут Илья, мне 17 лет и всё началось с банального желания. У меня есть рабочий сетап на Arch Linux + Hyprland, диван и новенький телевизор Samsung на стене. Мне хотелось простого человеческого действия, это запустить фильм или открыть браузер на большом экране без необходимости тянуть через всю комнату чёртов HDMI-кабель.

В Windows 10/11 это делается в два клика: нажал Win + K, выбрал ТВ, готово. Как это выглядит в современном Linux? Ну… примерно как сборка космического корабля из говна и палок.

Я честно пошел в интернет и написал на Reddit:

«Why is casting your screen to a TV on Linux still this hard in 2026?» Я попытался поставить gnome-network-displays и miraclecast. Мой ТВ даже не увидел. Окей, погуглил, запустил демона avahi. Телевизор наконец-то нашёлся! Нажимаю подключиться… получаю ровно один статичный кадр на экране ТВ, после чего весь экран намертво замерзает.

Пост внезапно собрал кучу апвоутов и волну сочувствия в комментариях. В этот момент у любого линуксоида внутри щёлкает тумблер: «Хочешь сделать хорошо — сделай это сам». Я решил ради шутки и фана написать за пару вечеров свою легковесную CLI-утилиту на Python с минимальным количеством зависимостей и даже не пытался реализовывать настоящий Miracast а лишь обычный DLNA.

Так родился проект FluxCast. Но я ещё не знал, в какой ад низкоуровневой отладки это меня затянет.

Акт I: Эйфория первого запуска

План был простой как три копейки: берем ffmpeg для захвата экрана, докидываем стандартные библиотеки Python (вроде http.server) и склеиваем это в один скрипт.

Хронология моих первых коммитов со стороны выглядит как биполярное расстройство разработчика:

  • 2 мая: Скелет готов. Код ужасен, но он пытается что-то стримить.

  • 3 мая: Исторический момент. Видео пошло на экран, звук заиграл! Но радость была недолгой. Задержка между действием на мониторе и картинкой на ТВ составляла… около 20 секунд из за ограничений протокола DLNA и его буферизации. Смотреть так видео или, не дай бог, презентации просто нереально. Я оставляю в следующем коммите оптимистичный комментарий: fix_audio:TODO_fix_delay_ =] и ухожу курить мануалы.

  • 4 мая: Есть контакт! Я закопался глубже в стандарты Wi-Fi Direct, выкинул лишние промежуточные прослойки и переписал трансляцию напрямую через RTSP/RTP пайплайны GStreamer. Задержка упала почти до нуля. Картинка плавная, мышка не отстает. Победа? Если бы…

Акт II: Добро пожаловать в зоопарк Smart TV

Как только твой скрипт начинает работать на твоем личном телевизоре, тебе кажется, что ты покорил мир. Но как только проект вылезает из недр GitHub, к тебе приходят они, другие пользователи. И от них ты узнаешь, что оказывается каждый производитель железа срать хотел на единые стандарты Miracast.

  • Телевизоры LG и эпоха пингов (7-13 мая): Прибегают владельцы LG WebOS. У них FluxCast отваливается ровно через 10 секунд после старта. Почему? Оказывается, капризные корейские телевизоры требуют регулярных пустых RTCP keep-alive пакетов и ограниченного стабильного битрейта. Если их нет, ТВ закрывает сессию. За 4-5 дней мы отлаживаем эту проблему с первыми тестерами.

  • Samsung 2024+: Новые телевизоры Samsung стали строже относиться к протоколам безопасности. Из-за бага в коде программа FluxCast сообщала телевизору, что поддерживает защиту контента. Телевизор ждал подтверждения шифрования, не получал его и через 11 секунд разрывал соединение. Кроме того, телевизор ждал, что компьютер сам запустит видеотрансляцию, а программа в это время ждала действий от телевизора.

  • Проблема с артефактами (KDE/GNOME): При трансляции экрана на статичной картинке появлялись небольшие визуальные артефакты (сраные пульсирующие кубики). Попытка включить умное обновление кадров (intra-refresh) убирала артефакты, но намертво вешала стрим через полторы минуты, а мой костыль с перезапуском потока приводил к черному экрану на телевизорах LG. Пришлось временно откатить эти фиксы, чтобы вернуть стабильность. Война с артефактами продолжается и по сей день и висит в открытом issue.

К концу мая проект внезапно “повзрослел”. Я добавил симпатичный системный трей используя библиотеку pystray, чтобы уйти от чистого терминала, и настроили полноценную работу через xdg-desktop-portal — теперь захват экрана работал на любом Wayland-композиторе из коробки.

А потом случилось то, чего я вообще не ожидал. Энтузиаст под ником alba4k залетает в репозиторий, наводит там порядок, создает и по сей день поддерживает пакет в AUR и… пробивает FluxCast на официальную ArchWiki в раздел Miracast софтверного каталога мультимедиа! Мой проект теперь стоит на главной вики линуксоидов рядом с официальным софтом от GNOME.

Акт III: Отладка черного ящика и война за портативность

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

Пользователь SebSch182 решил запустить Fluxcast через фирменный адаптер Microsoft 4K Wireless Display Adapter.

Эта проприетарная железка наотрез отказывалась принимать стандартный видеопоток на 3-м уровне RTSP рукопожатия и аудиопоток, который выдавал GStreamer. Соединение просто рвалось в ту же секунду. Пришлось копать спецификации Intel WiDi и смежных стандартов стриминга. Выяснилось, что адаптер требует жестко фиксированный формат аудиопакетов (LPCM со специфическими заголовками) и дико чувствителен к микроскопическим задержкам таймингов.

Я сажусь писать свой собственный кастомный мультиплексор аудио на Python прямо внутри проекта. Запушил, жду.

  • Видео работает! но обрывается.

  • Исключаю keepalive пакеты конкретно для него чтобы адаптер не ругался.

  • Видео работает и не обрывается! Но звука нет.

  • Делаю свобственный мультиплексор на Python попутно изучив библиотеку gc чтобы выжать из питоновской скорости максимум.

  • Фидбек от тестера: «Оно работает! Но звук ужасен, как будто из консервной банки».

Началась недельная игра в угадайку. У меня на столе этого адаптера нет. Мы гоняем коммиты туда-сюда. Я перевожу звук в Little-Endian (S16LE) — тестер пишет: «Стало ещё хуже, один белый шум и шипение». Возвращаю обратно.

Борьба с Майкрософт также длится до сих пор. Чтобы окончательно убедиться в теории, я скидываю тестеру ссылку на YouTube с чистой синусоидой, тест-тоном на 440 Гц. Когда ты тестируешь музыку, искажения понять сложно, а на чистом тоне сразу слышно характер деградации звука. Посмотрим чем завершится эта история но этот blind-дебаг стал для меня настоящим инженерным тренажёром.

Параллельно с дебагом железа всплыла другая проблема. Python-скрипт это круто, но заставлять обычного пользователя клонировать репо, вручную ставить кучу системных зависимостей, ставить иконки для приложения, алиасы и вручную пихать в системные папки конфиг для wpa_supplicant — это верный способ растерять всю аудиторию. Софт должен запускаться в один клик.

На этом этапе к разработке активно подключился alba4k. Мы решили автоматизировать всё, что только можно:

  1. Мы написали инсталлятор на bash (и деинсталлятор тоже) который сам после клонирование репо и его запуска все нужные файлы положит в /opt, сделает алиасы, конфиги и.т.д.

  2. Портативный AppImage: Чтобы полностью отвязаться от проблем с разными версиями библиотек в системе, я упаковал весь проект в единый AppImage-пакет. Сделали специальный bash-скрипт для автоматической сборки и добавили кастомный wrapper для ffmpeg. Теперь пользователю достаточно скачать один файл, выдать ему права на запуск и всё работает из коробки почти в любом окружении.

Заключение: Из костыля в PyPI-пакет

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

За чуть больше чем месяц программа научилась:

  • обнаруживать Miracast-приёмники,

  • Выполнять полноценное RTSP-рукопожатие

  • Что самое главное в отличие от заброшенного работать параллельно с обычным Wi-Fi соединением на почти всех адаптерах с поддержкой MCC (Multi-Channel Concurrent).

  • захватывать экран через xdg-desktop-portal в KDE и GNOME, через x11grab на X11 и через wf-recorder в Hyprland, Sway и других Wayland-композиторах,

  • автоматически подбирать параметры стрима для разных телевизоров,

  • поддерживать LG WebOS, Samsung, TCL телевизоры и даже были отчеты об успешной работе на проекторах и хоть как то частично работать с Microsoft Wireless Display Adapter,

  • запускаться через AppImage,

  • ставиться через AUR,

Но самое главное для меня что Fluxcast собрал за столь небольшое время 60 звезд на Github тем самым получив признание и место в официальной ArchWiki и обзавёлся удобным треем как для обычных пользователей так тайлинговых менеджеров.

Сейчас я готовлю релиз для публикации на PyPI, чтобы утилиту можно было поставить на абсолютно любом Linux-дистрибутиве одной понятной командой: pip install fluxcast.

Мораль истории проста: если в Linux что-то работает не так, как вам хочется — не бойтесь лезть под капот! Даже если в процессе вам придётся воевать с байтами, проводить в документациях больше времени чем на улице, слать иностранцам синусоиды на 440 Гц и писать системные скрипты сборки вместо сна. Оно того стоит. Это именно тот опыт который я так хотел получить от Open-source разработки.

Если кто-то заинтересовался проектом или хотел бы помочь. Все ссылки здесь.

ссылка на оригинал статьи https://habr.com/ru/articles/1047186/