Как лучше использовать ffmpeg с ASP.NET Core, в Linux?

Question

Как лучше использовать ffmpeg с ASP.NET Core, в Linux?

2

У меня есть проект (ASP.NET Core, в Linux), где находятся несколько задач, связанных с преобразованием и извлечением кадров из видеофайла.

Я подумал о двух возможных вариантах:

с помощью утилиты консоли ffmpeg
используя P/Invoke с библиотекой libavcodec и другими, которые ffmpeg использует

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

Я сделал googling, но нет неплохих проектов для платформы С#/ASP.NET Core на платформе Linux. Есть несколько полезных для C++ и Python, но НЕ для С# в Linux/.NET Core.

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

Я спрашиваю о вашей практике, потому что это мой первый опыт на платформе Linux с преобразованием/выборкой видео с использованием С#. Я использовал библиотеку Expression Encoder.NET на платформе Windows, но это другая история, и это не имеет смысла, прямо сейчас.

Может быть, есть и другие варианты, которые я сейчас не вижу. Мне не нравится первый вариант из-за возможных необработанных исключений, потому что ffmpeg с такой ролью становится черным ящиком для бэкэнда ASP.NET Core.

Neverlands 30 окт. 2017, в 14:58

Источник

1

Я лично использую 1-й вариант. Конечно, вам нужно перенаправить stdout strerr, чтобы перехватить вывод ffmpeg для перехвата ошибок (и проверки кода завершения процесса). Вам необходимо заявить, какие «многие возможные проблемы» вы видите в этом случае. Тем не менее, я не буду выполнять это непосредственно из приложения asp.net, у меня будет отдельное приложение для обработки видео.
Evk 30 окт. 2017, в 14:18
0

@Evk Evk Понятно, это вариант, спасибо. О возможных проблемах ... Я понимаю, что говорить об абстрактных вариантах довольно глупо, потому что говорить такие вещи нормально только из реальной практики. Но, например, видео или аудио были закодированы с ошибками, и ffmpeg может привести к сбою ... Такая ситуация может нарушить длительный процесс загрузки видео с генерацией предварительного просмотра ... Но это также может быть обработано с помощью stdin / stdout. Я не думал об этом, спасибо. Таким образом, я могу обрабатывать все возможные исключения.
Neverlands 30 окт. 2017, в 14:37
1

Ну, я никогда не видел, чтобы ffmpeg действительно падал, но даже если это произойдет - вы тоже это заметите. Обратите внимание, что в таком случае, если бы вы вызвали ffmpeg напрямую с помощью pinvoke - ваш процесс завершился бы аварийно. В общем, у меня обычно есть отдельная очередь обработки приложений для задач обработки видео (не обязательно последовательно, может быть использование нескольких потоков или даже нескольких приложений) и уведомление заинтересованных сторон (таких как веб-приложение) о результатах. Я бы никогда не сделал такую вещь в процессе веб-приложения asp.net.
Evk 30 окт. 2017, в 14:42
0

@Evk Насчет монолитной архитектуры, я с тобой полностью согласен, что это плохо. В этом проекте уже используется сервис-ориентированная архитектура (SOA), и уже есть очереди (с другими задачами) и связь служб (есть также отдельная служба OpenID Connect в семействе микросервисов проекта).
Neverlands 30 окт. 2017, в 14:46
1

В данном случае речь идет даже не о монолитной архитектуре (хотя это, конечно, тоже), а об этой конкретной задаче обработки видео. Обработка видео может занять много времени, поэтому вы не можете сделать это во время http-запроса (или он может быть сброшен из-за тайм-аута), и вы также не хотите порождать 1000 процессов ffmpeg в случае высокой нагрузки, поэтому вам нужна очередь и в этом случае разумно сделать так, чтобы эта очередь и ее обработка были удалены из процесса веб-приложения (потенциально обработка видео могла бы происходить даже на отдельном сервере - здесь монолитный дизайн действительно будет кусаться).
Evk 30 окт. 2017, в 14:50
0

@Evk Evk Понятно, спасибо за хороший совет.
Neverlands 30 окт. 2017, в 14:52

Показать ещё 4 комментария

Теги:

c#

ffmpeg

asp.net-core

linux

libavcodec

1 ответ

Ещё вопросы

Я лично использую 1-й вариант. Конечно, вам нужно перенаправить stdout strerr, чтобы перехватить вывод ffmpeg для перехвата ошибок (и проверки кода завершения процесса). Вам необходимо заявить, какие «многие возможные проблемы» вы видите в этом случае. Тем не менее, я не буду выполнять это непосредственно из приложения asp.net, у меня будет отдельное приложение для обработки видео.
@Evk Evk Понятно, это вариант, спасибо. О возможных проблемах ... Я понимаю, что говорить об абстрактных вариантах довольно глупо, потому что говорить такие вещи нормально только из реальной практики. Но, например, видео или аудио были закодированы с ошибками, и ffmpeg может привести к сбою ... Такая ситуация может нарушить длительный процесс загрузки видео с генерацией предварительного просмотра ... Но это также может быть обработано с помощью stdin / stdout. Я не думал об этом, спасибо. Таким образом, я могу обрабатывать все возможные исключения.
Ну, я никогда не видел, чтобы ffmpeg действительно падал, но даже если это произойдет - вы тоже это заметите. Обратите внимание, что в таком случае, если бы вы вызвали ffmpeg напрямую с помощью pinvoke - ваш процесс завершился бы аварийно. В общем, у меня обычно есть отдельная очередь обработки приложений для задач обработки видео (не обязательно последовательно, может быть использование нескольких потоков или даже нескольких приложений) и уведомление заинтересованных сторон (таких как веб-приложение) о результатах. Я бы никогда не сделал такую вещь в процессе веб-приложения asp.net.
@Evk Насчет монолитной архитектуры, я с тобой полностью согласен, что это плохо. В этом проекте уже используется сервис-ориентированная архитектура (SOA), и уже есть очереди (с другими задачами) и связь служб (есть также отдельная служба OpenID Connect в семействе микросервисов проекта).
В данном случае речь идет даже не о монолитной архитектуре (хотя это, конечно, тоже), а об этой конкретной задаче обработки видео. Обработка видео может занять много времени, поэтому вы не можете сделать это во время http-запроса (или он может быть сброшен из-за тайм-аута), и вы также не хотите порождать 1000 процессов ffmpeg в случае высокой нагрузки, поэтому вам нужна очередь и в этом случае разумно сделать так, чтобы эта очередь и ее обработка были удалены из процесса веб-приложения (потенциально обработка видео могла бы происходить даже на отдельном сервере - здесь монолитный дизайн действительно будет кусаться).
@Evk Evk Понятно, спасибо за хороший совет.

J. Doe · Answer 1 · 2017-10-30T13-52-00.000Z

У меня была та же проблема, и я создал собственную минимальную оболочку FFMPEG на основе FFmpeg.AutoGen. Wrapper хорошо работает на linux, но этот путь требует больше времени, чтобы FFMPEG как FFMPEG libs

Некоторое время назад для тестирования я создал также первый вариант с помощью new Process(). Великая вещь таким образом - простота

        Process process = new Process();
        process.StartInfo.FileName = "ffmpeg.exe";
        process.StartInfo.Arguments = "example arguments";
        process.Start();

Вы должны решить сами, но помните - вызывать функции C на С# - это удивительная вещь