Comments 6
итог. cli проще и понятней, чем портянка, не требует дополнительной компиляции и тиражирования при изменении/расширении версии и параметров.
Вы очень ловко забыли упомянуть что это не туториал, а продвижение вашей же библиотеки.
А зачем сразу делать вторую статью о том же самом? (прошлая https://habr.com/ru/articles/901132/)?
По сути вопроса, мотивация завернуть FFMpeg в Rust понятна. Как учебный проект по изучению Rust, FFI, и FFMpeg, вполне имеет смысл. Но есть фундаментальный изъян в подходе. FFMpeg растет стихийно, и за года развития превратился в монолитный комбайн, чем и решает вообще все возникающие проблемы. При этом наличие libav* библиотек в составе, не предполагает их использование во внешних программах как есть без приличного объема логики, реализованной в самом ffmpeg/ffprobe/ffplay инструменте. Точкой входа для траскодирования всего во все с сотней опций является именно исполняемый файл, который склеивает библиотеки в полезный инструмент. И FFI - будучи лишь пустой абстракцией - не уменьшает сложность использования, а лишь увеличивает. Большая часть требуемых операций при транскодировании сосредоточена в транскодирующем конвейере, который как раз в приложении и реализован. Зачем мне брать вашу библиотеку и городить еще один огород конвейера, если я могу сразу написать 200 опций в командлайн?
При использовании FFMpeg функционала в своем приложении не хватает немного другой функции - точки интеграции своего компонента(на любом удобном языке) в транскодирующий конвейер. Другими словами, мой проект может обладать уникальным функционалом по работе с сжатым или несжатым медиаконтентом. Я не хочу заморачиваться с поддержкой отдельных форматов и протоколов и хотел бы взять FFMpeg и расширить его конвейер. Интеграция напрямую - это C, легаси, и 15 лет стихийной разработки. В то же время, FFMpeg позволяет подключить внешние источники такие как Unix-сокеты, пайпы, сырые байтовые массивы и прочее. Было бы неплохо иметь нативные для конкретного языка абстракции, которые будут до и после моего компонента поднимать например инстансы FFMpeg, сматывать их не на уровне конвейера, а на уровне медиапотока, и предлагать вменяемую абстракцию в мой компонент.
Конкретный пример на злобу дня: Yolo детектор объектов в видео. FFMpeg в пайп-> Python из пайпа с метаданными в пайп -> FFMpeg из пайпа. По типу https://github.com/PyAV-Org/PyAV/blob/main/examples/numpy/generate_video_with_pts.py . Хотя используемые там абстракции мне не нравятся, так как они напрямую унаследованы от низкоуровнего FFMpeg API.
Спасибо за ваш подробный комментарий и ценные предложения! Ваши замечания очень полезны и помогают мне лучше понять направление развития ez-ffmpeg.
По поводу схожести статей, вы правы, новая статья частично пересекается с предыдущей (https://habr.com/ru/articles/901132/). Я хотел показать новые сценарии использования, но понимаю, что это может показаться повторением. В будущем постараюсь делать акцент на уникальном контенте.
Ваша точка зрения о сложности FFmpeg верна: это мощный инструмент, где командная строка даёт полный контроль. Моя цель с ez-ffmpeg — упростить типичные задачи (например, конвертацию или извлечение аудио) для Rust-разработчиков, снижая порог входа. Но я согласен, что для сложных сценариев командная строка остаётся предпочтительной.
Ваше предложение интегрировать свои компоненты в конвейер FFmpeg очень вдохновляет! Хочу отметить, что ez-ffmpeg уже поддерживает:
Все способы ввода FFmpeg, включая пайпы, для гибкой работы с данными.
Пользовательские ввод и вывод, включая данные в памяти или через приватные протоколы (https://github.com/YeautyYE/ez-ffmpeg/tree/main/examples/custom_input_output).
Пользовательские фильтры на Rust, аналогично PyAV (https://github.com/YeautyYE/ez-ffmpeg/tree/main/examples/custom_volume_filter).
Я пока не очень знаком с YOLO, но идея интеграции через пайпы выглядит перспективной! Если у вас есть опыт или конкретные предложения, как реализовать такую функциональность в ez-ffmpeg, буду рад вашим идеям или совместной работе над этим.
Спасибо ещё раз! Ваши идеи помогают улучшать проект. Приглашаю продолжить диалог и, возможно, вместе доработать ez-ffmpeg.
От командной строки FFmpeg к Rust: практическое руководство для различных сценариев