Работа с видео *

Если вы любите образовательный контент также, как его люблю я, вы обязательно оцените мои революционные решения в управлении видеопотоком, которые я упаковал в собственный браузер для мобильных устройств.

Когда пытаешься осмыслить Семихатова переходящего с кораблей бороздящих просторы космоса на эрмитовы операторы в гильбертовом пространстве. Когда вглядываешься в расположение пальцев каждого слайда “Dark Blues Music To Escape To...” в скользящей технике Justin Johnson. Когда разучиваешь каждое движение праздничного танца пятницы в жизнектвеождпющем стейтменте — выжил. Ну или просто ресечишь техники массажа и упражнений в зале…

У меня есть YouTube-канал с примерно полумиллионом подписчиков (адрес не указываю: не чтобы набрать аудиторию пишу). Видео выкладываю почти каждый день, работы много. И у меня сложилась «блогерская сборка», то есть железо для записи, анализа и обработки видео. В статье расскажу, какое оборудование использую, зачем каждый элемент и на чем сэкономить без заметной потери качества.

Если у вас есть собственные советы — велкам в комментарии, обсудим.

Развитие Physical AI сегодня уткнулось в отсутствие достаточного количества данных. Если для обучения VLM мы могли взять огромный объем текстовой информации, который годами копился в интернете, то VLA и world‑action-модели кормить практически нечем, создавать новые датасеты для обучения этих моделей оказалось чуть ли не сложнее, чем разработать конструкцию робота. Хотя люди сняли и выложили в открытый доступ огромное количество видео от первого лица, где руками делают что угодно — готовят, собирают, крутят, хватают, но использовать их в таком виде пока невозможно.

Я Артём Лыков, руководитель R&D-направления Physical AI в MWS, и сегодня я расскажу вам о том, с какими проблемами сталкивается отрасль, и о том, как мы разработали и протестировали AgenticFocus — пайплайн, который берет любое FPV-видео и превращает его в полноценный датасет для обучения гуманоидных роботов тонкой моторике. Ключевая идея AgenticFocus — разделить видеоряд на несколько полноценных слоев информации — фон, объекты и кинематику конкретного робота.

В этой статье приведены: паттерны команд Bash в формате скрипта make_window_icon_txt.sh, а также добавление alpha канала с помощью Bash-скрипта утилитами imagemagick (convert) и ffmpeg. Скрипт имеет размер 290 строк. Эти команды bash отвечают на вопросы:

— Как удалить фон из анимированных форматов gif, webp, mov?
— Как добавить alpha канал в форматы gif, webp, mov, mp4 и png?
— Как конвертировать форматы gif, webp, mov, mp4 в отдельные png изображения?
— Как собрать форматы gif, webp, mov, mp4 из отдельных png изображений?
— Как конвертировать изображения в формат ARGB иконок оконных менеджеров?
— Как попиксельно обрабатывать форматы gif, webp, mov, mp4 и png?

Также в статье приведены оптимальные параметры команд imagemagick (convert) и ffmpeg для обработки форматов gif, webp, mov, mp4 и png.

Представьте что вы — индус на отшибе мира у которого старенький ноутбук 2016-2017 года. Вам захотелось записать на YouTube видео с вашего компа, но вот незадача — OBS заставляет ваш ноутбук задыхаться. Bandicam платный, а бесплатной версией себя долго не помучаешь. Как насчет других аналогов? а вот фигушки! Если брать тот же ShareX то он не идёт с играми и жрёт кадры.

Принципе любой рекордер жрёт кадры, это неизбежно, в любом случае мораль проста - OBS идеален, если у тебя стоит хороший ПК. а если нет то... ну, тут ничего не поделаешь. Это не вина OBS — он решает другие задачи. Но для слабого железа нужен другой инструмент

И после одной такой мысли я подумал - а как решить эту проблему? Я живу по принципу "Критикуешь - предлагай" и я предлагаю свою программу - HomRec, которая решила мою проблему с OBS. Она полностью опенсурсна, есть на GitHub и бесплатна для каждого. Я написал её полностью на C++, она работает с помощью ffmpeg и, как мне кажется, вообще ничем не уступает по записи. А вот интерфейс знатно хромает.

