LINUX.ORG.RU

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

 ,


0

1

Состоялся релиз видео конвертера Cine Encoder 3.5.4. Программа написана на языке С++, использует в своей работе утилиты FFmpeg, MkvToolNix и MediaInfo, распространяется под лицензией GPLv3. Существуют пакеты под основные дистрибутивы: Debian, Ubuntu, Linux Mint, CentOS, Fedora, Arch Linux, Manjaro Linux.

В новой версии:

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

Программа может использоваться для изменения метаданных HDR, таких как Master Display, maxLum, minLum, и других параметров. Доступны следующие форматы кодирования: H265, H264, VP9, MPEG-2, XDCAM, DNxHR, ProRes.

>>> Подробности



Проверено: maxcom ()

Ответ на: комментарий от token_polyak

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

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

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

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

EXL ★★★★★ ()
Ответ на: комментарий от hatred

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

kirill_rrr ★★★★★ ()
Ответ на: комментарий от kirill_rrr

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

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

fornlr ★★★★★ ()
Ответ на: комментарий от kirill_rrr

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

hatred ★★ ()
Ответ на: комментарий от hatred

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

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

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

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

blex ()
Ответ на: комментарий от hatred

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

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

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

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

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

kirill_rrr ★★★★★ ()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от blex

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

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

hatred ★★ ()
Ответ на: комментарий от kirill_rrr

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

hatred ★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.