Comments 10
github.com/PowerShell/Crescendo
Собственно, изобретать собственный велосипед незачем, если уже есть официальный.
Разницы не будет никакой, поскольку ffmpeg использует для кодирования ту же самую библиотеку libx264, написанную videolan. Самая сложность была в том, чтобы сгенерировать такой mpeg2ts с постоянным битрейтом (и стаффингом) внутри которого видео тоже имеет более-менее постоянный битрейт, а не скачет от 0 и упираясь в потолок допустимого самим ts (а при дефолтных настройках x264 такой битстрим и генерируется). Худо-бедно получилось, в потоке ошибок анализаторы не видели, в плеерах игрался, а голова все равно не хотела воспроизводить. Решилось уже тонкой настройкой ts-муксера и генерацией SDT таблицы. В таком виде стабильно работает по полгода, перезагружась изредка в профилактики РТРС. Про vlc читал, но и слышал что любит течь по памяти он.
Если 1-е покажите, как выравнивали битрейт таким хаком?
Да, только связка ffmpeg + bash + systemd.
Видео кодируется следующим образом:
-c:v libx264 \
-b:v 3000k -maxrate 3000k -bufsize 480k \
-profile:v high -level 3.0 -pix_fmt yuv420p \
-s pal -r pal -aspect 16:9 \
-preset medium \
-forced-idr true \
-x264-params "nal-hrd=cbr:cabac=0:open-gop=0:videoformat=pal:filler=0:colorprim=bt470bg:transfer=bt470bg:colormatrix=bt470bg:interlaced=1:tff=1:weightp=0:force-cfr=1:keyint=25:min-keyint=25:scenecut=-1:bframes=2:b_pyramid=0:intra-refresh=0:constrained-intra=0" \
-tune film \
-top 1 \
-flags2 +local_header
Качество на выходе получается среднее, большего уже вряд-ли можно добиться без очередных глюков.
Нужно обратить внимание на bufsize, контролируя его по дампам потока и смотря, чтобы битрейт видео битстрима не прыгал. Меньше значение — сильнее деградирует качество картинки, но стабильнее битрейт, значение больше — начинает прыгать битрейт и появляются ошибки по ETSI TR 101 290 первого и второго приоритетов.
Муксер, упрощенно (без SDT), настроен так:
-f mpegts \
-flush_packets 0 \
udp://@225.10.10.1:5000?pkt_size=1316\&bitrate=3750000\&burst_bits=100000\&fifo_size=3000000\&buffer_size=3000000
Отключение параметра flush_packets важно. При включенном — ffmpeg будет выплевывать в сеть ts-пакеты as-is с размерами, кратными 188 байтам, что тоже может сводить ресиверы с ума. При выключении — 188-ти байтные ts пакеты буферизируются в один ethernet пакет, который уже и выплевывается в сеть.
Если всё будет декодироваться нормально при такой настройке, то можно включить CABAC — ценой небольшого увеличения загрузки при кодировании (и декодировании, но оно часто аппаратное) можно получить видимый выйгрыш в качестве картинки. В примере отключено, потому что железка, ради которой всё затевалось, не хотела с ним дружить.
Проблема ffmpeg не в обертке, проблема в формировании параметров командной строки под различные задачи.
Stackoverflow пестрит именно вопросами — как сформировать команду под ту или иную трансформацию.
Полезно было бы завести репозиторий задач и соответсвующих команд.
А на каком языке формировать эти команды, как реализовать использование, через UI, API или командную строку, каждый решит себе сам.
Sorry за негатив, но ожидал от статьи большего.
Пишем юзабельную оболочку для FFMPEG на Powershell