Ребята, вы невероятные! Проект FluxCast только что пробил 130 звёзд на GitHub! Спасибо вам огромнейшее за такую поддержку.
Только что я выпустил официальный пакет в Pypi! Также выкатил свежий релиз v0.1.1, где пофиксил первый краш на адаптере от Microsoft и добавил в TODO идею с целевым краудфандингом для покупки тестового железа. Работаем дальше!
Сам я ALT Linux не пользуюсь, поэтому собрать и поддерживать пакет для Сизифа мне будет сложновато. Но проект полностью открытый под лицензией GPL-3.0, и я только за! Если среди майнтейнеров АЛЬТа найдётся тот, кто захочет забрать FluxCast к себе в Сизиф я буду очень рад и готов помочь со своей стороны, если возникнут вопросы по зависимостям.
На самом деле идея с целевым сбором под конкретные железки звучит очень здраво, потому что скупить весь зоопарк смарт-ТВ и свистков для тестов в одиночку просто невозможно. Попробую добавить ссылки на краудфандинг в readme репозитория, возможно, действительно соберём на пару тестовых адаптеров, которые чаще всего просят в комментариях. Спасибо!
Ребята, я в шоке! Вчера вечером на гитхабе было еще 60 звёзд, а сейчас там уже 90! Спасибо огромное каждому за поддержку и фидбэк в комментариях, для меня это нереальная мотивация развивать проект дальше!
Идея с записью сетевых дампов и их прогоном через CI это на самом деле отличный, очень взрослый подход к тестированию сетевых протоколов. Для больших распределенных систем это буквально единственный способ не сломать совместимость со старыми железками.
На текущем этапе FluxCast до такой масштабной смены архитектуры еще не дорос, да и поддержка полноценного тестового стенда с моками сетевого трафика в одиночку отнимет больше времени, чем написание самого кода.
Но вы правы, если проект продолжит расти и возникнет необходимость в глубоком рефакторинге сетевой логики, сбор дампов от пользователей и написание юнит-тестов на их основе это первое, чем придется заняться. Зафиксировал эту мысль себе на будущее, спасибо за дельный совет!
Спасибо! Вопрос про приватность в Wayland сейчас действительно актуальный и важный.
На данный момент FluxCast работает на уровне захвата вывода конкретного экрана, поэтому изолировать и стримить только одно отдельное окно приложения (например, чисто браузер) стандартным способом пока не получится в телевизор улетит всё, что происходит на выбранном мониторе. =[
В будущем я бы хотел реализовать чистый стрим отдельных окон, а пока единственное рабочее решение это виртуальные headless-мониторы. Они отлично создаются в KDE/GNOME, но на тайлинговых WM всё не так гладко. Мы как раз месяц назад пытались расковырять этот кейс под Hyprland в одном из issue на гитхабе. Как выяснилось в ходе тестов, это апстрим-баг самого Hyprland, который перестаёт рендерить кадры на виртуальный вывод.
Если это все таки заработает то на физическом мониторе ноутбука вы можете спокойно открывать IDE, мессенджеры и sensitive информацию, а на телевизор будет транслироваться только чистая картинка с изолированного виртуального экрана.
Большое спасибо за поддержку и за звёздочку! Про выгорание и общение с пользователями это, наверное, главный страх любого опенсорс-разработчика xD, когда спадает первая волна эйфории. Буду стараться выстраивать процессы так, чтобы проект двигался за счет комьюнити, а не только на моем личном энтузиазме. Вам тоже успехов с вашими проектами!
С практической точки зрения вы правы, донгл или Mi Box решают проблему. Но ведь Linux это в принципе история не про "купить готовое", а про контроль над своим железом и экосистемой.
Мне было банально интересно разобраться, почему протокол, который работает пашет, спотыкается на Linux, и решить эту задачу программно. Плюс, FluxCast это не только про mkv-видео, а про полноценный шеринг экрана в реальном времени (презентации, код, браузер), где просто "кинуть файл в плеер" не сработает
Про go2tv знаю, отличный проект! Но у нас принципиально разные задачи.
go2tv это утилита для каста медиа-файлов (видео, аудио) или статических URL по протоколу DLNA/UPnP. Она не умеет захватывать твой рабочий стол "на лету" с Wayland/X11, кодировать движения мыши в реальном времени и передавать это как стрим по RTSP на Miracast-приёмник. FluxCast создавался именно для полноценного зеркалирования экрана (Screen Mirroring) с минимальной задержкой, а не для трансляции готовых файлов
Так как тестового стенда из десятка ТВ у меня нет, спасают три вещи:
Изоляция фиксов: Код для конкретных брендов (например, LG или адаптера Microsoft) я пишу отдельно, чтобы он не ломал общую логику для других устройств.
Тесты на своём ТВ: После каждого крупного изменения я обязательно проверяю работу всех оболочек (KDE, GNOME, Hyprland) на своём телевизоре. Если база работает у меня значит, фундамент не сломан.
Помощь тестеров: Перед тем как вливать фикс в основную ветку, я скидываю код пользователю, который нашёл баг. Пока он не подтвердит, что всё ок, изменения в прод не идут.
Привет! Отчасти я с вами соглашусь но на самом деле писать захват экрана и кодирование потока с нуля на чистом Python было бы максимально глупо и неэффективно, от такой нагрузки CPU бы просто поплавился.
Я просто не стал изобретать велосипед: всю тяжёлую и грязную работу (захват экрана, работу с аудио, кодирование видео) за меня делают проверенные утилиты вроде ffmpeg и пайплайны GStreamer, которые изначально написаны на C/C++.
Python в моём проекте выступает исключительно как послушный и гибкий "клей", который управляет этими процессами, рулит логикой сети и связывает всё воедино. Для этой задачи его производительности хватает с огромным запасом».
Ребята, вы невероятные! Проект FluxCast только что пробил 130 звёзд на GitHub! Спасибо вам огромнейшее за такую поддержку.
Только что я выпустил официальный пакет в Pypi! Также выкатил свежий релиз v0.1.1, где пофиксил первый краш на адаптере от Microsoft и добавил в TODO идею с целевым краудфандингом для покупки тестового железа. Работаем дальше!
буду рад помочь! =]
Сам я ALT Linux не пользуюсь, поэтому собрать и поддерживать пакет для Сизифа мне будет сложновато. Но проект полностью открытый под лицензией GPL-3.0, и я только за! Если среди майнтейнеров АЛЬТа найдётся тот, кто захочет забрать FluxCast к себе в Сизиф я буду очень рад и готов помочь со своей стороны, если возникнут вопросы по зависимостям.
На самом деле идея с целевым сбором под конкретные железки звучит очень здраво, потому что скупить весь зоопарк смарт-ТВ и свистков для тестов в одиночку просто невозможно. Попробую добавить ссылки на краудфандинг в readme репозитория, возможно, действительно соберём на пару тестовых адаптеров, которые чаще всего просят в комментариях. Спасибо!
Да, вы правы, не подумал как-то об этом, спасибо вам. Уже всё готово!
Ребята, я в шоке! Вчера вечером на гитхабе было еще 60 звёзд, а сейчас там уже 90! Спасибо огромное каждому за поддержку и фидбэк в комментариях, для меня это нереальная мотивация развивать проект дальше!
именно!
Идея с записью сетевых дампов и их прогоном через CI это на самом деле отличный, очень взрослый подход к тестированию сетевых протоколов. Для больших распределенных систем это буквально единственный способ не сломать совместимость со старыми железками.
На текущем этапе FluxCast до такой масштабной смены архитектуры еще не дорос, да и поддержка полноценного тестового стенда с моками сетевого трафика в одиночку отнимет больше времени, чем написание самого кода.
Но вы правы, если проект продолжит расти и возникнет необходимость в глубоком рефакторинге сетевой логики, сбор дампов от пользователей и написание юнит-тестов на их основе это первое, чем придется заняться. Зафиксировал эту мысль себе на будущее, спасибо за дельный совет!
Спасибо! Вопрос про приватность в Wayland сейчас действительно актуальный и важный.
На данный момент FluxCast работает на уровне захвата вывода конкретного экрана, поэтому изолировать и стримить только одно отдельное окно приложения (например, чисто браузер) стандартным способом пока не получится в телевизор улетит всё, что происходит на выбранном мониторе. =[
В будущем я бы хотел реализовать чистый стрим отдельных окон, а пока единственное рабочее решение это виртуальные headless-мониторы. Они отлично создаются в KDE/GNOME, но на тайлинговых WM всё не так гладко. Мы как раз месяц назад пытались расковырять этот кейс под Hyprland в одном из issue на гитхабе. Как выяснилось в ходе тестов, это апстрим-баг самого Hyprland, который перестаёт рендерить кадры на виртуальный вывод.
Если это все таки заработает то на физическом мониторе ноутбука вы можете спокойно открывать IDE, мессенджеры и sensitive информацию, а на телевизор будет транслироваться только чистая картинка с изолированного виртуального экрана.
Большое спасибо за поддержку и за звёздочку! Про выгорание и общение с пользователями это, наверное, главный страх любого опенсорс-разработчика xD, когда спадает первая волна эйфории. Буду стараться выстраивать процессы так, чтобы проект двигался за счет комьюнити, а не только на моем личном энтузиазме. Вам тоже успехов с вашими проектами!
С практической точки зрения вы правы, донгл или Mi Box решают проблему. Но ведь Linux это в принципе история не про "купить готовое", а про контроль над своим железом и экосистемой.
Мне было банально интересно разобраться, почему протокол, который работает пашет, спотыкается на Linux, и решить эту задачу программно. Плюс, FluxCast это не только про mkv-видео, а про полноценный шеринг экрана в реальном времени (презентации, код, браузер), где просто "кинуть файл в плеер" не сработает
Про go2tv знаю, отличный проект! Но у нас принципиально разные задачи.
go2tv это утилита для каста медиа-файлов (видео, аудио) или статических URL по протоколу DLNA/UPnP. Она не умеет захватывать твой рабочий стол "на лету" с Wayland/X11, кодировать движения мыши в реальном времени и передавать это как стрим по RTSP на Miracast-приёмник. FluxCast создавался именно для полноценного зеркалирования экрана (Screen Mirroring) с минимальной задержкой, а не для трансляции готовых файлов
Так как тестового стенда из десятка ТВ у меня нет, спасают три вещи:
Изоляция фиксов: Код для конкретных брендов (например, LG или адаптера Microsoft) я пишу отдельно, чтобы он не ломал общую логику для других устройств.
Тесты на своём ТВ: После каждого крупного изменения я обязательно проверяю работу всех оболочек (KDE, GNOME, Hyprland) на своём телевизоре. Если база работает у меня значит, фундамент не сломан.
Помощь тестеров: Перед тем как вливать фикс в основную ветку, я скидываю код пользователю, который нашёл баг. Пока он не подтвердит, что всё ок, изменения в прод не идут.
Привет! Отчасти я с вами соглашусь но на самом деле писать захват экрана и кодирование потока с нуля на чистом Python было бы максимально глупо и неэффективно, от такой нагрузки CPU бы просто поплавился.
Я просто не стал изобретать велосипед: всю тяжёлую и грязную работу (захват экрана, работу с аудио, кодирование видео) за меня делают проверенные утилиты вроде
ffmpegи пайплайныGStreamer, которые изначально написаны на C/C++.Python в моём проекте выступает исключительно как послушный и гибкий "клей", который управляет этими процессами, рулит логикой сети и связывает всё воедино. Для этой задачи его производительности хватает с огромным запасом».