Hacker News Digest

В Sony PS2 VPK-демuxe vpk_read_packet происходит деление на ноль из-за отсутствия проверки количества каналов. При обработке последнего блока аудио вычисляются size и skip через деление на par->ch_layout.nb_channels, которое может быть равно нулю из-за некорректного заголовка VPK-файла. Это приводит к SIGFPE и аварийному завершению любого FFmpeg-программы, открывающей вредоносный .vpk-файл или поток. Уязвимость эксплуатируется через 21-байтовый ввод с магией VPK и нулевым полем nb_channels в заголовке, обходя валидацию в vpk_read_header из-за расхождения данных между probing и чтением пакетов в кастомном AVIO-пути фаззера. Ошибка носит детерминированный характер, требует минимальных предусловий и представляет собой надёжный отказ в обслуживании без потенциала для выполнения произвольного кода. Рекомендуется добавить проверку if (par->ch_layout.nb_channels == 0) return AVERROR_INVALIDDATA; в начале vpk_read_packet, чтобы возвращать чистую ошибку вместо генерации исключения. Для регрессионного теста предложен массив из 21 байта, соответствующий краш-входу, при котором av_read_frame должен возвращать -22 (AVERROR_INVALIDDATA) без падения.

Уязвимость, вызванная делением на ноль, известна, исправлена патчем, отправленным в апреле и обсуждаемым в 2024 году. Спор о её значимости: одни считают краш на плохих данных некритичным, другие — что любой краш должен быть исправлен. Баг обнаружен фуззером, а не LLM, что подчеркивает практическую ценность автоматического тестирования над AI‐гиперболой. Участники отмечают, что генерация корректных входных данных для глубокого фуззинга остаётся сложной. Рекомендуется: ограничить поддерживаемые форматы FFmpeg вместо «всех», явно проверять переменные перед делением, использовать типы данных, исключающие ноль (например, unsigned с проверкой), и подавать PR с тестами вместо issue. Критикуется низкое качество документации — README фуззера назван «AI‐slop». AI ускоряет поиск багов, но порождает некачественный код и документацию, увеличивая нагрузку на разработчиков. Проблема отражает архитектурную сложность старых медиа-контейнеров в FFmpeg. Спор о том, является ли это уязвимостью библиотеки или лишь следствием пользовательского AVIO‐модуля.

Обе модели — Claude Fable 5 и GPT-5.6 Sol — самостоятельно создали полноценные музыкальные клипы под «Uptown Funk» с бюджетом $25 и $100, используя инструменты для поиска, генерации видео и монтажа через ffmpeg. Все клипы завершились успешно, синхронизированы с аудио и сохранены в HD-качестве, но движение в кадрах редко совпадает с ритмом песни — например, жест «gotta kiss myself» выглядит замедленно и неестественно.

Claude Fable 5 при $100 потратил $48.60 и сгенерировал клип в 1080p, используя только текст-в-видео, в то время как GPT-5.6 Sol при том же бюджете потратил $36.57, экспериментируя с тремя разными моделями генерации. GPT-5.6 Sol при $25 был единственным, кто использовал комбинацию статичных изображений и анимации, добавив текстовые эффекты — остальные просто склеивали клипы. Ни одна модель не перерабатывала результаты, не проверяла качество генерации и не использовала Replicate, несмотря на доступность. Claude оказался дороже в вычислениях, но его $100-клип выглядел чуть убедительнее. Бюджет в $100 оказался избыточным — модели не использовали его полностью и не предприняли стратегических шагов, например, создания согласованных персонажей.

Участники обсуждения считают, что AI-генерация музыкальных видео пока не достигает нужного качества: синхронизация с аудио неудовлетворительна, сюжеты слабы, а результат не заменяет человеческое творчество. Большинство согласны, что текущие AI-видео вредят развитию технологий, а не способствуют им. @anton7000 и @sensanaty спорят с @boca_honey о том, является ли это искусством; @saaaaaam и @dwa3592 критикуют качество, тогда как @willmeyers утверждает, что музыкант может сделать лучше за $25 и 45 минут с друзьями. @BLKNSLVR предлагает использовать «неquite-but-almost uncanny-valley-ness» как стилистическую особенность, а не баг.

К сожалению, предоставленный текст не содержит статьи "FFmpeg to Google: Fund Us or Stop Sending Bugs" от The New Stack. Вместо этого это форма подписки на их рассылку. Чтобы я мог создать точный пересказ статьи (~170 слов на русском в Markdown), пожалуйста, предоставьте текст самой новости.

Как только вы поделитесь содержанием статьи, я сразу подготовлю лаконичный пересказ, выделив главную идею и ключевые факты/цифры/цитаты, строго следуя вашим инструкциям.

• Крупные корпорации (Google, Amazon и др.) ожидают, что open-source проекты будут бесплатно исправлять уязвимости, которые они же и находят, но при этом не предлагают ни ресурсов, ни финансирования.
• Сторонники FFmpeg отвечают, что если проект не может позволить себе тратить время на бесплатную разработку, то это не значит, что он обязан это делать, и что крупные компании могут просто отказаться от использования open-source, если не хотят платить.
• Обсуждение вышло за рамки конкретной ситуации и затронуло более широкий вопрос о том, как корпорации используют open-source без всякой отдачи.
• Некоторые участники обсуждения подняли вопрос о том, что если FFmpeg и подобные проекты не могут позволить себе тратить ресурсы на бесплатную разработку, то, возможно, им стоит пересмотреть свою модель лицензирования или найти другие способы монетизации.
• В целом, обсуждение подняло волну обсуждений о том, как корпорации используют open-source без всякой отдачи, и как это влияет на устойчивость проектов.

