https://www.opennet.ru/openforum/vsluhforumID3/115749.html После шести месяцев разработки доступен (http://ffmpeg.org/download.html#release_4.1) мультимедиа-пакет FFmpeg 4.1 (http://ffmpeg.org/), включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и декодирование звуковых и видеоформатов). Пакет распространяется под лицензиями LGPL и GPL, разработка FFmpeg ведётся смежно с проектом MPlayer (http://www.mplayerhq.hu/). <br><br><br><br>Из изменений (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=RELEASE_NOTES;hb=release/4.1), добавленных (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=Changelog;hb=release/4.1) в FFmpeg 4.1, можно выделить: <br><br><br><br>- Добавлена возможность использования формата кодирования видео AV1 в контейнерах MP4 и реализован парсер для AV1. AV1 разработан альянсом Open Media (AOMedia) и позиционируется как общедоступный и не требующий оплаты отчислений свободный формат кодирования видео, который заметно опережает H.264 и VP9 по уровню сжатия; <br>- Добавлена поддержка реализации TLS на баз https://www.opennet.ru/openforum/vsluhforumID3/115749.html#79 Mon, 19 Nov 2018 00:58:18 GMT Да, спасибо за пример. Очень показательно. Я сам не могу приводить примеров, ибо не в теме вообще, рассуждаю из самых общих соображений.<br> https://www.opennet.ru/openforum/vsluhforumID3/115749.html#78 Sun, 18 Nov 2018 22:13:38 GMT &gt; Вяленый достиг готовности ещё в 2012 году. Вы все не понимаете о чём говорите.<br><br>А еще ему 480p не нравится, видите ли. А пусть этот умник попробует для начала сохранить себе на винч нежатый YUV в 1080p и посмотрит сколько это весит и какая там скорость потока, чтоли. Тогда узнает почему "лайтовые" забеги на посмотреть как вообще кодек были в 480p.<br> https://www.opennet.ru/openforum/vsluhforumID3/115749.html#77 Sun, 18 Nov 2018 22:06:23 GMT &gt; Кому нужны результаты сжатия в 480p в 2018? Пиарщикам?<br><br>В 500 кбитах то? Тем кто мувик по сети будет смотреть на дохлом канале, например.<br><br>&gt; С тем же успехом можно хвалиться скоростью сжатия видео в 240p.<br><br>Бандвиз жрется и на 240p и на 1080p. Так что плотно сжать важно и тех и других. Кстати на HD экономия бандвиза еще эпичнее получается. А скорость - оптимизируют не по дням а по часам. Вот там китаец. В августе он начал с времени кодирования тестового куска 600000+ миллисекунд. Сейчас в его же комитах цифры типа 149000 фигурируют.<br><br>&gt; Как-то модно стало выкатывать полуготовые решения, но зато на каждом углу орать,<br><br>"Release early, release often" :)<br> <br>&gt; что это прорыв технологий и будущее.<br><br>И таки мне оно нравится - жмет очень плотно. При том у меня нет кластеров как у гугли, я это на обычном компе пережал. А в x264 на тех же 500 кбит получается мутное гуано. А если видео сделать с битрейтом выше - нет, конечно, я и мпег2 зажать могу, так что плевый мувик который в av1 весит 35 мегов на все - стане https://www.opennet.ru/openforum/vsluhforumID3/115749.html#76 Sun, 18 Nov 2018 21:57:24 GMT &gt; Тайминги. Воспроизведение видео завязано на них. Надо вовремя прочитать, вовремя декодировать <br>&gt; и вовремя отрендерить. <br><br>Более того - вся логика DASH сводится к тому что если это не получилось, следующий сегмент будет взять с более паршивым качеством. Автоматически. Так что у юзера видео по сети будет такое, какое его железо и сети реально способны прожевать. А не так что мы тут пытаемся 10-мегабитный поток впихивать в несчастного GPRSника до упора, а тот смотрит его рывками по 3 секунды каждые полчаса.<br> https://www.opennet.ru/openforum/vsluhforumID3/115749.html#75 Sun, 18 Nov 2018 21:54:29 GMT &gt; Предлагаете все выпилить, даже явно мультимедиа типа rtmp*/hls ?<br><br>Сейчас еще DASH актуален. В нем ютуб вещает, да и остальные веб-сервисы видео в основном на него переползают. Ну и ffmpeg резонно научили с ним работать. И на input и на output. Чтобы генерить серверам это, а потом как клиенту - жевать то что нагенерили.<br><br>&gt; 3. Текущий подход наоборот безопаснее: все плееры и прочий мультимедиа софт использует <br>&gt; одну и ту же реализацию из ffmpeg<br><br>Вот именно. Обновить 1 либу с майнтайнерами которые в курсе политик безопасности - лучше чем 20 мелких, полузаброшенных, где автор чего доброго полагает что его супер-ЯП спасет от всего и вся, так что получается как у мозиллы с пдф и битмесаги с эвалом входных данных.<br> https://www.opennet.ru/openforum/vsluhforumID3/115749.html#74 Sun, 18 Nov 2018 21:50:18 GMT &gt; Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для <br>&gt; разбора которых требуются хитрые манипуляции байтами с реализацией на C<br><br>А на чем еще реализовывать критичный к скорости код? Безопасность там кстати здорово подтянули - гугель фуззит это добро непрерывно, так что баги чинятся еще до того как их хакеры найдут. И если кто считает что его парсеры валидируются лучше - на честное слово мы ему таки не поверим, пусть делом докажет. Реализовав столько же парсинга с производительностью не хуже и безопаснее. Тогда будет разговор.<br><br>&gt; (и высокими рисками каких-либо уязвимостей, что подтверждается практикой) <br><br>Практика сейчас такова что там continious fuzzing и куча тестов вылавливают в парсерах самые чудесатые баги.<br><br>&gt; и код, который умеет ходить по ssh не должны совмещаться. <br><br>Очень интересный вывод. Наверное, уровень экспертизы такой же как и с безопасностью.<br><br>&gt; И тем более этого не должно происходить в одной библиотеке, которую потом подключает<br>&gt; все кому не лень.<br><br>А https://www.opennet.ru/openforum/vsluhforumID3/115749.html#73 Mon, 12 Nov 2018 10:18:52 GMT &gt; Нет, собираете тот же ffmpeg, что и в системе, но с нужными вам опциями. Больше пересобирать<br>&gt; ничего не нужно (если линковка была динамической).<br><br>тут могут быть сюрпризы - модные-молодежные эшелон-ноденизабудимлефтпад-игого поделочки могут оказаться с намертво embedded кривособранным.<br>Но он как раз _будет_ требовать сетевой и tls стек, иначе как же вы в телефсбграмм-десктопе будете видео-то передавать?<br><br> https://www.opennet.ru/openforum/vsluhforumID3/115749.html#72 Mon, 12 Nov 2018 10:15:13 GMT &gt; Он должен не мне, а своим пользователям<br><br>у него, к счастью, нет "пользователей" в вашем смысле.<br>Ну то есть есть некоторое количество странных людей, включая меня, использующих именно ffmpeg, но их единицы и они знают что делают, в основном.<br><br>&gt; Это редкие исключения, а не правила.<br><br>ffmpeg весь - "редкие исключения", а для "правила" вам вон av1 с единственно-верным кодеком положон.<br>То есть он почти весь - миллион странных форматов и кодеков, и именно ради них и пилится в настоящее время.<br><br>&gt; А x264 как утилита командной строки это тулза для конвертации из &lt;что-нибудь&gt; в, собственно,<br>&gt; сжатый H.264 поток. Они решили добавить фильтры и расширенные входные форматы.<br><br>ну и прекрасно - вот им и адресуйте свою попоболь, со словами что они добавили в том числе и https: в качестве формата (а может и quic заодно), и он очень, очень несекьюрно. Вдруг уговорите?<br><br>к счастью, я использую очень старую версию x264, поскольку никаких чудес в самом кодеке не жду, и меня эта проблема не беспокоит, тем более что испол https://www.opennet.ru/openforum/vsluhforumID3/115749.html#71 Sat, 10 Nov 2018 09:06:11 GMT &gt; Мне вот категорически не нравится, когда то, что всегда было простым, надежным <br>&gt; и безопасным локальным конвертером вдруг научилось лазить по сети куда не <br>&gt; попадя. Этим должен заниматься кто-то другой. Не примитивная command-line обертка над <br>&gt; библиотекой кодера. Но текущее состояние ffmpeg не дает такой возможности.<br><br>1. ffmpeg лазит не сам, а через openssl/openssh. Если этим будет заниматься кто-то другой, то почему это будет безопаснее?<br><br>2. ffmpeg поддерживает много всего, кроме ssh/https: async bluray cache concat crypto data ffrtmpcrypt ffrtmphttp file ftp gopher hls http httpproxy https icecast librtmp librtmpe librtmps librtmpt librtmpte libsmbclient libsrt libssh md5 mmsh mmst pipe prompeg rtmp rtmpe rtmps rtmpt rtmpte rtmpts rtp sctp srtp subfile tcp tee tls udp udplite<br><br>Предлагаете все выпилить, даже явно мультимедиа типа rtmp*/hls ? Как уже отмечали - не будут вещи типа hls работать нормально, если их реализовывать без связи с демуксером.<br><br>3. Текущий подход наоборот безопаснее: все