Релиз видео конвертера Cine Encoder 3.5.4

использует в своей работе утилиты FFmpeg, MkvToolNix и MediaInfo

QProcess

НА ПОЛ ТАРЕЛКУ ПОСТАВЬ

А что в этом плохого? Как раз разделение труда, UNIX-Way. Программы делают что-то одно, но делают это хорошо.

FFmpeg и его утилиты отлично занимаются тем, для чего были предназначены – для кодирования и редактирования видео, а этот вот Cine Encoder предоставляет удобную GUI оболочку к богатой функциональности FFmpeg.

По такому же принципу работают абсолютно все IDE, начиная от Visual Studio, Visual Studio Code и заканчивая IDEA JetBrains.

И это правильный подход. В отличие от каких-нибудь иксов, которые нарушают первый принцип UNIX-Way и пытаются втянуть в себя всю функциональность и написать кривоработающие велосипеды.

У ffmpeg хороший библиотечный api. И использование процесса выглядит сомнительным.

Запуская процесс и парся его вывод совершенно естественно можно перейти к многопоточной и многозадачной архитектуре без ущербба отказоустойчивости и перерасхода памяти. А в случае подгрузки библиотеки - ХЗ.

Запуская процесс и парся его вывод совершенно естественно можно перейти к многопоточной и многозадачной архитектуре без ущербба отказоустойчивости и перерасхода памяти. А в случае подгрузки библиотеки - XЗ

Толи это опять юмор какой-то.

...то ли сравнение многопроцессных приложений с однопроцессными.

Отказоустойчивость, тут да. А вот перерасход памяти, тут строго нет. Плюс дополнительные силы на парсинг того, что и так может быть доступным. Эдакая двойная конвертация. Ну и по поводу надёжности: обрабатывающую часть вполне можно через vfork/spawn пустить.

Давай тогда сравнивать fork/exec и fork/api? Эт если речь про надёжность.

Правильно ли я понимаю комментарий:

1. Запускаем дочерний процесс используя posix_spawn (почему не обычный fork? операции длинные, выигрыш от более быстрого vfork минимален)
2. В дочернем процессе наш код использует API ffmpeg и делает работу, выдавая информацию в основной процесс в контролируемом нами формате.

Не получится ли, что напишем свой ffmpeg в результате?

Спасибо. Никогда так не делал, но, наверное, от лени.

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

дополнительные силы на парсинг того, что и так может быть доступным. Эдакая двойная конвертация.

Возможно, но парсинг текста это парсинг текста. Самое худшее что может случиться - будут получены нечитаемые данные и поле окажется пустым. А в случае прямой передачи через api можно и сегфолт словить если какая нибудь переменная выйдет за граничные условия.

И ещё мне кажется когда человек оформляет часть системы в качестве этакого самодостаточного элементарного устройства с этакой гальванической развязкой от прочих элементов - система в целом становится понятней и надёжней, хотя да, кпд слегка проседает.

Причём я не про то, чтобы изолировать отдельные api как это сейчас модно внутри виртуальной среды исполнения вроде андроида или веба, а об изоляции конечных задач пользователя.

про posix_spawn заговорился. Это «конкуррент» vfork+exec в одном флаконе.

Ffmpeg не получится, получится только то, что реально необходимо без парсинга. api достаточно простой, но нужно разок напрячься, разобраться и понять.

Это пока отлаживать (в отладчике) всё это скопом не потребовалось) тут тулинг на стороне потоков. Парсинги на сишечке и плюсцах тоже далеко не последние источники сигфолтов. Вывод же не потокол, он и измениться может, и тут оппа, и что-то да не учли. У меня вот именно с ffmpeg так и было)