Настройки помогают указать то как запись будет вестись, оверлеи исполняют базовые потребности по типу прикрепления картинки на экран или действий на клавиатуре. Так же я вошел в азарт и заделал туда свой терминал для различных задач (например — там есть свой пакетный менеджер для плагинов, а точнее их установки). подробнее я позже напишу в документации.

Кстати по поводу плагинов — они тоже присутствуют (как вы, скорее всего, уже поняли). Пишутся они на Lua 5.4, изначально я планировал сделать для этого Python но решил, что Lua больше подходит для этого.

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

Всё просто, вот краткое описание требований для «машины времени»:

— Старая фотография знакомого места.
— Реставрация старой фотографии: добавить цветов в ч/б фото и возможно, атмосферности.
— Оживление старой фотографии Minimax H3 и добавление одного или нескольких современных персонажей в старый оживленный мир.

Всего два небольших промпта в процессе.

Два года назад несколько секунд мыльной генерации считались прорывом. Сегодня нейросети выдают кинематографичные ролики в 4K качестве, держат консистентность персонажей и работают с референсами — и это активно применяется в работе.

В статье разобрал, какие технологические скачки произошли с 2024 по 2026 год, как они повлияли на рынок и какие направления будут определять развитие рынка дальше.

30 секунд за один проход, нативный звук, несколько персонажей — и даже DOC, PDF, PowerPoint или веб-страница на входе.

Alibaba открыла preview Wan 3.0, и это уже заметно больше похоже не на «оживление картинки», а на попытку собрать законченную сцену из разных исходных материалов.

Я подробно разобрал возможности и цены новой модели, посмотрел официальные демо и сравнил её с Seedance 2.5 и 2.0, Kling 3.0, MiniMax H3, Veo 3.1 и Grok Imagine.

Внутри статьи также — сами ролики: 30-секундный one-take, схватка кошки со снежным барсом, восемь языков в одной песне, document-to-video, UGC и другие примеры.

Пять красивых секунд сегодня умеют уже многие. Следующая планка — получить 20–30 секунд действительно управляемой сцены: с теми же героями, теми же предметами, нормальным звуком, развитием действия и без развала всего этого по дороге.

Wan 3.0 — ещё один очень заметный шаг именно туда.

Счетчик показал десятки проездов за одну красную фазу светофора. Машина была одна, и она стояла.

Нейросеть при этом отработала правильно. Она видела машину и держала ее рамку все это время. Ошибка была в семидесяти строках обычного Python, которые я написал сам.

Система считает машины, автобусы и трамваи на видео с неподвижной камеры… Готовых наборов данных не брал: хотел пройти весь путь от съемки до обученной модели сам и посмотреть, где он ломается.

Ломался он пять раз. Метрики тоже будут, вместе с разбором, почему верить им нельзя.

Последние годы я работал разработчиком в области машинного обучения, компьютерного зрения и 3D-реконструкции. Писал и видел множество вариантов организации вычислений и обработки потока данных. Но в них мне не хватало системы и организованности, прозрачности и гибкости. Поэтому я набрался решимости и воплотил самые мои смелые — и, как оказалось, вполне рабочие — идеи в новом фреймворке, который я назвал ICO.

Скролл-фильм на лендинге — это обычно сотни WebP и десятки мегабайт. Рассказываю, как заменил секвенции кадров сырым H.264-потоком без контейнера и WebCodecs-декодером: 84 → 18 МБ на мобиле. С параметрами кодирования и тремя честными тупиками: почему HEVC оказался хуже x264, зачем шумодав не нужен и как B-кадры сломали фильм на живом iPhone так, что валидация этого не увидела.

Процесс внедрения ИИ на стройке имеет свою специфику. Дело в том, что здесь есть свои подводные камни при масштабировании обработки видеопотоков, при самом процессе обработки данных и при дополнительном обучении модели YOLO под наши российские реалии. Расскажу обо всём по порядку.

Лет 10 назад, когда я работал в банке в Сибири, был у нас отдел - малая автоматизация. Делали ПО для местных. Потом отдел расформировали и перешли на централизованное ПО.

Сейчас каждый может стать таким небольшим отделом малой автоматизации. Для себя, для личных нужд или для своих.

