Comments 47
Классный проект, но писать вещи требующие real-time на питоне это просто извращение, как и писать утилиты не нем же или на любом другом не компилирующем языке.
Честно говоря, я перестал устанавливать питон пакеты на свой комп кроме каких то супер исключительных случаев, в которых не получается выручить без него.
Привет! Отчасти я с вами соглашусь но на самом деле писать захват экрана и кодирование потока с нуля на чистом Python было бы максимально глупо и неэффективно, от такой нагрузки CPU бы просто поплавился.
Я просто не стал изобретать велосипед: всю тяжёлую и грязную работу (захват экрана, работу с аудио, кодирование видео) за меня делают проверенные утилиты вроде ffmpeg и пайплайны GStreamer, которые изначально написаны на C/C++.
Python в моём проекте выступает исключительно как послушный и гибкий "клей", который управляет этими процессами, рулит логикой сети и связывает всё воедино. Для этой задачи его производительности хватает с огромным запасом».
В 90% случаев тормозит не питон, а криво написанный пайплайн в gstreamer. Если правильно прокинуть буферы, язык-обертка вообще не играет роли
А как фиксируете уже исправленные ошибки? Чтобы переписывая, не внести их вновь, тестироваться то не на чем.
Так как тестового стенда из десятка ТВ у меня нет, спасают три вещи:
Изоляция фиксов: Код для конкретных брендов (например, LG или адаптера Microsoft) я пишу отдельно, чтобы он не ломал общую логику для других устройств.
Тесты на своём ТВ: После каждого крупного изменения я обязательно проверяю работу всех оболочек (KDE, GNOME, Hyprland) на своём телевизоре. Если база работает у меня значит, фундамент не сломан.
Помощь тестеров: Перед тем как вливать фикс в основную ветку, я скидываю код пользователю, который нашёл баг. Пока он не подтвердит, что всё ок, изменения в прод не идут.
Это-то понятно. но что делать, когда у пользователей проблемы решены, они больше к вам на трекер не заглядывают, а вы решите переписать приложение под новую архитектуру? Как мне кажется, стоит сделать запись всего сетевого взаимодействия, чтобы потом гонять на CI эти реплеи. Хотя бы без таймингов, но с порядком сообщений.
Идея с записью сетевых дампов и их прогоном через CI это на самом деле отличный, очень взрослый подход к тестированию сетевых протоколов. Для больших распределенных систем это буквально единственный способ не сломать совместимость со старыми железками.
На текущем этапе FluxCast до такой масштабной смены архитектуры еще не дорос, да и поддержка полноценного тестового стенда с моками сетевого трафика в одиночку отнимет больше времени, чем написание самого кода.
Но вы правы, если проект продолжит расти и возникнет необходимость в глубоком рефакторинге сетевой логики, сбор дампов от пользователей и написание юнит-тестов на их основе это первое, чем придется заняться. Зафиксировал эту мысль себе на будущее, спасибо за дельный совет!
Огонь, конечно. Как разработчик опенсорс голосового помощника Ирины, желаю вам не выгореть от общения с пользователями (серьезно: в 17 лет и в первые 3 месяца проекта все баги править норм, но позже уже тяжелее - особенно когда проекту года 2)
Ну и звездочку добавил: обидно - проект сложный, а лайков мало :)
Большое спасибо за поддержку и за звёздочку! Про выгорание и общение с пользователями это, наверное, главный страх любого опенсорс-разработчика xD, когда спадает первая волна эйфории. Буду стараться выстраивать процессы так, чтобы проект двигался за счет комьюнити, а не только на моем личном энтузиазме. Вам тоже успехов с вашими проектами!
Хороший пример проекта под насущную потребность, как говорится, "неистово плюсую"!
Главное - не терять momentum и собрать группу единомышленников, чтобы проект не "выдохся".
и через wf-recorder в Hyprland, Sway и других Wayland-композиторах
Кстати, как в wayland-композиторах сейчас обстоят дела с сокрытием приватного содержимого или окон? Есть способ добиться того, чтобы screencast случайно не показал в телевизор терминальное окно, или IDE, где может появляться sensitive информация? А то телевизоры нынче пошли "умные" и не всегда они работают на владельца.
Спасибо! Вопрос про приватность в Wayland сейчас действительно актуальный и важный.
На данный момент FluxCast работает на уровне захвата вывода конкретного экрана, поэтому изолировать и стримить только одно отдельное окно приложения (например, чисто браузер) стандартным способом пока не получится в телевизор улетит всё, что происходит на выбранном мониторе. =[
В будущем я бы хотел реализовать чистый стрим отдельных окон, а пока единственное рабочее решение это виртуальные headless-мониторы. Они отлично создаются в KDE/GNOME, но на тайлинговых WM всё не так гладко. Мы как раз месяц назад пытались расковырять этот кейс под Hyprland в одном из issue на гитхабе. Как выяснилось в ходе тестов, это апстрим-баг самого Hyprland, который перестаёт рендерить кадры на виртуальный вывод.
Если это все таки заработает то на физическом мониторе ноутбука вы можете спокойно открывать IDE, мессенджеры и sensitive информацию, а на телевизор будет транслироваться только чистая картинка с изолированного виртуального экрана.
Вы тут начали про xdg-desktop-portal:
если запукскаете через (не смотрел ваш код) org.freedesktop.portal.ScreenCast то там можно выбрать только окно вместо монитора. gstreamer легко положит это окно на черный холст под разрешение телевизора.
Посмотрите ещё на org.freedesktop.portal.RemoteDesktop - это обертка над portal.ScreenCast там можно получить управление - некоторые телевизры с пульта шлют обратную связь
Проприетарный (закрытый) софт всегда борьба меча и щита. Возможно, проще сразу hdmi донгл с андроидом взять от 1.5т.р. и кастить mkv в плеер без перекодировки, особенно, если все лежит на NAS.
С практической точки зрения вы правы, донгл или Mi Box решают проблему. Но ведь Linux это в принципе история не про "купить готовое", а про контроль над своим железом и экосистемой.
Мне было банально интересно разобраться, почему протокол, который работает пашет, спотыкается на Linux, и решить эту задачу программно. Плюс, FluxCast это не только про mkv-видео, а про полноценный шеринг экрана в реальном времени (презентации, код, браузер), где просто "кинуть файл в плеер" не сработает
Вы точно также можете кастить экран, как видеопоток в mp4 или ts беря его из обрезанного фрейм-буфера как картинку. Кто-то даже X11 писал на js в браузере для случаев простых приложений, типа часов.
Разрабы телеков специально все заворачивают на свои сервисы, если получится - Ок. Но как вы уже заметили, у всех свои нюансы, и универсальное решение сделать не просто.
А не тестировали https://github.com/alexballas/go2tv? Кажется, что он решает ту же проблему, но при этом написан на go и распространяется в виде 1 файла с опциональной зависимостью от ffmpeg.
Про go2tv знаю, отличный проект! Но у нас принципиально разные задачи.
go2tv это утилита для каста медиа-файлов (видео, аудио) или статических URL по протоколу DLNA/UPnP. Она не умеет захватывать твой рабочий стол "на лету" с Wayland/X11, кодировать движения мыши в реальном времени и передавать это как стрим по RTSP на Miracast-приёмник. FluxCast создавался именно для полноценного зеркалирования экрана (Screen Mirroring) с минимальной задержкой, а не для трансляции готовых файлов
Сделал бы кто-нибудь ещё rdp адекватный под linux с поддержкой wayland)) Пол года не могу добиться адекватной работы... Вроде бы для разработчиков фича must have, но решений нет...
https://userbase.kde.org/Krfb приходится сидеть на kde
gnome-remote-desktop работает приемлимо. режим шадоу и даже хэдлес. но только гном.
а какой gnome и какой дистр ?
и есть ли unattended access и типо этой проблемы решения https://github.com/rustdesk/rustdesk/discussions/10016#discussioncomment-16705103 ?
Ну в гноме не тру РДП. оно подключается в текущий сеанс -то бишь если рядом с монитором кто-то есть - он всё видит, что не очень красиво\безопасно
Отличный пример того, как личная боль превращается в крутой опенсорсный продукт!)
Мое почтение. Сложилось убеждение из выжимки чтения форумов, что вейланд проект по удушению Линукс.
Ребята, я в шоке! Вчера вечером на гитхабе было еще 60 звёзд, а сейчас там уже 90! Спасибо огромное каждому за поддержку и фидбэк в комментариях, для меня это нереальная мотивация развивать проект дальше!
10 лет назад занимался этим же..) дошел до стрима в андроид приёмник, но самсунг не осилил....
Зарегай PyPI пока никто не засквотил название. Хоть пустым релизом.
Рекомендуется в таких случаях открывать сбор донатов, и на эти деньги жить, работать, и покупать эти железки для тестов. Например "для покупки Microsoft 4K Wireless Display Adapter и исправления бага донатьте $5k, кому нужно".
Даже через тот же международный donationalerts.
На самом деле идея с целевым сбором под конкретные железки звучит очень здраво, потому что скупить весь зоопарк смарт-ТВ и свистков для тестов в одиночку просто невозможно. Попробую добавить ссылки на краудфандинг в readme репозитория, возможно, действительно соберём на пару тестовых адаптеров, которые чаще всего просят в комментариях. Спасибо!
в сизифе не будет?
Сам я ALT Linux не пользуюсь, поэтому собрать и поддерживать пакет для Сизифа мне будет сложновато. Но проект полностью открытый под лицензией GPL-3.0, и я только за! Если среди майнтейнеров АЛЬТа найдётся тот, кто захочет забрать FluxCast к себе в Сизиф я буду очень рад и готов помочь со своей стороны, если возникнут вопросы по зависимостям.
Ребята, вы невероятные! Проект FluxCast только что пробил 130 звёзд на GitHub! Спасибо вам огромнейшее за такую поддержку.
Только что я выпустил официальный пакет в Pypi! Также выкатил свежий релиз v0.1.1, где пофиксил первый краш на адаптере от Microsoft и добавил в TODO идею с целевым краудфандингом для покупки тестового железа. Работаем дальше!
Вау! Уже не терпится придти домой и попробовать.
Забавно: я почти не играю на ПК, но есть в кладовке первый steam box (или как оно там называлось), в постоянном подключении nvidia shield. В итоге, ни одна из этих коробочек не показала стабильной работы, и я забил на надежду играть на большом ТВ. И это было на винде.
Теперь уже на линуксе даже пробовать их не хочется снова. Ваш проект прямо в жилу. И да, у меня LG, так что если заведётся, прям не знаю, как это будет круто.
Как я написал свой клиент Miracast для шаринга экрана под Linux в 2026 году и погряз в войне за проприетарные байты