FFMPEG

[n3k0nation]

Использую ffmpeg в качестве реэнкодера звуковых дорожек. Файлов много, все работает в автоматическом режиме (т.е. нормальная ситуация, когда очередь в 4 000 файлов и рабочих 4-5 fork-execute процессов с ffmpeg).
Проблема в том, что ffmpeg, рандомно, в тупую, виснет (без отжора CPU).

Параметры ffmpeg а-ля:

Код:

-i "input.m4a" -vn -acodec libvorbis "output.ogg"

Пока справляюсь костылем, а-ля:

Код:

            if(!proc.waitFor(5, TimeUnit.MINUTES)) {
                proc.destroyForcibly()
                    .waitFor(10, TimeUnit.SECONDS); //wait to kill
                return;
            }

Но это как-то слишком.

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

К сожалению, stdout ffmpeg направлен в /dev/null, по понятным причинам, поэтому я могу только догадываться, что там происходит во время зависания.
Возможно кто-то сталкивался или может быть будут дельные советы.

[WoWan-SM]

FFmpeg, для работы, может использовать две реализации RTMP: свою встроенную, которая активна по умолчанию, и при помощи librtmp. Последняя должна принудительно включаться опцией --enable-librtmp.

Все встроенные механизмы FFmpeg могут использовать пользовательский interrupt колбек. Установить его можно для формата используя поле AVFormatContext::interrupt_callback.

Встроенная реализация RTMP его обрабатывает (как минимум, я чинил в 2014 году утечку файловых дескрипторов в rtmp_open() на подключении при срабатывании этого колбека), а реализация при помощи librtmp - нет, просто потому, что вся кухня происходит внутри librtmp (из всех колбеков, которые можно ей задать - колбек для логирования).

Проверить, с какой реализацией rtmp собран FFmpeg, можно запустив его без параметров и поискать строку --enable-librtmp:

Код:

$ ffmpeg

ffmpeg version 3.0 Copyright (c) 2000-2016 the FFmpeg developers

built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.1)

configuration: --prefix=/usr --libdir=/usr/lib/ --incdir=/usr/include/ffmpeg3.0 --datadir=/usr/share/ffmpeg3.0 --docdir=/usr/share/doc/ffmpeg3.0 --enable-shared --enable-avresample --disable-stripping --enable-gpl --enable-version3 --enable-nonfree --enable-runtime-cpudetect --build-suffix=.ffmpeg3.0 --progs-suffix=3.0 --enable-postproc --enable-x11grab --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libdc1394 --enable-libfaac --enable-libfdk_aac --enable-libflite --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-libpulse [B]--enable-librtmp[/B] --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-openal --enable-opengl --enable-pthreads --enable-vaapi --enable-vdpau --enable-zlib --enable-debug=3

По поводу разницы, я особо не могу сказать: внутренняя более фичаста и функциональна, развивается, но испытывает больше проблем при publishing потока: librtmp поддерживает более навороченные схемы URL, которые особо любит Wowza. librtmp же находится в состоянии стагнации, развития нет, очень часто случаются такие проблемы с тайм-аутами (нет возможности поставить колбек на чтение). В своём PPA я планирую отказаться от сборки с librtmp в пользу встроенной поддержки.

Кроме того, внутренняя реализация поддерживает listen, чего категорически нет в librtmp. Т.е. можно тестировать схемы, где ffmpeg будет выступать в роли эдакого стримингового сервера.

И да stimeout пробывал?

[n3k0nation]

Не очень бы хотелось цеплять к нативу JVM. Если бы все было так просто, то я бы заюзал бы ffmpeg, как библиотеку в проекте
stimeout не подходит по причине того, что я реэнкожу не web-поток. А поднимать дополнительное звено, это будет слишком.

Вроде бы решил проблему, методом еще большего костыля (зато реэнкод происходит, бгг), но пока еще не тестировал. Если после тестирования все будет гладко, то отпишу решение проблемы.

[n3k0nation]

В общем, решение проблемы.

Немного предыстории: понадобилось мне так же делать нормализацию звука, кроме реэнкода, получение пика звука решил сделать опять же через ffmpeg через volumedetect. А теперь интересный факт, так как мне пришлось парсить аутпут ffmpeg'a, то я заметил чертовски офигительную вещь, а именно - ffmpeg пишет весь аутпут в stderr! Просто эпично

Как это связано с зависаниями? Все просто - если процесс стартуется, как подпроцесс в джаве, то при заполнении stdout/stderr, буфер может закончится и из-за чего процесс повиснет в вейте на аутпут. Чтение обычного stdout у меня было, но ffmpeg оказывается туда не пишет ничего. Забавно.