ИИ помогает делать проекты, которые раньше ты бы никогда не сделал. Или дорого по времени, или по ресурсам. А сейчас.... Давно уже не испытывал такой личной упоротости в маленькие проекты. Про один я уже писал, теперь расскажу про другой.

Итак, добро пожаловать на шоу!

Иногда легаси нельзя постепенно улучшить: его приходится разбирать, переосмысливать и заменять, пока основной продукт продолжает работать. Именно в такой ситуации оказались мы в Okko. Нам нужно было отделить воспроизведение от монолита, переписать транскодинг, заменить единовременно старую CMS и сохранить непрерывную работу онлайн-кинотеатра. В результате мы получили единую Видеоплатформу с документированными API, собственным кодированием 4K и HDR, управляемой аналитикой и возможностью разворачивать отдельные инсталляции для внешних партнёров.

Привет! Меня зовут Юлия, я представляю компанию Okko — один из крупнейших и старейших онлайн-кинотеатров России. Сервис появился в 2011 году и за это время вырос в сложный технологический продукт, ежедневно работающий с большими объемами видеоконтента и высокой нагрузкой.

В Okko я руковожу отделом discovery продуктов и сервисом «Видеоплатформа», и именно о нем пойдет речь в этой статье. Я расскажу, почему мы решили создать сервис, какие задачи перед собой поставили, с какими техническими и организационными вызовами столкнулись и как внедрили новую платформу без даунтайма основного продукта.

Продолжаем изучать, как устроен SFU изнутри: добавляем simulcast, ice restart и мониторинг сети. Дневник разработки на Rust.

Продуктовые сайты любят анимацию «крутишь колесо мыши — объект меняется на глазах». Первый инстинкт: сделать это видео с currentTime. Вот почему это почти всегда неправильный первый инстинкт, и что вместо этого используют на практике.

