Есть хотелка портировать с libvlc утилитку для вывода потоков с видео камер, утилитка написана на яве с vlcj в виде обертки над libvlc, но есть идея переписать на сях для более внятного контроля видео слоя, которого под явой по понятным причинам нет
Утилитку не возбраняется прибить гвоздями к конкретному аппаратному декодеру (невидии или амд) и рисовалке
Нужно:
- выводить одновременно 64+ потока h264/h265 в разных разрешениях, в том числе в хайрезе (5мп+) т.е. нужна поддержка и аппаратного декодирования и вывода, и сразу в многопотоке без синхронизации потоков
- выводить фрагментированный мп4 или прямой ts без разрывов между кусками т.е. что-бы первый кадр файла можно было сразу нарисовать на последнем кадре того что игралось до этого без сброса слоя вывода («черный кадр»)
- в идеале встроенная возможность подсасывать файлы по http(s) чтоб не плодить буфферы
- кросс-платформа линух-вин, неплохо поддерживать мак хотя бы на базовом уровне
на данный момент libvlc печалит следующими моментами:
- стабильность - иногда она на ровном месте убивается при переключении сегментов или старте вывода потока, что в нативном виде что под ява-оберткой, при этом закономерности никакой нет, это просто данность
- совместимость с «китайским» h264/265 не фонтан - часто то что легко декодирует ffmpeg непреодолимое препятствие для libvlc
- нет возможности при переключении заранее декодировать новый поток (дождаться опорного кадра) или подгрузки нового файла (дождаться декодера) и переключать вывод по факту готовности кадра без разрыва картинки
- при включении аппаратного ускорения есть затуп с синхронизацией вывода по первому кадру, при отключении - под явой есть предсказуемый затуп однопоточного вывода
из плюсов:
- аппаратное ускорение работает весьма неплохо (хотя после выпиливания из дебиана live555 приходится собирать ручками) на всех платформах
- обертка под яву весьма недурная
Gstreamer отложен в долгий ящик ибо прошлые эксперименты несколько лет назад показали что надо строить довольно сложную надстройку для декодирования чужого заранее определяя используемые источником кодеки
С ffmpeg все выглядит намного проще в плане автомата определения содержимого но несколько лет назад были определенные проблемы с аппаратным ускорением - либо я что-то делал не так (с) но даже тупой вывод 32 ffplay (т.е. без моего участия - просто 32 эталонных реализации от авторов запущенных одновременно) отжирал ресурсов заметно больше чем вывод тех-же 32 потоков через libvlc - возможно ffmpeg’у помогло бы правильное обертывание чтоб он не долбил 32 копии?
На что еще посмотреть?
