Введение: Почему в 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. Мы решили автоматизировать всё, что только можно:
Мы написали инсталлятор на bash (и деинсталлятор тоже) который сам после клонирование репо и его запуска все нужные файлы положит в /opt, сделает алиасы, конфиги и.т.д.
Портативный AppImage: Чтобы полностью отвязаться от проблем с разными версиями библиотек в системе, я упаковал весь проект в единый AppImage-пакет. Сделали специальный bash-скрипт для автоматической сборки и добавили кастомный wrapper для
ffmpeg. Теперь пользователю достаточно скачать один файл, выдать ему права на запуск и всё работает из коробки почти в любом окружении.
Заключение: Из костыля в PyPI-пакет
То, что начиналось в мае 2026 года как крик души на Реддите и злой скрипт, написанный от обиды на существующий софт, сегодня превратилось в полноценный проект.
За чуть больше чем месяц программа научилась:
обнаруживать Miracast-приёмники,
Выполнять полноценное RTSP-рукопожатие
Что самое главное в отличие от заброшенного MiracleCast, мой проект умеет работать параллельно с обычным 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://fluxcast.secweb.cloud/
Исходный код проекта: https://github.com/IlyaP358/fluxcast
Пакет в AUR: https://aur.archlinux.org/packages/fluxcast-git
Мы на ArchWiki: https://wiki.archlinux.org/title/List_of_applications/Multimedia#Miracast
Комментарии (44)
Mingun
13.06.2026 20:19А как фиксируете уже исправленные ошибки? Чтобы переписывая, не внести их вновь, тестироваться то не на чем.
IlyaP358 Автор
13.06.2026 20:19Так как тестового стенда из десятка ТВ у меня нет, спасают три вещи:
Изоляция фиксов: Код для конкретных брендов (например, LG или адаптера Microsoft) я пишу отдельно, чтобы он не ломал общую логику для других устройств.
Тесты на своём ТВ: После каждого крупного изменения я обязательно проверяю работу всех оболочек (KDE, GNOME, Hyprland) на своём телевизоре. Если база работает у меня значит, фундамент не сломан.
Помощь тестеров: Перед тем как вливать фикс в основную ветку, я скидываю код пользователю, который нашёл баг. Пока он не подтвердит, что всё ок, изменения в прод не идут.
Mingun
13.06.2026 20:19Это-то понятно. но что делать, когда у пользователей проблемы решены, они больше к вам на трекер не заглядывают, а вы решите переписать приложение под новую архитектуру? Как мне кажется, стоит сделать запись всего сетевого взаимодействия, чтобы потом гонять на CI эти реплеи. Хотя бы без таймингов, но с порядком сообщений.
IlyaP358 Автор
13.06.2026 20:19Идея с записью сетевых дампов и их прогоном через CI это на самом деле отличный, очень взрослый подход к тестированию сетевых протоколов. Для больших распределенных систем это буквально единственный способ не сломать совместимость со старыми железками.
На текущем этапе FluxCast до такой масштабной смены архитектуры еще не дорос, да и поддержка полноценного тестового стенда с моками сетевого трафика в одиночку отнимет больше времени, чем написание самого кода.
Но вы правы, если проект продолжит расти и возникнет необходимость в глубоком рефакторинге сетевой логики, сбор дампов от пользователей и написание юнит-тестов на их основе это первое, чем придется заняться. Зафиксировал эту мысль себе на будущее, спасибо за дельный совет!
janvarev
13.06.2026 20:19Огонь, конечно. Как разработчик опенсорс голосового помощника Ирины, желаю вам не выгореть от общения с пользователями (серьезно: в 17 лет и в первые 3 месяца проекта все баги править норм, но позже уже тяжелее - особенно когда проекту года 2)
Ну и звездочку добавил: обидно - проект сложный, а лайков мало :)
IlyaP358 Автор
13.06.2026 20:19Большое спасибо за поддержку и за звёздочку! Про выгорание и общение с пользователями это, наверное, главный страх любого опенсорс-разработчика xD, когда спадает первая волна эйфории. Буду стараться выстраивать процессы так, чтобы проект двигался за счет комьюнити, а не только на моем личном энтузиазме. Вам тоже успехов с вашими проектами!
yursdan
13.06.2026 20:19Хороший пример проекта под насущную потребность, как говорится, "неистово плюсую"!
Главное - не терять momentum и собрать группу единомышленников, чтобы проект не "выдохся".
и через wf-recorder в Hyprland, Sway и других Wayland-композиторах
Кстати, как в wayland-композиторах сейчас обстоят дела с сокрытием приватного содержимого или окон? Есть способ добиться того, чтобы screencast случайно не показал в телевизор терминальное окно, или IDE, где может появляться sensitive информация? А то телевизоры нынче пошли "умные" и не всегда они работают на владельца.
IlyaP358 Автор
13.06.2026 20:19Спасибо! Вопрос про приватность в Wayland сейчас действительно актуальный и важный.
На данный момент FluxCast работает на уровне захвата вывода конкретного экрана, поэтому изолировать и стримить только одно отдельное окно приложения (например, чисто браузер) стандартным способом пока не получится в телевизор улетит всё, что происходит на выбранном мониторе. =[
В будущем я бы хотел реализовать чистый стрим отдельных окон, а пока единственное рабочее решение это виртуальные headless-мониторы. Они отлично создаются в KDE/GNOME, но на тайлинговых WM всё не так гладко. Мы как раз месяц назад пытались расковырять этот кейс под Hyprland в одном из issue на гитхабе. Как выяснилось в ходе тестов, это апстрим-баг самого Hyprland, который перестаёт рендерить кадры на виртуальный вывод.
Если это все таки заработает то на физическом мониторе ноутбука вы можете спокойно открывать IDE, мессенджеры и sensitive информацию, а на телевизор будет транслироваться только чистая картинка с изолированного виртуального экрана.
eri
13.06.2026 20:19Вы тут начали про xdg-desktop-portal:
если запукскаете через (не смотрел ваш код) org.freedesktop.portal.ScreenCast то там можно выбрать только окно вместо монитора. gstreamer легко положит это окно на черный холст под разрешение телевизора.
Посмотрите ещё на org.freedesktop.portal.RemoteDesktop - это обертка над portal.ScreenCast там можно получить управление - некоторые телевизры с пульта шлют обратную связь
denis_iii
13.06.2026 20:19Проприетарный (закрытый) софт всегда борьба меча и щита. Возможно, проще сразу hdmi донгл с андроидом взять от 1.5т.р. и кастить mkv в плеер без перекодировки, особенно, если все лежит на NAS.
IlyaP358 Автор
13.06.2026 20:19С практической точки зрения вы правы, донгл или Mi Box решают проблему. Но ведь Linux это в принципе история не про "купить готовое", а про контроль над своим железом и экосистемой.
Мне было банально интересно разобраться, почему протокол, который работает пашет, спотыкается на Linux, и решить эту задачу программно. Плюс, FluxCast это не только про mkv-видео, а про полноценный шеринг экрана в реальном времени (презентации, код, браузер), где просто "кинуть файл в плеер" не сработает
denis_iii
13.06.2026 20:19Вы точно также можете кастить экран, как видеопоток в mp4 или ts беря его из обрезанного фрейм-буфера как картинку. Кто-то даже X11 писал на js в браузере для случаев простых приложений, типа часов.
Разрабы телеков специально все заворачивают на свои сервисы, если получится - Ок. Но как вы уже заметили, у всех свои нюансы, и универсальное решение сделать не просто.
xakep666
13.06.2026 20:19А не тестировали https://github.com/alexballas/go2tv? Кажется, что он решает ту же проблему, но при этом написан на go и распространяется в виде 1 файла с опциональной зависимостью от ffmpeg.
IlyaP358 Автор
13.06.2026 20:19Про go2tv знаю, отличный проект! Но у нас принципиально разные задачи.
go2tv это утилита для каста медиа-файлов (видео, аудио) или статических URL по протоколу DLNA/UPnP. Она не умеет захватывать твой рабочий стол "на лету" с Wayland/X11, кодировать движения мыши в реальном времени и передавать это как стрим по RTSP на Miracast-приёмник. FluxCast создавался именно для полноценного зеркалирования экрана (Screen Mirroring) с минимальной задержкой, а не для трансляции готовых файлов
Hyperplasia
13.06.2026 20:19Сделал бы кто-нибудь ещё rdp адекватный под linux с поддержкой wayland)) Пол года не могу добиться адекватной работы... Вроде бы для разработчиков фича must have, но решений нет...
naim
13.06.2026 20:19https://userbase.kde.org/Krfb приходится сидеть на kde
Hyperplasia
13.06.2026 20:19Там тоже всё печально с 4к и с масштабированием.
naim
13.06.2026 20:19таких проблем не наблюдаю ,а масштабирование клиентским софтом ardp . Ubuntu 26 lts
eri
13.06.2026 20:19gnome-remote-desktop работает приемлимо. режим шадоу и даже хэдлес. но только гном.
naim
13.06.2026 20:19а какой gnome и какой дистр ?
и есть ли unattended access и типо этой проблемы решения https://github.com/rustdesk/rustdesk/discussions/10016#discussioncomment-16705103 ?eri
13.06.2026 20:19я сейчас работаю на gnome 48 debian 13; 43,44 норм.
unattended по паролю, но в трее под вайлендом висит кнопка отключения сессии.
в недрах dconf есть переключатель какой монитор использовать или создавать виртуальный.eri
13.06.2026 20:19на некоторых версиях не подключается если экран заблокирован. можно разблокировать по ssh через loginctl
Lizdroz
13.06.2026 20:19Отличный пример того, как личная боль превращается в крутой опенсорсный продукт!)
Dionisiy_eshe
13.06.2026 20:19Мое почтение. Сложилось убеждение из выжимки чтения форумов, что вейланд проект по удушению Линукс.
IlyaP358 Автор
13.06.2026 20:19Ребята, я в шоке! Вчера вечером на гитхабе было еще 60 звёзд, а сейчас там уже 90! Спасибо огромное каждому за поддержку и фидбэк в комментариях, для меня это нереальная мотивация развивать проект дальше!
eri
13.06.2026 20:1910 лет назад занимался этим же..) дошел до стрима в андроид приёмник, но самсунг не осилил....
mydigitalhabb
13.06.2026 20:19Рекомендуется в таких случаях открывать сбор донатов, и на эти деньги жить, работать, и покупать эти железки для тестов. Например "для покупки Microsoft 4K Wireless Display Adapter и исправления бага донатьте $5k, кому нужно".
Даже через тот же международный donationalerts.
IlyaP358 Автор
13.06.2026 20:19На самом деле идея с целевым сбором под конкретные железки звучит очень здраво, потому что скупить весь зоопарк смарт-ТВ и свистков для тестов в одиночку просто невозможно. Попробую добавить ссылки на краудфандинг в readme репозитория, возможно, действительно соберём на пару тестовых адаптеров, которые чаще всего просят в комментариях. Спасибо!
kujoro
13.06.2026 20:19в сизифе не будет?
IlyaP358 Автор
13.06.2026 20:19Сам я ALT Linux не пользуюсь, поэтому собрать и поддерживать пакет для Сизифа мне будет сложновато. Но проект полностью открытый под лицензией GPL-3.0, и я только за! Если среди майнтейнеров АЛЬТа найдётся тот, кто захочет забрать FluxCast к себе в Сизиф я буду очень рад и готов помочь со своей стороны, если возникнут вопросы по зависимостям.
IlyaP358 Автор
13.06.2026 20:19Ребята, вы невероятные! Проект FluxCast только что пробил 130 звёзд на GitHub! Спасибо вам огромнейшее за такую поддержку.
Только что я выпустил официальный пакет в Pypi! Также выкатил свежий релиз v0.1.1, где пофиксил первый краш на адаптере от Microsoft и добавил в TODO идею с целевым краудфандингом для покупки тестового железа. Работаем дальше!
Shtoka
Классный проект, но писать вещи требующие real-time на питоне это просто извращение, как и писать утилиты не нем же или на любом другом не компилирующем языке.
Честно говоря, я перестал устанавливать питон пакеты на свой комп кроме каких то супер исключительных случаев, в которых не получается выручить без него.
IlyaP358 Автор
Привет! Отчасти я с вами соглашусь но на самом деле писать захват экрана и кодирование потока с нуля на чистом Python было бы максимально глупо и неэффективно, от такой нагрузки CPU бы просто поплавился.
Я просто не стал изобретать велосипед: всю тяжёлую и грязную работу (захват экрана, работу с аудио, кодирование видео) за меня делают проверенные утилиты вроде
ffmpegи пайплайныGStreamer, которые изначально написаны на C/C++.Python в моём проекте выступает исключительно как послушный и гибкий "клей", который управляет этими процессами, рулит логикой сети и связывает всё воедино. Для этой задачи его производительности хватает с огромным запасом».
Lizdroz
В 90% случаев тормозит не питон, а криво написанный пайплайн в gstreamer. Если правильно прокинуть буферы, язык-обертка вообще не играет роли
IlyaP358 Автор
именно!