Жан-Баптист Кемпф, президент и основной разработчик VLC, получил Европейскую премию SFS 2025 на SFSCON за свою долгосрочную преданность проекту. VLC, начавшийся как студенческая инициатива в 1996 году, превратился в один из самых широко используемых медиаплееров с миллиардами пользователей по всему миру. Когда проект был на грани исчезновения после выпуска оригинальных разработчиков, Кемпф взял на себя руководство и преобразовал его в незаменимый медиаплеер, который мы используем сегодня.

Маттиас Киршнер, президент FSFE, отметил, что для многих пользователей проприетарных операционных систем VLC стал первым свободным программным обеспечением, которое они когда-либо устанавливали. В своей речи Кемпф выразил честь получению награды и поблагодарил команды VideoLAN и FFmpeg за их работу, часто совершаемую с малым признанием. Европейская премия SFS, учрежденная в 2023 году, признает людей, внесших значительный и устойчивый вклад в продвижение свободного программного обеспечения в Европе.

• VLC исторически критичен для воспроизведения видео благодаря широкой поддержке кодеков, особенно в 2000-х, и остается популярным на мобильных устройствах и Windows.
• Основатель проекта Жан-Батист Кемпф получил признание за отказ многомиллионного предложения о продаже, чтобы сохранить проект открытым и без "вшивания" рекламы.
• На Linux VLC уступает mpv/Celluloid для продвинутых пользователей, но остается удобным решением для новичков и систем с устаревшим оборудованием.
• Проект вносит значительный вклад в экосистему через ffmpeg и разработку технологий вроде низколатентного стриминга Kyber, несмотря на критику интерфейса и функционала.

Emacs как обрезчик видео

Марцин Борковский показал, как вырезать фрагменты прямо из редактора. Автору тоже часто нужно обрезать скринкасты, поэтому он вдохновился и написал video-trimmer-mode (~300 строк Elisp).

• Использует ffmpeg для всей тяжёлой работы.
• Показывает превью и позволяет задавать начало/конец кадрами.
• Код живёт в dotsies и обновляется.

Если пригодилось — поддержите автора на GitHub Sponsors или купите его macOS/iOS-приложения.

• Автор показал, как обрезать видео прямо в Emacs, используя ffmpeg и 300 строк Elisp.
• Пользователи спорят: «круто, но зачем?» vs «если ты уже живёшь в Emacs, то это естественно».
• Плюсы: всё текстом, клавиатурное управление, можно автоматизировать, не надо выходить из среды.
• Минусы: GUI всё-таки удобнее для точного выбора кадров; для разовой задачи проще спросить LLM нужную команду ffmpeg.
• Сторонники Emacs считают его не редактором, а полноценной программной средой (или «ОС»), где легко интегрировать любые инструменты.

FFmpeg/asm-lessons — репозиторий с уроками по ассемблеру для FFmpeg.
Цель: научиться писать высокопроизводительные рутины на x86-64, ARM и других архитектурах, ориентированные на мультимедиа-задачи.

Содержание (кратко):

• Уроки: от базовых инструкций до векторных расширений (SSE/AVX, NEON).
• Примеры: реализация IDCT, фильтров, цветового преобразования.
• Тесты: юнит-тесты и бенчмарки для сравнения C vs asm.
• CI: автоматическая проверка на x86-64 и ARM через GitHub Actions.

Как начать:

1. Клонируйте репо.
2. Установите nasm, yasm или llvm-mingw.
3. Соберите пример: make lesson01.

Полезные ссылки:

• Документация FFmpeg
• x86 SIMD
• ARM NEON

• Пользователи восхищаются масштабом FFmpeg и экономией вычислений даже при небольших улучшениях.
• Обсуждаются случаи, когда ручная сборка быстрее intrinsic’ов, и инструменты для поиска «горячих точек».
• Некоторые ждали более глубокой связи с FFmpeg, а не общее введение в ассемблер.
• Поднимаются вопросы портативности (пока только x86-64), необходимости математических подготовок и перегруженности NASM-макросами.
• Большинство соглашается: писать LLVM IR вручную нет смысла, проще использовать inline-assembly или векторные инструкции.

Репозиторий FFmpeg

• 120 755 коммитов, 38 веток, 408 тегов, размер 271 МиБ
• Языки: C 90 %, Assembly 8 %, Makefile 1 %, остальное <1 %

Ветка master

• Последний коммит: a2cfaf1 — avformat/mov: передавать индекс потока в sanity_checks для HEIF
• CI: все проверки успешны (linux-amd64, linux-aarch64, Windows, lint)

Ссылки

• ZIP | TAR.GZ | BUNDLE

Последние изменения

• libavformat: передача индекса потока в sanity_checks для HEIF (James Almer)
• libavcodec: очистка pu_info в rv60dec
• fftools/ffmpeg_mux_init: 64-битные вычисления score
• libswscale: выравнивание на 8 строк для planarCopyWrapper
• doc/examples: замена sleep на av_usleep
• presets: удалены устаревшие пресеты iPod

• FFmpeg ушёл с GitHub на самостоятельный Forgejo, отказавшись от рассылок и ускорив навигацию по файлам.
• Пользователи жалуются на защиту Anubis с «аниме-девочкой»: ошибки «Invalid Response», пропадающий CSS, проблемы на Android.
• Критика мотива «не Microsoft» и вопросы: почему именно Forgejo, а не GitLab/Gitea.
• Сторонники отмечают суверенитет и удобство, противники — нестабильность и «нелепый» брендинг.