Если кто то, когда-либо занимался видеопотоками поверх интернета, т.е использовал классический медиасервер работающий по принципу RTSP to HLS (или ему подобные протоколы) тогда он знает какие проблемы возникают. Для примера возьмем двух гигантов, Flussonic и Wowza. В документации Flussonic`a есть четкие аппаратные характеристики при которых ЦП начнет долбиться в сотку: 250 камер с битрейтом 2 Мбит/c, на Xeon E3-1230v5 3.4 GHz + 32 GB RAM. У Wowza же четких примеров нет, но если немного «экстраполировать», то у нее на том же железе около 350-400 камер с битрейтом 2 Мбит/c, загружают процессор на сотку. Давайте внесу оговорку: я понимаю, что указанное железо довольно старое. Но 80% малого и среднего бизнеса на +/- таком работают, я имею ввиду тех, кто не пользуется облачной инфраструктурой или не арендует железо в ДЦ. Так вот, казалось бы, ну такая вот нагрузка, что с ней поделать? Проблема в том, что в моменте эти потоки никто не смотрит. Условный «охранник» залипает в телефоне, пьет кофе – а сервак 24/7 продолжает нарезать сырые кадры в HLS-сегменты и писать архив, грея серверную. Банальное расходование ресурсов в пустую, когда они не нужны. А в наш век стоимости на железо – стоит беспокоиться о таких вещах.

Решение на поверхности, и многие о нем знают – режим On Demand (по запросам). Нет зрителей – тушим камеру.  Есть зритель – отдаем HLS-поток. Казалось бы, все идеально, вопрос решен, расходимся. Но тут вылезает главная проблема классического On Demand - как только зрителей нет, соответственно камера потушена, запись архива не ведется. Для любой системы безопасности – это новомодный «ред флаг».

Выкатили мы первый релиз в прод (100 камер), обрадовали клиентов, начали работать. Прошел где-то час, полетели алерты. Залезаю на сервак, смотрю htop – а там свободно 100 метров ОЗУ. Пу-пу-пу-пу. Нужно внести уточнение что боевой сервер имел 32 гига озу. Ожидаемое поведение было то что процессор отдыхает, сетевуха переваривает трафик, озу 250-300 МБ, диски нагружены не сильно. Так что, когда видишь такие цифры в htop, начинаешь винить себя и свои кривые руки, написавшие это "Г". Но все же решили пойти в Гугл, чатгпт и тому подобное. Благо, ответ нашелся быстро, и посыпать голову пеплом перестали.

Код оказался не вообще не причем, память сожрал сам Линукс. Если когда-нибудь вы писали тонны данных на диск, я думаю вы уже поняли в чем дело. Есть такой «невидимый враг» как страничный кэш (Page Cache). Вот именно он и был корнем этой проблемы.

Как работает страничный кеш и что с ним делать?

Когда ваша функция, которая должна писать данные на диск пишет данные, на самом деле она не пишет их на диск. Она пишет их в ОЗУ. Логика ядра Линукса проста и банальна, и она направленна на ускорение «отзывчивости» системы, всю суть можно объяснить так: «О, только что записали сотню гигабайт данных, наверное, скоро понадобится эти данные прочитать. Оставлю-ка я их в кеше, пользователь будет рад что так быстро смог их прочитать.» И так гигабайт за гигабайтом, пока в сервере не кончится физическая память.

Типичное решение проблемы – пишем скрипт, который раз в час делает echo 3 > /proc/sys/vm/drop_caches. Ну а кто-то просто забивает и позволяет системе убивать случайные процессы через OOM Killer. Но мы же пишем отказоустойчивую штуку. Нам такое не подходит. Задача объяснить ядру ОС, что наши fMP4 сегменты видеоархива — это write-only мусор на небольшое количество времени (т.к если клиент не хочет долго хранить записи, то архив чистится, а если хочет – мы отправляем архив после N времени хранения в S3, а локальную копию тоже чистим). Так что все должно работать по принципу – записал и забыл.

Предисловие

Есть небольшой побочный профиль, которым я занимаюсь – ретрансляция сырых потоков RTSP, в HLS. По сути задача простая, чтобы любой простой юзер мог увидеть картинку со своих камер, не пользуясь проприетарным облачным ПО от производителя камер. Во-первых, это много денег, т.к многие клиенты хотят хранить достаточно долго записи с камер. Во-вторых, почти у всех производителей камер разное ПО, и это тупо не удобно иметь 10 разных приложений и/или порталов, где это все можно посмотреть. Ну и в-третьих мало где есть интеграции с ИИ (что для моих клиентов, критически важно). Даже если эта интеграция есть, она либо узкоспециализирована, либо опять-таки проприетарна, либо стоит много денег, а иногда и все это вместе. Решение - использование сырых RTSP потоков, их поддерживают и отдают 90% всех камер на рынке.

Так вот, схема была достаточно проста: несколько камер, простой бэк, выдаем на едином ресурсе для клиентов картинку по HLS, используя плеер hls.js. Всех все устраивало, всем все нравилось. Быстро, просто, удобно и не дорого. Тесты работали идеально, клиенты довольны. С каждым был чат, куда выдавали ссылку на просмотр, а также был общий чат со всеми клиентами – где обсуждались вопросы подключения, финансовые ну и прочее. И вот настает момент Х, кто-то по ошибке скидывает в общий чат ссылку…и конец. По ссылке кликнул видимо весь чат, 3 минуты, полетели алерты в боте, алярм, ахтунг, тревога. Смотрим железо, сервер в ауте, ООМ, все потоки отвалились. Через 20 минут чат разрывался от гневных сообщений, о неработоспособности у всех. Занавес.

TouchDesigner позволяет собирать сложные генеративные эффекты из небольшой сети операторов. В этом туториале создадим «живую луну» из 500 000 точек, поверхность которой непрерывно деформируется процедурным шумом.

Основной эффект строится на связке Point Generator POP, Feedback POP, Noise POP и Math POP. Шум смещает частицы, а нормализация каждый кадр возвращает их на поверхность сферы. Благодаря обратной связи деформация превращается в непрерывное движение.

После настройки POP-системы подготовим рендер через Geometry COMP, добавим шлейф с помощью Feedback TOP и завершим изображение свечением через Bloom TOP. В статье приведены схема сети, параметры операторов, скриншоты всех основных этапов и варианты дальнейшего развития эффекта — от аудиореактивности до управления через MIDI.