The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Выпуск мультимедиа-пакета FFmpeg 6.1"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от opennews (??), 11-Ноя-23, 12:39 
После десяти месяцев разработки доступен мультимедиа-пакет FFmpeg 6.1, включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и декодирование звуковых и видеоформатов). Пакет распространяется под лицензиями LGPL и GPL, разработка FFmpeg ведётся смежно с проектом MPlayer...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60093

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноним (1), 11-Ноя-23, 12:39 
Libvvenc так и не завезли, хотя патчи уже несколько месяцев весят.
Ответить | Правка | Наверх | Cообщить модератору

3. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +3 +/
Сообщение от Аноним (1), 11-Ноя-23, 12:40 
Точнее, висят :)
Ответить | Правка | Наверх | Cообщить модератору

13. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (13), 11-Ноя-23, 14:05 
vvenc проще через pipe гонять - всё равно все его опции только так указываются.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

15. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +2 +/
Сообщение от завезли (?), 11-Ноя-23, 14:28 
Нафиг не упало при открытом и популярном AV1.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

20. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –5 +/
Сообщение от Аноним (20), 11-Ноя-23, 14:54 
> Нафиг не упало при открытом и популярном AV1.

Технически av1 куда более ущербен и, видимо, никогда не займёт заметного места в индустрии. Благодаря его полнейшему провалу, адекватные альтернативы, если и появятся, никогда уже не смогут повторить хотя бы и такой "успех". По крайней мере, до тех пор, пока превосходящие проприетарные технологии не отойдут в общественное достояние и не появится достаточно заинтересованных производителей (что, скорее всего, не случится).

Ответить | Правка | Наверх | Cообщить модератору

21. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +4 +/
Сообщение от Аноним (21), 11-Ноя-23, 15:07 
AV1 провал из-за его использования на тытрупе?
Чувак, ты бы попробовал на мобильном инете 4К хотя бы глядеть - сразу тупые комменты отпали бы.
VP9 может почти вдвое больше весить - вдвое больше напряг для скорости, а заодно двойная доза трафика для людей с ограниченными возможностями.
Этот формат сделан быть свободным от всех возможных корпоративных претензий так как к VP9 все еще оставались вопросы. И кодирование силами видеокарты уже появилось, так что гундеть о якобы провале заведомо тупняк свой показывать.
Ответить | Правка | Наверх | Cообщить модератору

22. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (13), 11-Ноя-23, 15:16 
> VP9 все еще оставались вопросы

https://www.google.com/search?q=av1+patent+pool

Люблю анонимов на opennet, которые живут в альтернативной реальности "AV1 не имеет патентных проблем". Имеет. Google платит.

Ржу.

Ответить | Правка | Наверх | Cообщить модератору

24. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (24), 11-Ноя-23, 15:54 
> Google платит.

Кому и сколько?

> Ржу.

Иди овса поешь.

Ответить | Правка | Наверх | Cообщить модератору

25. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –6 +/
Сообщение от Аноним (13), 11-Ноя-23, 16:00 
> Кому

Patent holders

> и сколько?

Спросите их.

> Иди овса поешь.

Мощные аргументы. Продолжайте.

Ответить | Правка | Наверх | Cообщить модератору

70. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (-), 11-Ноя-23, 19:42 
>> VP9 все еще оставались вопросы
> https://www.google.com/search?q=av1+patent+pool
> Люблю анонимов на opennet, которые живут в альтернативной реальности "AV1 не имеет
> патентных проблем". Имеет. Google платит.

Гугли наздоровье. А таки декодеры с этим натолкали в чипы даже уже копеечные китайцы, в вебе работает, а больше от него ничего и не надо было. Если кто захочет из принципа просрелить себе пятки и платить MPEG LA + еще пачке патентных троллей, это, конечно, его право. А мы этого в вебе делать уже не будем. Даже эппла вот прожали AV1 играть. А ваши чудные проприетарные кодеки в вебе как раз и не работают. И кому они без этого сейчас нужны уже. Легаси телевизионщицкое.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

111. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (111), 11-Ноя-23, 23:24 
4К - "хотя бы"?
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

23. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (24), 11-Ноя-23, 15:53 
Технически, может, и так. Но H265, кроме дисков (которые R.I.P.), не взлетел, и велика вероятность, что H266 проследует той же дорогой. Потому что основные пользователи - интернет-компании, а стандарты MPEG им нафиг не упали из-за лицензионных отчислений. Максимум, поддержит Apple, но они и так по жизни варятся в собственном соку.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

26. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (13), 11-Ноя-23, 16:02 
H.265 более чем взлетел.

В нём ~100% profession HDR content.

AV1, кроме как на YouTube/NetFlix, нет нигде. Мёртвый тяжёлый кодек, чтобы Google сэкономила 2 копейки.

Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноним (31), 11-Ноя-23, 16:50 
>YouTube/NetFlix

Там такое битрейт низкий, что вообще насрать какой там кодек.
>чтобы Google сэкономила 2 копейки

Именно. Но почему юзеры с гигабитным каналом должны подстраиваться под бомжей у которых даже 4G нет?

Ответить | Правка | Наверх | Cообщить модератору

152. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 00:43 
>>YouTube/NetFlix
> Там такое битрейт низкий, что вообще насрать какой там кодек.

Вот как раз совсем не насрать. Там H.264 муть жуткая, а трафа даже на 360p позорном жрет больше чем VP9 на 480 (который уже более смотрябельный), если не 720 (это еще не HD но уже ОК).

А если 1080p хотя-бы взять... ээ... там столько трафа что H.264 версии в этом разрешении может тупо не оказаться. Гугол более 720 в 264 просто не грузит,  даже ЭТО жрет неимоверно битрейта и потому - норовит нарваться на икоту от опустошения буфера при любых неидеальностях. Что конечно же бесит юзерей. Ну да, конечно, они должны быть примотаны проводным гигабитом и желательно сразу в датацентре гугли - но так не бывает, а хомяки хотят смотреть видео на толкане куда их вафля едва достреливает, или вообще проскакивая тоннели и мосты в авто каком, на ходу.

>>чтобы Google сэкономила 2 копейки
> Именно. Но почему юзеры с гигабитным каналом должны подстраиваться под бомжей у
> которых даже 4G нет?

Да вот что-то 4G с вот именно безлимитом - и без звездочек - если и бывает - то за какие-то несуразные деньги. Потому что шатали операторы столько трафа качать.

Ответить | Правка | Наверх | Cообщить модератору

168. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 08:40 
Эх, когда уже наконец все обзаведутся нормальным интернетом, новые кодеки потеряют актуальность и закончится это сумасшествие... Лучше иметь "устаревший" H264 с высоким битрейтом, чем новомодный AV1 с крошечным. Но почему то я должен ему радоваться... вот пускай любители смотреть смешные видосики на сортирах и радуются.
Ответить | Правка | Наверх | Cообщить модератору

171. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (171), 13-Ноя-23, 11:33 
> Эх, когда уже наконец все обзаведутся нормальным интернетом,

Когда вы проспонсируете (весьма короткодействующие) соты 5G или хотя-бы 4G по всему глобусу. Что точно влетит в копеечку. И это в ближайшее время не изменится, убер-скоростные ADC/DAC для SDR с ТАКОЙ скоростью умеет аж целый Analog Devices на всю планету. Что хотите то и делайте с этим фактом.

> новые кодеки потеряют актуальность и закончится это сумасшествие...

Сейчас все упирается в именно сети. Поэтому и уделяют столько внимания кодекам. У гугла оплата трафика - основная статья раходов. Вот и пашут чтобы снизить объемы, ютуб основной потребитель. Но если картинка будет г, юзеры ее смотреть не будут, или к конкуренту уйдут. Все же видео должно доставлять эстетическое наслаждение, что с плохой картинкой хуже получается. В этом месте наступает некая балансировка интересов тех и других.

> Лучше иметь "устаревший" H264 с высоким битрейтом, чем новомодный AV1 с крошечным.

Лучше кому и почему?

1) Я со своей стороны предпочту хранить меньше байтов если это не в ущерб картинке.
2) А уж по сети чем меньше тем лучше.
3) И я совсем не горю желанием заплатить за тот факт что выложил свои мувики на свой сервак.
4) Удобно когда есть стандартный формат который все браузеры жрут без условий и оговорок, патентное вымогательство этот аспект здорово нагибало. То что этот позор закончился - отлично!

> Но почему то я должен ему радоваться... вот пускай любители смотреть смешные
> видосики на сортирах и радуются.

Никаких рациональных аргументов я тут вроде бы не увидел...

Ответить | Правка | Наверх | Cообщить модератору

204. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 16:47 
Потому что, например, режиссёр снял фильм (а не смешной видосик с котиками) и выложил на ютуб. Который пожал это прекрасным AV1 с битрейтом аж 1Mbps, все нищуки ликуют. А через 10 лет даже у нищуков будет лучше скорость. И даже им не надо будет такое "качество", а тот фильм так и останется только в этом качестве. Спасибо YouTube, что портишь контент заранее, блин. На Vimeo хотя бы можно оригинал скачать будет. Да, в "отсталом" h264, но качество все равно будет лучше.

Иначе говоря, нафиг не надо, чтобы AV1 1Mbps выглядел, как H264 2Mbps, это не решает проблему качества. Между плохим и осень плохим не надо выбирать плохое, надо топить за хорошее. А хорошее даже при помощи AV1 не получить, если ориентироваться на бомжей с мобилками.

Ответить | Правка | Наверх | Cообщить модератору

210. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 19:30 
> Потому что, например, режиссёр снял фильм (а не смешной видосик с котиками)
> и выложил на ютуб. Который пожал это прекрасным AV1 с битрейтом
> аж 1Mbps, все нищуки ликуют. А через 10 лет даже у
> нищуков будет лучше скорость. И даже им не надо будет такое
> "качество", а тот фильм так и останется только в этом качестве.
> Спасибо YouTube, что портишь контент заранее, блин. На Vimeo хотя бы
> можно оригинал скачать будет. Да, в "отсталом" h264, но качество все
> равно будет лучше.

Если вам не нравится сервис ютуба вы в вашем праве пользоваться чем-то другим. Вместе с гениальными режиссерами. Гугл никого принудительно на свои серваки не загоняет. Даже можете поставить свою ферму серваков и аплоадить нужное добро сами, в любом формате. Заодно и узнаете сколько что стоит и как оно. Также можете аплоадить на какие там иные сервисы и что там еще.

Только положа руку на сердце - я не думаю что с такими познаниями в кодировании видео и настрое из вас получится убийца ютуба. Даже убийцы Vimeo не получится. А у вимео битрейт в разы выше гугли и оно лагает намного чаще у юзерей, за что и непопулярно.

> Иначе говоря, нафиг не надо, чтобы AV1 1Mbps выглядел, как H264 2Mbps,
> это не решает проблему качества. Между плохим и осень плохим не
> надо выбирать плохое, надо топить за хорошее. А хорошее даже при
> помощи AV1 не получить, если ориентироваться на бомжей с мобилками.

По моему вы на себя многовато берете
1) Навешивая левые эпитеты направо налево - убедитесь что обратка не прилетит.
2) Решать за всех что им надо - фееричная наглость просто. Я вас не уполномачивал за меня расписываться что мне надо.
3) В интернете все просто - не нравится сервис не пользуетесь им. Но на мой вкус вимео ютубу и близко не конкурент в том числе и из за ломовых потоков. Они скопытятся при попытке косплеить гугл даже на 30%, имхо. Видимо такая самобалансировка - как начинает лагать, так юзеры разбегаются - и - вот - смогло несколько процентов. С AV1 смогло бы раза в три больше юзерей сервить.

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

Ответить | Правка | Наверх | Cообщить модератору

218. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 20:52 
> Решать за всех что им надо - фееричная наглость просто.

Так вы и решаете, причем не за своих 1,5 юзера, а за всех.

> не нравится сервис не пользуетесь им

Гуглом пользуются потому что он монополист, а бомжи с мобилками просто не видят разницы. Но да, давайте на них ориентироваться. А юзеры с 4K панелями во всю стену пусть пролетают. Но не удивляйтесь, почему все остальные кино лезут смотреть на амазон или хотя бы нетфликс и торренты, а не туда, где битрейт конский. А сделать 2 варианта (с низким и высоким битрейтом), конечно же, нельзя. Я топлю за выбор, а не за ограничение.

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

Ответить | Правка | Наверх | Cообщить модератору

230. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 22:35 
> Так вы и решаете, причем не за своих 1,5 юзера, а за всех.

Я решаю за себя и своих юзерей. При том мои технические решения я как инженер еще и отстаивать могу, с аргументами. За H.265 в этом треде я вообще ни 1 аргумента не увидел.

Даже анонимъ запастивший график - при помощи нехитрой черчебы другого анонима показал что AV1 сделал там H.264 в 2 раза по бандвизу. Прямо на той точке которую он педалировал (лол!!). Да и 265 там досталось нормально так. И это на версии 4-летней давности, с тех пор имхо разрыв только усиливался. Нормальное демо получилось чего мы такие с AV1 возимся :)))

Вот я и думаю - а какого б хрена мне этой мощью да не пользоваться для себя? Тем более еще забесплатно то и с широкой поддержкой в открытых тулсах? Я что - мазохист платить за кодек хуже и с кучей проблем? Ничего личного, это бизнес. Всегда хотел сказать это какому-нибудь проприетарщику.

> Гуглом пользуются потому что он монополист, а бомжи с мобилками просто не
> видят разницы.

У лично меня вообще 30" калиброваный IPS :D. Иначе я бы и не узнал что HBD-path для LBD дает в AV1 нефиговое улучшение. На мобилке вы это в жизни не увидите. А вот на 30" IPS таки да, если знать куда смотреть. Но вот мобилка из него - разве что для Шварцнегера.

> Но да, давайте на них ориентироваться. А юзеры с
> 4K панелями во всю стену пусть пролетают.

Да у меня так то и у самого монитор норм :). А чего я себя любимого буду обижать то?!

> Но не удивляйтесь, почему все остальные кино лезут смотреть на амазон или хотя бы нетфликс
> и торренты, а не туда, где битрейт конский.

На ютубе с AV1 битрейт как раз приятно удивляет. И расход трафика тоже, если это мобильный интернет. И в отличие от хреноты с ломовым битрейтом оно при отклонениях от идеала по части сетей, серверов, и проч - тупит сильно меньше. Быстрее пребуфер, быстрее скачка сегментов, перемотка, вот это все. Если я мотанул через половину мувика, чудес не бывает. сегмент надо качнуть. Чем больше - тем дольше. Гугл в этом достиг определенных успехов, остальные вообще этот уровень технологий взять напрягаются. Потому и плачутся про монополистов. Ну и вот кто индейцам виноват что они со стрелами задр@чивались вместо изобретения пороха?

> А сделать 2 варианта (с низким и высоким битрейтом), конечно же, нельзя. Я топлю
> за выбор, а не за ограничение.

А корпы топят за то чтобы потратить поменьше и заработать побольше. При том когда банкет оплачивается "из своих" - мне почему-то вполне по пути с таким курсом действий. За ваш то счет все что угодно - при условии что банкет оплачиваете вы.

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

На мой вкус так у ютуба на 2144p и выше в AV1 картинка так весьма недурная для интернет сервиса, при приятно удивляющем бандвизе на это дело.

Ответить | Правка | Наверх | Cообщить модератору

236. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 23:47 
Хз какой инженер будет спорить с тем фактом, что у блюреев качество лучше, чем у вебни, и будет проталкивать ее. Разве что какой-нибудь ангажированный фанатик, который не понимает, что некорректно уже устаревшие H264 и H265 с AV1 сравнивать, но что не сделаешь ради идеи "нагибания гнусных патентных троллей". Ведь если с 266 сравнить, то профита может и не быть даже по соотношению битрейта к качеству.

А мне в равной степени насрать на корпов типа Google, так и на троллей. Две копейки переплатить за железку я могу, и поэтому на мой выбор открытость не влияет никак. Google же предлагает запрыгивать на поезд AV1, не дождавшись прихода VVC и независимых тестов.

Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

240. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 14-Ноя-23, 00:04 
> Хз какой инженер будет спорить с тем фактом, что у блюреев качество
> лучше, чем у вебни, и будет проталкивать ее.

Так там и битрейт какой?! Думаю AV1 будет отлично выглядеть и на заметно меньшем битрейте. А мелкий битрейт - лучше всего хайлайтит отличия между кодеками. На ломовом битрейте и mpeg2 некоторым - кодек.

> Разве что какой-нибудь ангажированный фанатик, который не понимает, что
> некорректно уже устаревшие H264 и H265 с AV1 сравнивать,

H.265 появился примерно в те же времена что AV1. А то что на AV1 кодеры налегли и довели до ума - этим от 265 и отличается. Кто будет вон те инновации до ума доводить я тоже не знаю. А оно кому-то на этих условиях сильно надо? Что-то мне подсказывает что "пользователи" зажлобятся работу кодеров оплачивать. Особенно несколько лет к ряду, чтобы довести до ума более менее. Ибо кодек на 10% спеки и на 90% имплементация. Так что патентовщики могут идти нахрен, они хотят сделав 10% работы получить 100% бабок. Это называется лохотроном. Ублажать таких "за идею" особенно когда можно вместо этого комитить в альтернативные проекты - хм, какое заманчивое предложение! Сделать 90% работы, нифига не получить, а патентные тролли за свои 10% постригут купоны. Удачи в таком бизнесе, кодеры за столько времени все же немного перестали лохов изоюражать. Все как вы и хотели вроде? И теперь помогать будут тем кто помогает в ответ. А к некооперативным халявщикам и вымогателям будет другой подход =)

> но что не сделаешь ради идеи "нагибания
> гнусных патентных троллей". Ведь если с 266 сравнить, то профита может
> и не быть даже по соотношению битрейта к качеству.

Ну сравните. Только вот учитывая вон то выше - сомневаюсь что там будут чудеса. Зато ободрать за патенты небось опять попытаются. Да и истеричное строгание кодеков исой как бы намекает что их обставили и, видимо, патроны пообещали оставить этих чудил без грантов...

> А мне в равной степени насрать на корпов типа Google, так и
> на троллей. Две копейки переплатить за железку я могу, и поэтому
> на мой выбор открытость не влияет никак. Google же предлагает запрыгивать
> на поезд AV1, не дождавшись прихода VVC и независимых тестов.

А я не собираюсь отстегивать кому-то за решения дороже и хуже. Более того - нужда явно лицензировать что-то например на серваках или где там еще - делает все сильно неудобнее. Так что вы там и переплачивайте, если оно вам надо. И сервируйте себе это сами заодно. Потому что сотни гимора с финансовыми документами на ровном месте мне вообще не хочется.

Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

244. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 14-Ноя-23, 00:50 
> Так там и битрейт какой?! Думаю AV1 будет отлично выглядеть и на заметно меньшем битрейте. А мелкий битрейт - лучше всего хайлайтит отличия между кодеками. На ломовом битрейте и mpeg2 некоторым - кодек.

Конечно, кодек. Ведь его на всех DVD используют, а толк от AV1, если в нем только ютуб-видео будут. Да и в принципе только новый контент, а весь огромный пласт старого - в проприетарных.
> Ну сравните. Только вот учитывая вон то выше - сомневаюсь что там будут чудеса.

Допустим, чудес не будет, но все равно это не определяет выбор в пользу AV1 среди ЮЗЕРОВ. И да, юзеры не коммитят ни в какие кодеры, и им нет цели видео кому то отдавать, вот и прыгать на AV1 не спешат. Статистика торрент-трекеров тому пример.

Ответить | Правка | К родителю #240 | Наверх | Cообщить модератору

252. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 14-Ноя-23, 15:13 
> Конечно, кодек. Ведь его на всех DVD используют,

У меня DVD приводов не осталось по сути уже. Кодирование в мпег2 меня не интересует.

> а толк от AV1, если в нем только ютуб-видео будут.

Я им для себя пользуюсь через сабжа+libaom, скажем размеры мувиков с всяких девайсов с камерой в разы сдуваю без какого-то особого визуального ущерба. На кодеках не написано кому, почему и для чего ими пользоваться. Для чего хочу - для того и пользуюсь. Забыв гугла спросить. Впрочем, гугол по своему полезен, у него есть примеры достаточно эффективных вариантов кодирования, в том числе и под режим "fire and forget".

> Да и в принципе только новый контент, а весь огромный пласт старого - в проприетарных.

Ну так на какой H.264 троллота уже и подзабила с отжимом денег, переключившись на более новые. Кодек позапрошлого поколения же. Но для себя его юзать?! А мне надо в 2 раза более жирные файлы и бандвиз по сети, с тем же качеством картинки? Ну вот и ответ. Это само по себе денег стоит.

>> Ну сравните. Только вот учитывая вон то выше - сомневаюсь что там будут чудеса.
> Допустим, чудес не будет, но все равно это не определяет выбор в
> пользу AV1 среди ЮЗЕРОВ.

Да мне похрену, я выбираю из доступных опций и чем привлекательнее условия и лучше технические параметры тем вероятнее что я буду использовать именно это. А если кому-то что-то не нравится он может писать в спортлото. Платить за них в 2 раза больше за бандвиз или строиться под причуды проприетарщиков за мои же деньги я не буду.

> И да, юзеры не коммитят ни в какие кодеры, и им нет цели видео кому то отдавать, вот
> и прыгать на AV1 не спешат. Статистика торрент-трекеров тому пример.

Я не кодирую релизы вареза на торент трекеры -> мне вообще пофиг на этот кейс.

Ответить | Правка | К родителю #244 | Наверх | Cообщить модератору

163. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (163), 13-Ноя-23, 06:27 
70% просмотров ютуба — это как раз бомжи с мобилками.
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

166. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 08:10 
Должны наслаждаться артефактами, я считаю. А учитывать их интересы - это какое то сумасшествие и мазохизм. Из-за этого у нас и нет сервисов, где был бы стриминг с нормальным битрейтом, что все равняются на бомжей с мобилками. Да еще и выдумывают какие то специальные кодеки, чтобы бомжам было не так больно (будто бы они на своих экранчиках вообще видят разницу), а страдают в итоге все остальные.
Ответить | Правка | Наверх | Cообщить модератору

209. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (209), 13-Ноя-23, 19:30 
Тут такое дело: ютуб живёт с рекламы. И будет действовать в интересах тех, кто эту рекламу смотрит. А не 1% элиты с гигабитным каналом (которая ещё и прошаренная, и разных адблоков себе поустанавливала). И да, мобилка у «бомжа» зачастую стоит дороже, чем ваш кудахтер целиком:)
Ответить | Правка | Наверх | Cообщить модератору

220. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 21:06 
Это все понятно, но интересы свои у вас есть? Вы, 1% элиты, линуксом почему то пользуетесь, а не покорно платите майкрософту за лицензию.

>И да, мобилка у «бомжа» зачастую стоит дороже, чем ваш кудахтер целиком:)

Тем более обидно им должно быть. Если железо тянет, то дома можно хоть блюреи по сети стримить, а не жалкие 1Mbps с ютуба.

Ответить | Правка | Наверх | Cообщить модератору

231. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 22:49 
> Это все понятно, но интересы свои у вас есть? Вы, 1% элиты,
> линуксом почему то пользуетесь, а не покорно платите майкрософту за лицензию.

Почему-то если засетапить свои серваки, интересы начинают подозрительно напоминать гугловские. Как то - заплатить за это все поменьше. Засервировать этим всем - побольше. В этом смысле AV1 весьма хорошо смотрится. Более того - я проверял, другие обладатели серверов считают так же. Почему-то когда вопрос в том чтобы оплачивать банкет из своих, все что-то очень сообразительные и горой за эффективные технологии. Что бы это могло быть? :)

>>И да, мобилка у «бомжа» зачастую стоит дороже, чем ваш кудахтер целиком:)
> Тем более обидно им должно быть. Если железо тянет, то дома можно
> хоть блюреи по сети стримить, а не жалкие 1Mbps с ютуба.

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

Назло гуглу поставить себя любимого на бабки? Клевая идея, вы это и сделайте :)

Ответить | Правка | Наверх | Cообщить модератору

238. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 23:55 
> Почему-то если засетапить свои серваки, интересы начинают подозрительно напоминать гугловские.

Повторюсь, да нам в РФ вообще положить на патенты, это пускай буратины держат серваки там, где их имеют тролли и копирасты.

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

Я стримлю у себе в локалке напрямую с торрентов, в тч и для членов своей семьи. Не г*вном же с одноклассников и ютуба их кормить.


Ответить | Правка | Наверх | Cообщить модератору

241. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 14-Ноя-23, 00:22 
> Повторюсь, да нам в РФ вообще положить на патенты, это пускай буратины
> держат серваки там, где их имеют тролли и копирасты.

Ну тогда и серваки вы там себе поставите, реализации кодеков способные хотя-бы AV1 побить - напишете, как я понимаю? Ну или кто это будет делать? И за чей счет будет банкет? А, кодек еще неплохо бы в софт интегрировать. Нахрен кому сферический кодек в вакууме?

> Я стримлю у себе в локалке напрямую с торрентов, в тч и
> для членов своей семьи. Не г*вном же с одноклассников и ютуба их кормить.

И как, много H.266 или чего там у вас по задумке AV1 побивает насервирвоали то? И в какой конфиге?

А я транскод в AV1 c всяких камерообразных практикую - H.26x делаемый этим добром очень рыхлый, особенно H.264, и его можно в разы убавить по весу перегнав в AV1 - а визуально разницу вообще хрен заметишь. При том учитывая панические релизы H.26x - время жизни AV1 кажется получится гораздо приятнее, ибо мощный кодек с хорошим заделом на уровне формата.

Ответить | Правка | Наверх | Cообщить модератору

245. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 14-Ноя-23, 01:09 
>Ну или кто это будет делать? И за чей счет будет банкет? А, кодек еще неплохо бы в софт интегрировать. Нахрен кому сферический кодек в вакууме?

Если поддерживать инициативы гугля, то тогда действительно, всему миру придется смотреть AV1, даже там, где на патенты класть хотели. А если не заниматься поддержкой монополиста, то гуглю придется самостоятельно поддержку своих новомодных кодеков продвигать, и тогда VVC может взять вверх по итогу. От чего все, кроме американских корпов, могут только выиграть. Или нет, но в любом случае, американские патенты - это не причина всему остальному миру гуглю в продвижении своих идей помогать, пускай страдают там сами.
> И как, много H.266 или чего там у вас по задумке AV1 побивает насервирвоали то?

В том то и дело, что не нужен никакой транскод (в AV1 или куда то еще), если канал достаточно жирный и вафля не у соседа в гараже стоит.

Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

253. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 14-Ноя-23, 15:59 
> Если поддерживать инициативы гугля, то тогда действительно,

Мне вполне по пути с идеей тратить меньше бабок на бандвиз и хранение мувиков.

> всему миру придется смотреть AV1, даже там, где на патенты класть хотели.

Отмораживать уши назло бабушке? Ваши - ок! Мои - черта с два!

А то что благодаря отсутствию патентных терок накодированое в webm можно в веб выложить на свой сервак и играться везде будет - фича. Более важная для меня чем DVD и блюреи.

> А если не заниматься поддержкой монополиста, то гуглю придется самостоятельно
> поддержку своих новомодных кодеков продвигать,

На вид делает мою жизнь сложнее и дороже, позволяя каким-то проприетариям выкручивать мне руки. Это мне зачем? ISO 10 лет саботировал видео в интернете. Задолбали. Пусть идут нафиг с такими "стандартами".

> и тогда VVC может взять вверх по итогу.

Боюсь что стандарты цель которых - развод меня на оплату (в основном амерских) патентов меня не интересуют. Особенно глядя как это работало прошлые 10 лет. ISO себя дискредитировал вдрызг, посмотрим что AOM  сможет. Конкуренция полезная штука. Morning gentlemens ;)

> От чего все, кроме американских корпов, могут только выиграть.

Это как я "выигрываю" от оплаты роялтей даже в китайских чипах и гимора с проигрыванием видео в браузерах?!

> миру гуглю в продвижении своих идей помогать, пускай страдают там сами.

Когда сможете какие-то более осмысленные варианты, которые еще и работают, не создавая проблем, тогда и поговорим.

>> И как, много H.266 или чего там у вас по задумке AV1 побивает насервирвоали то?
> В том то и дело, что не нужен никакой транскод (в AV1
> или куда то еще), если канал достаточно жирный и вафля не
> у соседа в гараже стоит.

Ну вот нет, гнать видео снятое всякими девайсами с камерой нахрен надо. Там кодек реалтайом сильно ограничен и поток рыхлый. Его даже тем же кодеком можно в пару раз сдуть без визуальных потерь. А кодеком посильнее, типа AOM и раза в 3-4. Вы в своем праве оплачивать сервировку не транскодированого видео - из своих. Я за вас это делать не буду.

Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

256. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (256), 14-Ноя-23, 17:20 
> Должны наслаждаться артефактами, я считаю. А учитывать их интересы - это какое
> то сумасшествие и мазохизм. Из-за этого у нас и нет сервисов,
> где был бы стриминг с нормальным битрейтом, что все равняются на
> бомжей с мобилками. Да еще и выдумывают какие то специальные кодеки,
> чтобы бомжам было не так больно (будто бы они на своих
> экранчиках вообще видят разницу), а страдают в итоге все остальные.

Вы за платные видеосервисы, правильно понимаю?
Кодеки придумывают для того, чтобы битрейт был ниже при том же качестве картинки. Поэтому "бомжи" и их "экранчики" не при чём.

Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

258. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 14-Ноя-23, 18:22 
Когда ты монополист, то можешь хоть в каком всратом качестве контент отдавать, не особо обращая что там у конкурентов. Почему у ютуба самый низкий битрейт из всех популярных хостингов? Потому что он жадным - монополист, только и всего. И дело не в кодеке, можно было и AV1 отдавать в лучшем качестве.
Ответить | Правка | Наверх | Cообщить модератору

303. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 17-Ноя-23, 13:29 
> Когда ты монополист, то можешь хоть в каком всратом качестве контент отдавать,
> не особо обращая что там у конкурентов. Почему у ютуба самый
> низкий битрейт из всех популярных хостингов? Потому что он жадным -
> монополист, только и всего. И дело не в кодеке, можно было
> и AV1 отдавать в лучшем качестве.

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

И пока у конкурентов их добро лагает, тормозит, дергается, перематывается полчаса и теряет буфер, ютуб просто работает. И такие "мелочи" (ничего себе мелочи!) бесят юзерей намного больше. А так все хорошо, прекрасная маркиза.

Ответить | Правка | Наверх | Cообщить модератору

39. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +2 +/
Сообщение от Аноним (39), 11-Ноя-23, 17:21 
Мертвый тяжелый кодек, который в железе уже реализован интелом, амудёй и нвидией?
Надо бы им рассказать, что он мертвый, а то они не догадываются.

"Все, сворачиваемся, мы не подумали про космическую радиацию" (с)

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

72. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (-), 11-Ноя-23, 19:52 
> H.265 более чем взлетел.

Куда он взлетел?! Из за конских отчислений и сразу нескольких конкурирующих пулов патентной троллоты, в паре с техническим отставанием от AV1 - всей этой троллоте пришлось смачно утереться и пролететь в куче стандартов. Особенно в вебе.

> В нём ~100% profession HDR content.

И фиг бы с ним - это 99% людей не увидят вообще никогда. И им всем глубоко похрен на 0.001% маргиналов и что там у них за супер-форматы. В более-менее массовые стандарты H.265 как раз и не попал в результате. При том этот привет ISO и патентной троллоте передали так то сами корпорасы, достаточно посмотреть кто в Open Media Alliance вписался.

А можно и не смотреть. А посмотреть как фирма ARM лихо комитит - тадам - в AV1. Да и VP1 и FFMPEG до кучи окучивает слегка, раз пошла такая пьянка. Ну а чего, продажи ядер улучшение софтварных кодеков - толкает. Значит фирме ARM оно надо - так их ядра привлекательнее клиентам. А x265 вообще полтора маргинала пилит, "где-то там".

> AV1, кроме как на YouTube/NetFlix, нет нигде.

На минутку, 95% пользаков на планете именно там видео и смотрят.

> Мёртвый тяжёлый кодек, чтобы Google сэкономила 2 копейки.

H.265 и на 5% от этого масштаба не используется. Да и вон та парочка - почти монополисты, остальные чисто технически лохи полные и конкурировать не способны.

Россияне пыжатся вон альтернативы делать. Только там максимум H.264, с совершенно ломовым битрейтом (==затыки при любом удобном случае, от перегруза сети, серверов и чего там), голимой артефачащей картинкой, диким жором трафика (привет мобильный интернет!) и прочими прелестями. Гугл аж трясется как осиновый лист с таких супер-технологий вещания. А H.265 играться внезапно и не будет. Сюрприз!

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

85. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (31), 11-Ноя-23, 21:22 
> На минутку, 95% пользаков на планете именно там видео и смотрят.

От этого менее ущербными открытые кодеки не становятся. Но вам лишь бы какой кал, лишь бы 2 копейки троллям не перепало.
>  А H.265 играться внезапно и не будет. Сюрприз!

И вы этому рады до усрачки, что вам VP9 суют вместо 265 и AV1 вместо 266...

Ответить | Правка | Наверх | Cообщить модератору

149. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 12-Ноя-23, 23:18 
> От этого менее ущербными открытые кодеки не становятся. Но вам лишь бы
> какой кал, лишь бы 2 копейки троллям не перепало.

Просто для понимания я собрал распоследнего ffmpeg, av1, vp9, x264 и x265 из гита да погонял это все side by side. Стоит сказать что меня не интересуют всякие перверсии типа аниме - так что гонял я это на более менее киношном контенте, или RAW которые воон там у xiph лежат (внимание, огормные файлы) - да и сравнил как мне оно.

У AV1 почему-то при одинаковом визуальном качестве картинки самые мелкие файлы получаются. А если у него врубить еще дополнительный турбо-чит описаный на doom9 как то форсировать HBD режим процессинга даже для "обычного" 8 бит YUV 4:2:0 - он еще процентов десять бандвиза срежет как с куста. Правда, ценой на 30-40% большего времени кодирования, но и выигрыш почтенный и там этот ваш 265 вообще оказывается ни о чем.

Да, AV1 медленно жмет но я для жирных мувиков научился tiled encoding юзать и speed поднимаю до 3. Вопрос: а чего б мне и не порадоваться что мне очень крутой кодек на халяву подогнали? Заодно можно выкладывать мувики на моих серверах. Никому ничего не выплачивая. И это будет играться у юзерей. И мой повод для расстройства в этом состояни дел - например что?!

>>  А H.265 играться внезапно и не будет. Сюрприз!
> И вы этому рады до усрачки, что вам VP9 суют вместо 265
> и AV1 вместо 266...

У меня нет самоцели раскормить всех патентных троллей на планете. И ничего такого суперского я в H.265 для себя не нашел чтобы за него еще и платить, когда AV1 есть, на мой вкус это double-win когда кодек и жмет лучше и бесплатный. А патентной троллоте - приветы! Пусть планируют на диету сесть. Ибо так то кодеки может печь не только ISO и судя по тому что я вижу - кроме 266 в разработке то и AV2 еще бывает. И конкуренция оборзелой троллоте - то что доктор прописал.

Более того - я счатаю что стандарты существуют для интероперабельности, а не для того чтобы какие-то вымогатели ставили всех на бабки. Если ISO не может это обеспечить - окей, а зачем он тогда нужен?!

Ответить | Правка | Наверх | Cообщить модератору

151. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 00:27 
>кроме 266 в разработке то и AV2 еще бывает. И конкуренция оборзелой троллоте - то что доктор прописал.

Это не здоровая конкуренция, это выламывание рук со стороны Google и ко. Потому что даже если AV2 будет окажется технически хуже, то все равно они будут использовать его, а не 266 (или 267, если он окажется доступен), потому что им это выгодно. Поэтому они и разрабатывают ОТКРЫТЫЕ кодеки, что победить "троллей поганых" в честной конкуренции не так и просто.

Ответить | Правка | Наверх | Cообщить модератору

153. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 00:55 
> Это не здоровая конкуренция, это выламывание рук со стороны Google и ко.

Враг моего врага - мой союзник. Та троллота хотела выламывать руки мне, под требованием компплайнса с "стандартом". Я должен сожалеть о участи кондомов, прикрывающих вымогателство стандартами? Ох, как мне жалко то... что горе-стандартизаторы не скопытились еще раньше и не освободили дорогу тем кто будет стандарты юзать для стандартизации и interop. Потому что стандарты для вымогательства - нафиг не упали. Из за таких "стандартизаторов" у нас был головняк с полу-недо-работающим видео в вебе. И так более десяти лет. Когда там майкрософт тег <video> запилил то? Я уж и забыл. Но теперь этот фееричный булшит таки в прошлом. За десять лет гемора господ давно пора призвать к ответу по всей строгости. И это вовсе и не достижение было. Сюрприз!

> Потому что даже если AV2 будет окажется технически хуже, то все
> равно они будут использовать его, а не 266 (или 267, если

Технология не подвешена в сферическом вакууме и странно оценивать ее без условий использования. А рестриктивные условия так то сгубили немало технологий. Если ISO хочет пойти по этой дорожке - тем хуже для ISO, имхо.

> он окажется доступен), потому что им это выгодно. Поэтому они и
> разрабатывают ОТКРЫТЫЕ кодеки, что победить "троллей поганых" в честной конкуренции не
> так и просто.

Мне тоже выгодно ничего не отстегивать левым троллям, какая неожиданность. А серваки у меня много где есть.

Ответить | Правка | Наверх | Cообщить модератору

156. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 01:08 
> Мне тоже выгодно ничего не отстегивать левым троллям, какая неожиданность. А серваки у меня много где есть.

А у меня нет, и мне положить на тех, у кого они есть, как и 99%. Нам надо наилучший из возможных кодеков в вебе, да и везде, а тот, кто согласен на меньшее, тот идет на поводу у гугля и прочих корпов, продвигающих открытые кодеки, независимо от их качества (потому что так им выгодно).

Лучше переплатить доллар и иметь аппаратную поддержку самого лучшего кодека (согласно независимым тестам), чем сэкономить и довольствоваться поддержкой открытых. AV1 не помешает, но дайте мне и другие альтернативы, не надо закапывать их.

Ответить | Правка | Наверх | Cообщить модератору

173. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (173), 13-Ноя-23, 12:20 
> Нам надо наилучший из возможных кодеков в вебе

Ты за это платить не готов. Вот и гугль не хочет.

> Лучше переплатить доллар и иметь аппаратную поддержку самого лучшего кодека

Ха.. даже если забыть про "высер про самый лучший", то платить-то тебе надо не только за хард, но и за каждое видео на ютупе и нетфликсе, которое будет перекодировано в "самый лучший кодек". Готов платить по "доллару" с каждого просмотренного на ютупе видео? Или сейчас ты резко решишь, что "пускай гугл платит"?

Ответить | Правка | Наверх | Cообщить модератору

190. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 15:14 
Ясен пень, пускай гугель платит, ведь он рекламу сует в бесплатные видео, а нетфликсы и так не бесплатные.
Ответить | Правка | Наверх | Cообщить модератору

219. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 20:54 
> Ясен пень, пускай гугель платит, ведь он рекламу сует в бесплатные видео,
> а нетфликсы и так не бесплатные.

Ну дык. И даже так отбить затраты на кучу бандвиза и серверов - довольно тяжко. Так что свои причуды вы и оплачиваете сами. Хотите коммерческий кодек? Круто, купите его и жмите в него. Сервера не такие? Отлично - оплатите какие вам там надо и будет по вашему. Заодно и узнаете сколько обслуживание вашей ценной тушки стоит. А когда каждый второй юзер с вашем 265 будет делать мозг что оно еще и не играется - ну вот сами и разбирайтесь с ними. Или сапорт наймите. Или что там.

Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

221. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 21:10 
Ублюдочный гугл пускай платит вместе со всеми остальными корпорастами. Или переносит свою контору в Сомали.
Ответить | Правка | К родителю #219 | Наверх | Cообщить модератору

225. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 22:01 
> Ублюдочный гугл пускай платит вместе со всеми остальными корпорастами. Или переносит свою
> контору в Сомали.

А иначе - что? Какой-то Аноним (31) с опеннета их смотреть не будет? Все, гипс снимают, заявление на банкротство подают, не иначе.

А програмеры тоже себе, своим фирмам и проч неудобно делать - не будут. И они так то не в Сомали. И даже не в РФ. Боее того - роялти на чипы даже чайна отстегивает, и, конечно, взымает с покупанов чипарей. Не будут же они за вас оплачивать это вымогалов?! За счет покупателя то - еще куда ни шло.

Ответить | Правка | К родителю #221 | Наверх | Cообщить модератору

239. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 14-Ноя-23, 00:04 
Майкрософт тоже подает на банкротство ведь вы не пользуете его шиндовс и не платите. А, это не в ваших интересах? Ну вот и интереса гугля с моими не совпадают, ваши кстати тоже не особо, прежде чем пугать патентами хотелось бы посмотреть хоть на один случай, где любителя постримить в h265 для друзей нагнули патентные тролли. Не слышал о таком.
Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

242. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 14-Ноя-23, 00:28 
> Майкрософт тоже подает на банкротство ведь вы не пользуете его шиндовс и
> не платите. А, это не в ваших интересах?

Да мне похрен так то что с майкрософтом случится. Ну, если они красиво скопытятся, пусть меня позовут, на могилке потанцевать. Я достаточно попартнерил с оными чтобы захотеть вернуть им некий фавор.

> Ну вот и интереса гугля с моими не совпадают, ваши кстати тоже не особо,

С моими интересами я и без всяких хренов с опеннета разберусь. И идея платить поменьше а сервировать побольше - нравится не только гуглу.

> прежде чем пугать патентами хотелось бы посмотреть хоть на один случай,
> где любителя постримить в h265 для друзей нагнули патентные тролли. Не
> слышал о таком.

Для начала напугали все браузеры так что поддержка H.26x в браузерах - полный бардак! А вот делать из чужих проблем свои мне нахрен нужно, если это можно избежать. С AV1 всего этого крапа нет. Он просто играется. В почти всем что шевелится уже на данный момент. И гимора с ним сильно меньше чем с 265. Про 264 еще можно порассуждать но это легаси кодек позапрошлого поколения, которого вот тут показательно сделали по битрейту В ДВА РАЗА.

Ответить | Правка | К родителю #239 | Наверх | Cообщить модератору

243. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 14-Ноя-23, 00:42 
Ну вот, пугал, пугал патентными троллями тех, кто терабайтам голивудское кинцо выкачивает (уже смешно), а оказывается, и необязательно ничего платить, если даже в штатах за это не бутылят.
> Для начала напугали все браузеры так что поддержка H.26x в браузерах - полный бардак!

Поэтому надо запилить еще один кодек, чтобы вместо одного было 2 конкурирующих. Типичный гугл-вей. И плевать, что остальным (проприетарщикам) он не упал. Гугл выкручивает руки всем не реализуя поддержку h265 в Chrome на должном уровне, а виноваты тролли, которым гугл не хочет платить.

Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

266. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 14-Ноя-23, 23:51 
> Ну вот, пугал, пугал патентными троллями тех,

Да они так то - развели весь глобус на отчисления в железе, вплоть до последнего китайского soc - и им то норм. А вот я не понимаю почему я должен платить крышевикам MPEG LA при том что кодек они вообще не разрабатывают: x264 вообще другие люди кодили. При том это все с меня взыщет даже полуподваольный китаец. С него это взыскал создатель IP блока декодера, а себе в минус работать никто не будет.

Немного отвалили от веббраузеров - цыска как-то договорилась свой стремнокодек нашару всем ставить. Но их кодек - кусок Г, тормознее VP9 в декодировании, мыло жуткое, вообще не оптимизированная помойка.

Ну и 264 мне вот прям ща интересен - как divx 3. Легаси кодек. Он даже VP9 не может побить. А уж AV1 - вон там анон расчертил что получается. Файло в ДВА раза меньше при равном качестве.

> кто терабайтам голивудское кинцо выкачивает (уже смешно),
> а оказывается, и необязательно ничего платить, если даже в
> штатах за это не бутылят.

Там циска как-то впряглась за браузеры для H.264 но из них такие софтваршики что получилось "как обычно с 264" - т.е. такое качество реализаци что этот позор и даром не надо. Если есть более приличные реализации, например, сабж, браузеры их умеют подхватывать. Но это все же не решает на 100% проблему качественного, шустрого, беспроблемного восрпоизведения. И мы говорим о легаси которое сейчас как DIVX3 примерно. Если вам надо это - пользуйтесь. А я не мусорный бачок для полупроприетарной срани. Особенно когда можно нормальный кодек нашару взять и играется везде. При том мне все равно сколько и чего вы у голивуда спиратили. Меня интересует чтобы у тех кто на мой серв зайдет видео играло без гимора, вовсе не. Чтобы просто выложить мувик, без делания мне мозга проблемами.

>> Для начала напугали все браузеры так что поддержка H.26x в браузерах - полный бардак!
> Поэтому надо запилить еще один кодек, чтобы вместо одного было 2 конкурирующих.

Его таки более-менее прожали в все мало-мальски актуальные браузеры. И это работает. Чем и хорошо. Можно более менее уповать что клиент это умеет. И это не ставит его на бабки и не заставляет качать кривой супертормоз цискин полублоб и что там еще за УГ. За вот это вот весь ISO надо было давно расформировать к хренам. Десять лет такого позора - это за гранью. Такие "стандарты" мне не требуются.

> Типичный гугл-вей. И плевать, что остальным (проприетарщикам) он не упал. Гугл
> выкручивает руки всем не реализуя поддержку h265 в Chrome на должном
> уровне, а виноваты тролли, которым гугл не хочет платить.

Да вот знаете, все это извращение надоело уже даже и корпам. Посмотрите кто в AOM входит. Думаю что ЭТИ свое - отспорят. И троллей таки построят, а ISO либо принципиально сменит политику, либо пойдет стандарты на выпечку пончиков фигачить. На остальных можно с чистой совестью забить. Пусть делают что хотят, они ни на что не влияют. Если помрут - ну, минус какие-то скунсы, и хрен с ними. Я точно скучать по ним не буду. Чего мне скучать по создателям проблем и рекетирам?

Ответить | Правка | К родителю #243 | Наверх | Cообщить модератору

274. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 15-Ноя-23, 03:01 
> Там циска как-то впряглась за браузеры для H.264
> Его таки более-менее прожали в все мало-мальски актуальные браузеры

На лицо прямо таки упорное желание лезть в бутылку. Сперва злые проприетарщики не дают стримить в H265 бедным юзерам. Теперь вот проприетарщики не дают разработчикам браузеров обеспечить поддержку. Хотя все браузеры, кроме лисы, уже давно умеют H265, но почему то это не лисы проблемы и её эффективных менеджеров, а проприетарщики опять виноваты. Да и причём тут вообще блоб для H264, который лишь для WebRTC используется. Кстати в лисе многие до сих пор ставят h264fy, чтобы ускорение было на ютубе, ведь VP9 их железка не умеет, так что спасибо им, что хоть 264 реализовали, блин.

Ответить | Правка | К родителю #266 | Наверх | Cообщить модератору

286. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 15-Ноя-23, 18:25 
> На лицо прямо таки упорное желание лезть в бутылку.

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

> Сперва злые проприетарщики не дают стримить в H265 бедным юзерам. Теперь вот
> проприетарщики не дают разработчикам браузеров обеспечить поддержку.

Там не столько проприетарщики сколько патентные тролли. Но они имеют кое что общее. Идиотские рестрикции на ровном месте. Але, гараж! Если хочется чтоб технология была повсеместной - ее придется таки дать нашару. Что не отменяет возможность делать коммерческие решения под специфичные сценарии, обслуживать интересы крупных клиентов, или что там. А когда начинается вон то - возникает вопрос, правда ли эти - офигенные и незаменимые?! AOM дал ответ: "незаменимых не бывает".

> Хотя все браузеры, кроме лисы, уже давно умеют H265,

Они так "умеют" что в половине случаев надо "хардварный декодер у юзера". Соответственно, если сервить в этом - задолбают. И я не понимаю смысл в 265, когда есть AV1 который и жмет лучше и без таких проблем. Похоже 265 мертворожденная технология.

> но почему то это не лисы проблемы и её эффективных менеджеров, а проприетарщики
> опять виноваты.

Скорее, патентные тролли. Но в конечном итоге я не буду делать из чужих проблем - свои. AV1 мне это обеспечивает более-менее. Чем и крут.

> Да и причём тут вообще блоб для H264, который лишь для WebRTC используется.

Он IIRC и для остального используется как декодер - если ничего лучше в системе нет. Но во первых работает хреново. Во вторых нужда заниматься такой порнографией кодек не украшает. А для легаси позапрошлого поколения выглядит издевательством над здравым смыслом. А назвать этот крап "легаси позапрошлого поколения" можно благодаря AV1, показавшему что сделать крутой современный кодек можно без исо и супер-технологий мпеглы.

> Кстати в лисе многие до сих пор ставят h264fy, чтобы ускорение было на
> ютубе, ведь VP9 их железка не умеет, так что спасибо им,
> что хоть 264 реализовали, блин.

Мало ли какие перверсии на свете бывают. Это вообще не технический аргумент за технологию.

Ответить | Правка | К родителю #274 | Наверх | Cообщить модератору

186. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 14:45 
> А у меня нет, и мне положить на тех, у кого они есть, как и 99%.

Ну, понимаешь, в сухом остатке:
- Вы будете драть друг другу глотки. Суммарный эффект: куча порваных м...ков.
- Я с моими серверами прожму сколько-то юзерей. Суммарный эффект: технологии немного сдвинутся в ту сторону, потому что я тоже впрягся их обеспечивать.

А вот что вы там делали в своей норке - всем и правда пофиг, если это в сеть не вывешено, хоть MPEG на CD записывайте, мне не жалко покуда это все меня никак не импактит. А в вебе вы 265 мало куда вывесить сможете, особенно чтобы хостинг его еще и не транскодировал. На своем то серваке я могу кодирование сам прогнать как мне угодно, а на чужом хостинге будете кушать что дали и никуда не денетесь. А им там тоже сильно надо патентопроблемы разгребать и прочее "видео не играется", при том что разработчиков кодека полтора калеки, фирмачи типа ARM вместо этого на AV1 налегают и проч.

> Нам надо наилучший из возможных кодеков в вебе, да и везде, а тот, кто согласен
> на меньшее, тот идет на поводу у гугля и прочих корпов, продвигающих открытые кодеки,
> независимо от их качества (потому что так им выгодно).

Я лучше буду подыгрывать тем чьи интересы совпадают с моими, чем платить каким-то левым хмырям непонятно за что в формате левого рекета. И еще и кодек кодьте себе сами, дескать. А зачем такой стандарт надо? Это для меня дороже и хуже получается. Мой интерес тут в чем?

> Лучше переплатить доллар и иметь аппаратную поддержку самого лучшего кодека
> (согласно независимым тестам), чем сэкономить и довольствоваться поддержкой
> открытых. AV1 не помешает, но дайте мне и другие альтернативы, не надо закапывать их.

Я сам в состоянии билдануть ffmpeg с последними версиями либ да сделать тесты без "независимых" экспертов прикормлеными теми или иными корпами. При том сразу на том что я кодировать заинтересован а не чем-то абстрактном. И посмтрев как AV1 в Q-mode делает самые мелкие файлы при том же качестве - особенно если в HBD режиме кодить даже LBD контент - я не догоняю зачем мне весь тот гимор надо. Если тем пользователям надо - вот они пусть и фигачат! А, у них "серверов нет"? Тогда пусть заткнутся и жрут что дают. Веб это мир свободных людей, тут никто никому ничем не обязан и все держится на добровольном взаимодействии.

Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

193. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 15:40 
> - Вы будете драть друг другу глотки. Суммарный эффект: куча порваных м...ков. Я с моими серверами прожму сколько-то юзерей.

Хватит выдумывать. Никаких серваков у нас, юзеров, нет, поэтому никакие глотки мы драть не будем. И пойдём смотреть видео не к вам, кто на нас решил сэкономить, а в другое место значит. Пускай такие "добродетели" убьются об стену, раз они не думают о том, что хотят юзеры, а только о своей прибыли пекутся. Вот они и есть м-ки. Сперва нам рекламу суют и платить заставляют, а потом еще и контент в убогом качестве отдают.
> А, у них "серверов нет"? Тогда пусть заткнутся и жрут что дают.

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

Ответить | Правка | Наверх | Cообщить модератору

195. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 15:54 
> Хватит выдумывать. Никаких серваков у нас, юзеров, нет, поэтому никакие глотки мы
> драть не будем. И пойдём смотреть видео не к вам, кто
> на нас решил сэкономить,

А вы и не были моей целевой аудиторией, это вообще больше побочная фишка для друзей, которые так то вокруг опенсорса и линухов кучкуются. Им и должно быть удобно прежде всего. Остальное вообще side effect.

И вообще, идите стребуйте чего-нибудь с гугла, амазона, эпла, нетфликса и проч. Не забудьте рассказать как это все получилось. Они по моему вообще на мнение пользаков, как бы это, когда юзерей миллионами, там плюс-минус десяток вообще ничего не решает. И даже пару процентов может быть выгоднее отбрить, чем выплачивать роялти всякие.

> а в другое место значит. Пускай такие "добродетели" убьются об стену, раз они
> не думают о том, что хотят юзеры, а только о своей прибыли пекутся.

Вы в вашем праве пойти воооон туда и требовать с них что вам там удобно. Я правда сомневаюсь что это хорошо работает. Так что де факто будете кушать что дадут.

> Вот они и есть м-ки. Сперва нам рекламу суют и платить заставляют, а потом
> еще и контент в убогом качестве отдают.

Вы в вашем праве не пользоваться сервисами которые вам не нравятся. Кстати TV тоже рекламу кажет, да еще и перемотать на нужное время так сразу - нельзя. Но пипл даже такое смотрит.

>> А, у них "серверов нет"? Тогда пусть заткнутся и жрут что дают.
> Нет, это пускай поехвашие линуксоиды заткнутся и идут нафиг со своим около
> религиозным фанатизмом. Общество - это НЕ вы, нечего за нормальных людей
> решать, что им надо.

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

Вон там гражданин график вывесил где AV1 по битрейт-качество делает всех. В случае H264 еще в ДВА РАЗА к тому же. Если кто хочет на вас в 2 раза больше трафа лить - флаг ему в руки. За 4 года с тех пор соотношения разумеется стали еще жестче в пользу AV1. Там видите ли у гугли, ARM и проч пипл на фултайме теперь кодек улучшают, кроме энтузиастов.

Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

197. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (31), 13-Ноя-23, 16:17 
> И вообще, идите стребуйте чего-нибудь с гугла, амазона, эпла, нетфликса и проч.
> Не забудьте рассказать как это все получилось. Они по моему вообще
> на мнение пользаков, как бы это, когда юзерей миллионами, там плюс-минус
> десяток вообще ничего не решает. И даже пару процентов может быть
> выгоднее отбрить, чем выплачивать роялти всякие.

Вот я об этом и говорю, что они не лучше, чем те "тролли" о которых вы говорите. То, что корпы кинули подачку в виде AV1 не желает их от этого пушистей. Вот пускай и платят отчисления.
Но есть разница между "для друзей постримить" и "миллиарды видео жать для широкой публики". В первом случае, я не против открытых кодеков, но продвигают их не для вас и не за этим, а как доминантов в вебе. Странно это не понимать.
>В случае H264 еще в ДВА РАЗА к тому же. Если кто
> хочет на вас в 2 раза больше трафа лить - флаг
> ему в руки.

Гугл волнует соотношение качество-трафик, а меня лишь качество. Все равно фильмы будем качать с торрентов в h264 или h265, а не ютуба.

Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

211. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 19:37 
> Вот я об этом и говорю, что они не лучше, чем те
> "тролли" о которых вы говорите. То, что корпы кинули подачку в
> виде AV1 не желает их от этого пушистей. Вот пускай и платят отчисления.

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

> Но есть разница между "для друзей постримить" и "миллиарды видео жать для
> широкой публики". В первом случае, я не против открытых кодеков, но продвигают
> их не для вас и не за этим, а как доминантов в вебе. Странно это не понимать.

А по моему гугл сделал вполне честно - чтобы стримить для миллиардов срубая денег, впрягся в создание технологии. Это куда более честный подход чем какой-то левый рекет с патентами, когда кодеки пишут одни а бабки стригут почему-то левые MPEG LA и прочие нужные структуры, не замеченные в производстве чего либо кроме рэкета.

> Гугл волнует соотношение качество-трафик, а меня лишь качество. Все равно фильмы будем
> качать с торрентов в h264 или h265, а не ютуба.

Меня тоже волнует соотношение битрейт-качество. Видео занимают довольно много места, да и возможность зааплоадить их по сети - фича. А аплоадить в 2 раза больше - весьма такое себе.

Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

86. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Прохожий (??), 11-Ноя-23, 21:25 
> это 99% людей не увидят вообще никогда
> 95% пользаков на планете именно там видео и смотрят

А остальные 5% что и где?


> Из за конских отчислений и сразу нескольких конкурирующих пулов патентной троллоты

Ты так переживаешь, как будто из собственного кармана платишь. А ведь эта экономия до тебя, как конечного пользователя, не доходит от слова "совсем". Где же оседают эти бабки, спрашивается? Эти бабки оседают в карманах тех самых корпораций, которые ты, видимо, ненавидишь.

> патентной троллоты

"Патентные тролли" не совсем уместный термин в данном случае. Потому что создать новый кодек, превосходящий по характеристикам предыдущий - это совсем не то же самое, что застолбить какое-то название, или придумать, как мышкой левой ногой по экрану возить. Люди сделали хороший кодек, люди хотят заработать. Тебе-то что, собственно?

> В более-менее массовые стандарты H.265 как раз и не попал в результате.

Что значит "массовые стандарты"? HEVC/H.265 поддерживается на следующих устройствах:
iPhone 7 или новее
iPad Pro или новее
Samsung Galaxy S8/S8+ или новее
Samsung Galaxy Note 8 или новее
Google Pixel 2 или новее
OnePlus 6T или новее
Moto G9 или новее
Redmi Note 8 или новее
Huawei Mate 9 или новее
Huawei P9 или новее
Vivo V20 или новее

Считай практически ВЕСЬ рынок мобильников поддерживает H.265. Если это не массовость, что тогда массовость?

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

91. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 21:42 
Не знал, что даже мой древний ванплас его умеет.
>Люди сделали хороший кодек, люди хотят заработать. Тебе-то что, собственно?

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

Ответить | Правка | Наверх | Cообщить модератору

146. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от anonymous (??), 12-Ноя-23, 19:00 
> Люди сделали хороший кодек, люди хотят заработать. Тебе-то что, собственно?
> Люди доказали новую теорему, хотят заработать. Тебе-то что, собственно?

Не всякие способы заработка полезны для общества.

Патентовать математику, а алгоритмы (не реализации) - и есть математика - это троллинг. Весьма для общества вредный. Правильно, что его игнорируют.

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

150. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 00:12 
Гугель и прочие нетфликсы заботят только бабки. Тупо выгодно оказалось свое разработать, чем отчисления платить.
Ответить | Правка | Наверх | Cообщить модератору

187. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 14:58 
> Гугель и прочие нетфликсы заботят только бабки. Тупо выгодно оказалось свое разработать,
> чем отчисления платить.

Отлично, в этом месте нам с ними по пути. Можно даже комитов накидать, чтобы не иметь дел с вон той шушерой, офигевшей в край. Когда работы работают одни, что в написании кодека, что в хостинге, а купоны стригут какие-то совсем левые хрены. Вы на таких условиях и фигачьте, мистер!

Ответить | Правка | Наверх | Cообщить модератору

196. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 15:57 
Ну и норм. Не мне же им "коммиты кидать", пускай этим занимаются другие на каких угодно условиях. Я пользователь, и мне главное - конечный результат.
Ответить | Правка | Наверх | Cообщить модератору

215. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 20:37 
> Ну и норм. Не мне же им "коммиты кидать", пускай этим занимаются
> другие на каких угодно условиях. Я пользователь, и мне главное -
> конечный результат.

Вот лично мой опыт показывает что у AV1 результат - весьма даже. Мягко говоря. Де факто более удачный кодек по битрейт качество я просто не назову. А умникам из MPEG LA и прочих ISO пусть кто хочет тот и кодит кодек, имхо. И я сомневаюсь что предложения заплатить еще и бабок за супер-пупер право кодить в этом формате добавит ему популярности. Платить денег непонятно за что, при том что никто даже конкретные преимущества назвать не может? Хм, удачи в продажах.

И вообще - в технологиях имеет слово тот кто их создает и имплементит. Вы никак не заставите их делать то что им дорого, неудобно, криво, хреново и проч. Разве что "сделай сам". Но как блаблабла пользователь вы походу лишены этой возможности. Тем хуже для вас, можете искать тех кто будет вас хостить с вашими пожеланиями, удачи в поисках.

Так то конечно любой каприз - но исключительно за ВАШИ деньги. Если вы платите - вам хоть мпег2 нарулят. Где вы возьмете денег на оплату бандвиза и серваков на хранение, если это окажется кому-то надо - уже ваши сложности, соответственно.

Ответить | Правка | Наверх | Cообщить модератору

224. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (31), 13-Ноя-23, 21:18 
Будет результат, когда я на торрентах скачаю кинцо в AV1 с нормальным битрейтом и не придется корчиться, как сейчас от ютубовских видео.

Ответить | Правка | Наверх | Cообщить модератору

175. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (173), 13-Ноя-23, 12:34 
> Ты так переживаешь, как будто из собственного кармана платишь.

Лол, а кто платит? Или по твоему деньги у гугла не от рекламодателей, а у тех - не от потребителей, которые эту рекламу (показанную гуглом) и смотрят и потом покупают товары/услуги?
Расходы на рекламу включены в стоимость рекламируемых товаров и услуг. Если ты покупаешь ЛЮБОЙ товар или услугу, которая где-то когда-то платно рекламировалась - то ты платишь за эту рекламу производителю товара/услуги (а тот часть этих денег переводит (помимо прочих) и гуглу). Даже если персональны ты эту рекламу не смотрел ни разу всё равно за неё платишь.
Так что деньги в карман гугла кочуют (хоть и не напрямую, а в пару "прыжков") из карманов именно тех, кто рекламируемые на гугле товары/услуги и приобретает/потребляет (оплачивает).

> Люди сделали хороший кодек, люди хотят заработать. Тебе-то что, собственно?

Это нормально. Ну пока они покупателей добровольно находят. Кстати, где я могу купить телефон без поддержки h.xxx с ценой соответственно меньше? А, понятно... Ну тогда сорян, ну вот ты и плати. Гугл не хочет и чувак которомы ты пишешь не хочет. И вот я что-то не хочу принудительно платить за кодек, которым может и не планирую пользоваться. Налог Мигалкова в мире кодеков.

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

182. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 14:04 
>> это 99% людей не увидят вообще никогда
>> 95% пользаков на планете именно там видео и смотрят
> А остальные 5% что и где?

Мало ли, торенты, двачи, вимео всякие, и чего там еще маргинального и нонеймового я забыл.

> Ты так переживаешь, как будто из собственного кармана платишь.

А из чьего же? :) В конечном итоге за все платит пользак. И если кого поставили на роялти, это будет слуплено с покупана. До последнего цента. Разработчики, производители и проч не будут из своих платить, за кого вы их принимаете?!

А у меня еще и серваки в интернете есть и я в гробу видал идею доплачивать какой-то троллоте за право там мувики хостить. Так что они могут валить со своими супер-кодеками и роялтями туда где не светит солнце.

> А ведь эта  экономия до тебя, как конечного пользователя, не доходит от слова "совсем".

Я вообше не потребитель. Я создаю контент, разрабатываю, у меня серваки в интернете, а еще я вот кодированием видео при помощи сабжа нехило развлекаюсь.

> Где же оседают эти бабки, спрашивается? Эти бабки оседают в карманах
> тех самых корпораций, которые ты, видимо, ненавидишь.

Моя идентификация friend or foe работает по совсем иным критериям. Кто помогает достичь моих целей и задач - тот и friend. Кто мешает, саботирует, рекетирует и проч - foe. Формальный лейбл не важен, важен результат. И кроме всего прочего я хочу играть видео в вебе без отчислений всяким левым пудакам.

>> патентной троллоты
> "Патентные тролли" не совсем уместный термин в данном случае. Потому что создать
> новый кодек, превосходящий по характеристикам предыдущий - это совсем не то
> же самое, что застолбить какое-то название, или придумать, как мышкой левой
> ногой по экрану возить.

Примерно один хрен - большая часть тех алгоритмов достаточно общеизвестна. А поскольку абстракции штука забавная то обычно еще и находится 100500 способов делать что-то наподобие, только еще и лучше - и не нарушая патент. Если задаться этой целью. Вот разработчики AV1 такой целью задались и судя по результатам тестовых забегов этой штуки - нехило утерли патентным троллям нос. Во всяком случае почему-то у AV1 с равным качеством самые мелкие файлы получаются. Ради чего с кодеками все и трахаются, собственно, в конечном то итоге.

> Люди сделали хороший кодек, люди хотят заработать. Тебе-то что, собственно?

1) Меня несколько напрягает когда это называют стандартом и начинают вымогательствовать. ИМХО либо уж interop, либо обслуживание интересов нескольких жлоборасов. Взаимоисключающие параграфы!
2) Пойнт платить за более плохой кодек, когда можно не платить, за хороший, более активно развиваемый, как комьюнити так и корпами - мне не понятен. Я не считаю это офигенным результатом работинга за который стоит платить.

>> В более-менее массовые стандарты H.265 как раз и не попал в результате.
> Что значит "массовые стандарты"? HEVC/H.265 поддерживается на следующих устройствах:

И что этот десяток девайсов доказывает? AV1 поддерживается почти всеми современными чипсетами и поэтому список устройств с ним - не влезет в лимиты форума, имхо, а если даже если и нет, то у современных девайсов хватит проца и в софте сожрать интернетовский битрейт. Тем более что фирма ARM сейчас просто героически AV1 оптимизит, и кодеры, и декодеры, да и VP9 до кучи бонусом достается.

> Считай практически ВЕСЬ рынок мобильников поддерживает H.265. Если это не массовость, что
> тогда массовость?

Возможность играть видео без гимора на более-менее всех клиентах, конечно. В случае AV1 она есть, а h.265 в вебе вообще не жилец.

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

33. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +4 +/
Сообщение от Аноним (33), 11-Ноя-23, 16:56 
>H265 не взлетел

В пиратских видео (где пофиг на патенты) - очень даже взлетел. И h.266 там же взлетит, когда кодеки завезут.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

38. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 17:17 
Они все о бедных корпорациях переживают, чтобы те отчисления не платили. Предлагают использовать ущербные альтернативы, но профессионалы знают, что лучше, поэтому держатся от них подальше.
Ответить | Правка | Наверх | Cообщить модератору

73. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 11-Ноя-23, 19:55 
> Они все о бедных корпорациях переживают,

Кроме бедных корпораций, гадать не удумают ли патентные тролли мне навесить за хостинг видео на моем серваке - так себе идея. Да и играться в вебе 265 всяко не будет. Вы же не делали двигун браузера. Его делал гугл. Даже для левых клонов типа яндексбраузеров всяких, которые суть форк хрома с немного перепиленой мордочкой и добавлением местных зондов в пару гугловым. Ну вот и выбирайте. А, ну можете вот файрфокс выбрать, но им с их 5% веба платить за патенты всяким MPEG LA тоже жаба душит. Так что это вы там сами как-нибудь.

Ответить | Правка | Наверх | Cообщить модератору

88. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Прохожий (??), 11-Ноя-23, 21:36 
> Да и играться в вебе 265 всяко не будет.

Это почему же?

Десктопные браузеры с поддержкой H.265: Chrome (версия 107 и позднее), Microsoft Edge (версия 16 и позднее),  Safari (версия 11 и позднее).

Мобильные браузеры с поддержкой  H. 265: Chrome (версия 107 и позднее), Safari for iOS (версия 11.0 и позднее).

Ответить | Правка | Наверх | Cообщить модератору

106. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 22:04 
И почему то, например, амазону не впадлу платить отчисления и релизить новый контент в prime video в h.265.
Ответить | Правка | Наверх | Cообщить модератору

201. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 16:28 
> И почему то, например, амазону не впадлу платить отчисления и релизить новый
> контент в prime video в h.265.

Ну а я не амазон - и мне впадлу. Так что с амазона и требуйте что вам там удобно. Мне вон то просто не выгодно.

Ответить | Правка | Наверх | Cообщить модератору

208. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 17:23 
Переноси хостинг в РФ и будет насрать, как и всем остальным в нашей стране, где всем положить на проблемы американских корпораций.
Ответить | Правка | Наверх | Cообщить модератору

217. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 20:42 
> Переноси хостинг в РФ и будет насрать, как и всем остальным в нашей стране,

Спасибо, но я как-нибудь пешком постою. Это вы как-нибудь без меня, вон там у вас супер-убийцы ютуба, кушайте не обляпайтесь. Конечно же полные днища по битрейт-качество и икают еще жестче чем вимео. Одно дело хотеть, и совсем другое - мочь.

> где всем положить на проблемы американских корпораций.

А что, россияне уже производят чипы с декодерами этого добра чтобы роялти не платить? И софт пишут, чтобы проблем с этого не иметь?

Ответить | Правка | Наверх | Cообщить модератору

222. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 21:13 
Так никто и не видит проблем с отчислением двух копеек за поддержку качественного кодека, тем более, на смартфонах и ноутах, где автономность имеет значение.


Ответить | Правка | Наверх | Cообщить модератору

232. Скрыто модератором  +/
Сообщение от Аноним (-), 13-Ноя-23, 22:56 
Ответить | Правка | К родителю #222 | Наверх | Cообщить модератору

237. Скрыто модератором  +/
Сообщение от Аноним (31), 13-Ноя-23, 23:47 
Ответить | Правка | К родителю #232 | Наверх | Cообщить модератору

264. Скрыто модератором  +/
Сообщение от Аноним (264), 14-Ноя-23, 22:25 
Ответить | Правка | К родителю #237 | Наверх | Cообщить модератору

265. Скрыто модератором  +/
Сообщение от Аноним (31), 14-Ноя-23, 23:38 
Ответить | Правка | К родителю #264 | Наверх | Cообщить модератору

267. Скрыто модератором  +/
Сообщение от Аноним (-), 15-Ноя-23, 00:13 
Ответить | Правка | К родителю #265 | Наверх | Cообщить модератору

135. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 12-Ноя-23, 06:57 
В браузерах обычно нет декодеров H.265, потому что за них пришлось бы платить отчисления. Но за аппаратные декодеры в видеокарте Nvidia, Intel и AMD уже всё заплатили. Под поддержкой в Chrome и Edge имеется в виду частичная (можешь перепроверить на caniuse) поддержка в виде API для аппаратного декодера. Есть аппаратный кодек в видеокарте - есть H.265 в браузере. Нет - нет.
Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

184. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 14:25 
>> Да и играться в вебе 265 всяко не будет.
> Это почему же?

Потому что платить за патенты мало кто хочет. И ставить своих юзерей на бабки тоже.

> Десктопные браузеры с поддержкой H.265: Chrome (версия 107 и позднее), Microsoft Edge
> (версия 16 и позднее),  Safari (версия 11 и позднее).

Во первых не вижу файрвокса! Во вторых, как минимум в линухе что файрфокс что хромиум обломаются так сразу. А я так то сам линух использую и иллюстрировать картину "сапожник без сапог" уж точно не собираюсь. Если я заплатил за сервак - сервировать меня любимого по высшему разряду он просто обязан. К тому они все и AV1 прекрасно сожрут. Только его и еще много кто сожрет бонусом, потому что не стоит вопрос с патентной троллотой.

И декодер AV1 понапихали уже почти везде, а 265 только в топовых девайсах. Потому что роялти платить надо и довольно много, дешевые процы так делать нерентабельно. Ублажить 10% жирных клиентов в ущерб остальным - махохизм, выбирая между тем сделает ли мозг несколько клиентов или основная масса - ну вы поняли.

> Мобильные браузеры с поддержкой  H. 265: Chrome (версия 107 и позднее),
> Safari for iOS (версия 11.0 и позднее).

Я рад за них и все такое. Можете кодировать в 265, если вам это надо. Мне и с AV1 неплохо оказалось. Впрочем, поскольку "у вас нет серверов" - мне вообще до 314ды во что вы будете кодировать - я с этим никогда не повстречаюсь. Хоть в MPEG2 или что там, для меня ничего не изменится. И как вы там с клиентами и их проблемами разбираться будете - не мои грабли. Я не вижу у 265 никаких понятных мне достоинств, зато вижу ряд дурных проблем, импактящих в том числе и меня.

Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

103. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 21:59 
> Вы же не делали двигун браузера. Его делал гугл.

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

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

185. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 14:27 
> Так вот пускай гугл его и двигает, раз ему это выгодно, но
> я не вижу тут интересов юзеров. В интересах юзеров, чтобы наиболее
> качественный формат был наиболее распространенный, а не наиболее открытый. Ну или
> чтобы хотя бы был выбор.

Юзеров вообще не будет никто спрашивать. Они не сетапят серваки, не гоняют траф, не хостят контент, не решают траблы с "не играется видео" и мозг грызут в саппорте или где там не им.

Так что если кому-то зачем-то H.265 надо - вот он все это и сетапит. За свой счет. И решает вон те проблемы сам. Если понимает зачем все это надо.

Ответить | Правка | Наверх | Cообщить модератору

40. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +3 +/
Сообщение от Denys (??), 11-Ноя-23, 17:26 
На трекерах уже сжимают через AV1, а h266 и в помине нет
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

41. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (41), 11-Ноя-23, 17:29 
будут кодеки - будут и сжимать.
Ответить | Правка | Наверх | Cообщить модератору

93. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Прохожий (??), 11-Ноя-23, 21:48 
Какой смысл сжимать в AV1, который хуже, чем H.265? Тем более, на нелегальном контенте. Там априори никто никому ничего не платит.
Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

97. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 21:53 
Я поискал и нашёл больше рипов в VP9, чем в AV1. Но 265 все равно больше в разы. И почему то мне кажется, что скорее релизеры перейдут на 266, чем на AV1.
Ответить | Правка | Наверх | Cообщить модератору

105. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Прохожий (??), 11-Ноя-23, 22:03 
VP9 вообще не встречал ни разу. Впрочем, меня интересовал в последнее время только контент в 4k. Все фильмы были закодированы в h.265
Ответить | Правка | Наверх | Cообщить модератору

44. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Ivan_83 (ok), 11-Ноя-23, 18:08 
Только из за толп нытиков у которых программно ничего выше 480p не декодируется потому что проц унылый, а аппаратно они умеют 264, иногда 265 и ещё немного более старого.
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

49. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (31), 11-Ноя-23, 18:39 
265 рипы необязательно лучше 264, они меньше, только и всего.
Ответить | Правка | Наверх | Cообщить модератору

60. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (20), 11-Ноя-23, 19:31 
> 265 рипы необязательно лучше 264, они меньше, только и всего.

Они всегда хуже. Потому что нельзя взять и уменьшить битрейт в 50 раз. Все вопросы к тем, кто таким занимается. Ремуксы идут в HEVC тоже. Только у них нормальные цветопередача, достаточные битрейт и детальность кодирования, в том числе динамических сцен.

Ответить | Правка | Наверх | Cообщить модератору

90. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (90), 11-Ноя-23, 21:41 
А не надо в 50 по сравнению с 264. Даже вдвое - уже отлично.
Ответить | Правка | Наверх | Cообщить модератору

101. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (20), 11-Ноя-23, 21:58 
По сравнению с чем? С контентом, адово пожатым в h264 (и хорошо если нормальным кодеком)? Зато если оставить размер файла ровно тем же, качество ощутимо вырастет. При этом, кодировать надо с исходника, а исходник только у студии, поэтому мыльные файлы в интернете в любом случае не показательно. А вдвое блюрей пожать и h264
Ответить | Правка | Наверх | Cообщить модератору

133. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 12-Ноя-23, 06:23 
Ну ёкарный бабай, ты саботируешь сравнение кодеков. Не крути все ручки сразу. Даже две не крути. Не говори, что надо покрутить ручки, до которых невозможно дотянуться. Сравни x264 и x265, настроенные на максимальное качество, определись с метриками, определись с требуемым качеством, получи небольшую экономию битрейта при одинаковом качестве. Да, не будет там никаких 50% и придётся с мылом воевать (ну, так раньше было).
Ответить | Правка | Наверх | Cообщить модератору

141. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (20), 12-Ноя-23, 11:12 
С мылом не надо воевать, его надо принять. Можно подлить _достаточно_ битрейта, чтобы его не было избыточно. Если битрейт идёт не туда, неплохая идея отключить любые психовизуальные оптимизации. А вот с артефактами avc ничего не сделать (хотя психовизуальные оптимизации тоже надо отключать, это же ад из артефактов с ними) и он просто хуже кодирует, особенно это видно на динамических сценах. Разрыв намного больше, если исходник уже не идеален (т.е. когда его битрейт не по-настоящему заоблачный или вообще лосслесс), тут x265 легко рвёт x264 и libvpx-vp9 libaom соответственно, после чего x265 унижает libvpx-vp9 и x265 это ещё плохонький кодер. Но даже его достаточно, чтобы уничтожить все "бесплатные" кодеки.
Ответить | Правка | Наверх | Cообщить модератору

89. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Прохожий (??), 11-Ноя-23, 21:40 
> они меньше, только и всего

Дык в этом и есть основной смысл любого кодека, работающего с пользовательским контентом - уменьшать объём так, чтобы качество не страдало по сравнению с предыдущим кодеком.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

95. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 21:49 
С этим никто не спорит, но исходим из текущих реалий. Пока качественных релиз-групп, которые используют 265, почти нет, а возможно и не будет уже (тк появится новый кодек).
Ответить | Правка | Наверх | Cообщить модератору

99. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Прохожий (??), 11-Ноя-23, 21:57 
Как это нет, если я только в этом формате и смотрю кинцо?
Ответить | Правка | Наверх | Cообщить модератору

107. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 22:09 
Основная масса контента все еще в 1080p, а не 4K.
Ответить | Правка | Наверх | Cообщить модератору

109. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Прохожий (??), 11-Ноя-23, 22:16 
И как же ты это подсчитал, интересно? Я вот только в 4k и смотрю. Никаких проблем не было с его наличием. И формату уже не первый год, новые телеки только такими и выходят, даже самые дешманские.

Да, старые фильмы до какого-то года - там сплошь и рядом FullHD. Но и это потихоньку исправляется. Рынок, как я уже написал выше, насыщен техникой, способной воспроизводить 4k.

Ответить | Правка | Наверх | Cообщить модератору

43. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Ivan_83 (ok), 11-Ноя-23, 18:06 
Вы упускаете огромный пласт технологий где h.265 взлетел и до сих пор летает - DVB и всякие блюреи.
DVB это все телеки и всё что може принимать наземное, кабельное, спутниковое и мобильное ТВ.

Всякие ператы на трекерах до сих часто делают h.264 потому что полно нытиков у которых телек или их супер мега дорогой аппаратный плеер к телеку умеет только его, AV1 рипов очень мало, думаю ещё и потому что кодировать в него затратно: пока ты в него кодируешь все успеют выкать 264/265 релизы по несколько раз.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

45. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (45), 11-Ноя-23, 18:15 
>кодировать в него затратно: пока ты в него кодируешь все успеют выкать 264/265 релизы по несколько раз.

1. ничто не мешает кодировать по нарастающей. Сначала юелать релиз быстрым кодеком, чтобы быть первым, а уже потом - более сжимающим, чтобы сэкономить место и траффик

Ответить | Правка | Наверх | Cообщить модератору

46. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 18:34 
>сэкономить место и траффик

Нужно лишь индусам, которые не могут позволить себе не только нормальный безлимитный интернет, но и ПК. А потому им и 700мб рипы норм, тк смотрят они их со смартфонов.

Ответить | Правка | Наверх | Cообщить модератору

48. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Ivan_83 (ok), 11-Ноя-23, 18:38 
Про место вы зря, у меня домашнее видео имеет неприличный битрейт в 100 мегабит только потому что в камере такой аппаратный энкодер, я бы с удовольствием пережал это всё гденить до 10-20 мегабит и освободил пару сотен гигабайт.
Ответить | Правка | Наверх | Cообщить модератору

51. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 11-Ноя-23, 18:41 
Что же вас останавливает?
Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Ivan_83 (ok), 11-Ноя-23, 18:46 
Сложно разобратся со всеми параметрами которые надо скормить ffmpeg чтобы качественно перекодировать, у меня в этом нет экспертизы.
Ответить | Правка | Наверх | Cообщить модератору

67. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от onanim (?), 11-Ноя-23, 19:39 
ffmpeg -i input.mp4 -b:v 10M output.mp4
Ответить | Правка | Наверх | Cообщить модератору

69. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от onanim (?), 11-Ноя-23, 19:42 
ещё надо -c:a copy, чтобы звук оригинальный оставить.
итого
ffmpeg -i input.mp4 -b:v 10M -c:a copy output.mp4
если качество не нравится, попробовать 20M
Ответить | Правка | Наверх | Cообщить модератору

188. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 15:04 
> ffmpeg -i input.mp4 -b:v 10M output.mp4

Это мягко говоря очень неоптимальный вариант кодирования по соотношению битрейт-качество.

1) Если кодировать для себя а не в сеть - Q-mode намного более хорошая идея.
2) Если надо чтобы в сеть лезло, тогда constrained-Q mode, примерно как первое но с clamp на максимум битрейта во избежание затыков. Это уже годится для bulk-transcode в режиме fire and forget но в интенсивных сценах может дать более плохую картинку.
3) 2-pass куда как лучше по достигаемому битрейт-качество. А по времени первый проход у сабжа очень резвый, можно и процессинг аудио скипнуть заодно, разница с 1-pass небольшая а вот файло при равном качесте куда меньше. Единственное исключение - реалтайм стримы так, конечно, не получится в реалтайме то.
4) Параметры кодека при этом могут быть довольно винтажненькие и субоптимальные/консервативные.

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

98. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Прохожий (??), 11-Ноя-23, 21:56 
Спроси у ChatGPT или у Google Bard. Они оба знают более-менее. Сам так делал, когда надо было.
Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

161. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноньимъ (ok), 13-Ноя-23, 04:46 
> Сложно разобратся со всеми параметрами которые надо скормить ffmpeg чтобы качественно перекодировать,
> у меня в этом нет экспертизы.

Вы анонима ниже не слушайте главное, он бяку советует.

Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

53. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (31), 11-Ноя-23, 18:45 
Сейчас все "продвинутые" пираты имеют терабайты хранилища, какая им разница на экономию в пару гигов. Главное, где лучше качество. Поэтому аудитория ресурсов с "маленькими" рипами - нищуки, в основном. Ну или те, кому на качество положить.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

59. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (59), 11-Ноя-23, 19:28 
> Сейчас все "продвинутые" пираты имеют терабайты хранилища, какая им разница на экономию
> в пару гигов. Главное, где лучше качество.

Качество одинаковое при меньшем размере. Экономия гигов - больше контента влезет, быстрее скачается - нужно.

Ответить | Правка | Наверх | Cообщить модератору

84. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 21:05 
Выбор обычно стоит между относительно качественными 264-рипами и 265 с ультра-маленьким размером и низким качеством. Потому что крайне мало 265-групп, которые бы делали упор на качество, а не на вес. А бывает, что качественных вообще нет и лучше ремукс.
Ответить | Правка | Наверх | Cообщить модератору

144. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от anonymous (??), 12-Ноя-23, 13:43 
нет оригинала ни у тех ни у других пиратов, они оба два используют уже пережатый материал где уже отброшено огромное количество информации. Потому и кажется что якобы 265 не может делать лучше.
Ответить | Правка | Наверх | Cообщить модератору

47. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Ivan_83 (ok), 11-Ноя-23, 18:35 
Мешает.
Скорее всего там нет фермы для кодинга, и пока AV1 будет всё ещё кодировать то что выпустили в 265 нужно будет уже что то другое релизить.
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

52. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 11-Ноя-23, 18:42 
> Скорее всего там нет фермы для кодинга, и пока AV1 будет всё ещё кодировать то что выпустили в 265

265 сравним по скорости с AV1. AV1 медленнее, но не в разы.

Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 18:49 
AV1 рипов мало потому что всех и h.265 пока устраивает, а значит нет особого смысла тот же самый контент кодировать дважды.
Ответить | Правка | Наверх | Cообщить модератору

63. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 11-Ноя-23, 19:35 
> AV1 рипов мало потому что всех и h.265 пока устраивает

Вы где эти h265 рипы вообще видите? Их единицы.


Ответить | Правка | Наверх | Cообщить модератору

81. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 20:48 
На зарубежных трекерах.
Ответить | Правка | Наверх | Cообщить модератору

104. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Прохожий (??), 11-Ноя-23, 22:00 
Да ладно. Каждое кинцо в формате 4k кодируется в h.265. Других и не помню кодеков, чтобы для этого формата использовались.
Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

125. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 12-Ноя-23, 00:20 
> Да ладно. Каждое кинцо в формате 4k кодируется в h.265. Других и
> не помню кодеков, чтобы для этого формата использовались.

Да. Для 4к.

Ответить | Правка | Наверх | Cообщить модератору

164. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (163), 13-Ноя-23, 06:33 
Ищем на рутрекере «hevc» — упираемся в лимит в 500 результатов. Ищем то же на руторе — упираемся в лимит в 2000 результатов. Вы там это, анабиоз прерывайте хоть изредка.
Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

172. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 13-Ноя-23, 11:46 
> Ищем на рутрекере «hevc» — упираемся в лимит в 500 результатов. Ищем то
> же на руторе — упираемся в лимит в 2000 результатов. Вы там это,
> анабиоз прерывайте хоть изредка.

Сколько останется если убрать ремуксы и webdl?

И какое отношение к h264 раздачам?

Ответить | Правка | Наверх | Cообщить модератору

155. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 01:05 
> 1. ничто не мешает кодировать по нарастающей. Сначала юелать релиз быстрым кодеком,
> чтобы быть первым, а уже потом - более сжимающим, чтобы сэкономить
> место и траффик

Вы только что раскрыли know how ютуба :). Они сперва кодируют в VP9 и (low end) h.264. А потом уже AV1 нарезают, чем "горячее" контент тем быстрее его в AV1 перегоняют.

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

50. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 11-Ноя-23, 18:40 
> Всякие ператы на трекерах до сих часто делают h.264 потому что

На 1080p h264 даёт лучшие результаты, у него сотни оптимизаций которые в h265 так и не перетащили до сих пор. А совместимость идёт бонусом.

В 4k и прочих извращениях, да, h265 работает получше.
Но, тут уже входит в игру популярность 4к, который всем очень нужен оказывается, особенно смотрящим 4к стриминг нетфликса с битрейтом 5Мб/с, амуриканцы на реддите уже прохавали этот момент и выкупают обратно проданные до этого железные блюрей плееры.

> думаю ещё и потому что кодировать в него затратно: пока ты в него кодируешь все успеют выкать 264/265 релизы по несколько раз

Отсутствие оптимизированных AV1 кодеков основное препятствие конечно для всяких риперов, но это постепенно фиксят. В остальном вопрос за аппаратными кодировщиками, всякие стримеры смартфоны и прочее.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

56. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 18:56 
>4к стриминг нетфликса с битрейтом 5Мб/с

Так у 1080p он там еще ниже. Получается, им как раз и нужен 4K?

Ответить | Правка | Наверх | Cообщить модератору

61. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноньимъ (ok), 11-Ноя-23, 19:32 
>>4к стриминг нетфликса с битрейтом 5Мб/с
> Так у 1080p он там еще ниже. Получается, им как раз и
> нужен 4K?

1080p с битрейтои в 5Мб будет качественнее 4к с битрейтом 5Мб.

Шутка в том что весь этот 4к в стримах - пшик.


Нормальный битрейт для 4К - 144Мб/c, если сжимать хорошо и правильно без совместимости с железными плеерами то можно до 50 сжать, но с оговорками. Потому как чудес не бывает в природе от слова совсем.
Если у вас мыльная 3д графика то можно ужать сильнее, если зернистая плёнка то без мыла не получится.

На 5Мб нетфликса - это мыло сплошное если не квадраты.

Ответить | Правка | Наверх | Cообщить модератору

71. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от noc101 (ok), 11-Ноя-23, 19:45 
> Нормальный битрейт для 4К - 144Мб/c

И где ты такой битрейт видел?

Ответить | Правка | Наверх | Cообщить модератору

115. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноньимъ (ok), 11-Ноя-23, 23:56 
>> Нормальный битрейт для 4К - 144Мб/c
> И где ты такой битрейт видел?

На блюрей дисках. Гугл.

Ответить | Правка | Наверх | Cообщить модератору

122. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (24), 12-Ноя-23, 00:16 
Вы в глаза видели такой диск хоть раз? В большинстве случаев речь идет максимум о 50 Mb/s, а иногда и того меньше для релизов "попроще".
Ответить | Правка | Наверх | Cообщить модератору

126. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –2 +/
Сообщение от Аноньимъ (ok), 12-Ноя-23, 00:43 
> Вы в глаза видели такой диск хоть раз? В большинстве случаев речь
> идет максимум о 50 Mb/s, а иногда и того меньше для
> релизов "попроще".

50 GB диски имеют битрейн 72 или 92 Mб/с

66 GB и 100 GB - 92Mб/с или 123Мб/с или 144Mб/с.

UHD блюреев с 50Мб/с битрейтом не существует.

Ответить | Правка | Наверх | Cообщить модератору

130. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноним (24), 12-Ноя-23, 04:38 
Википедию я тоже читать умею, спасибо. Речь о том, что существует в реальном мире. Я вот, например, имею небольшую коллекцию блюрей-дисков и знаю, какой там битрейт. И кучу ремуксов качал, то тоже видел их битрейт.
Ответить | Правка | Наверх | Cообщить модератору

179. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от noc101 (ok), 13-Ноя-23, 13:12 
>> Вы в глаза видели такой диск хоть раз? В большинстве случаев речь
>> идет максимум о 50 Mb/s, а иногда и того меньше для
>> релизов "попроще".
> 50 GB диски имеют битрейн 72 или 92 Mб/с
> 66 GB и 100 GB - 92Mб/с или 123Мб/с или 144Mб/с.
> UHD блюреев с 50Мб/с битрейтом не существует.

Ты путаешь чтение диска и битрейт.
https://www.sony.ru/electronics/support/articles/00190648
Не позорься больше

Ответить | Правка | Наверх | Cообщить модератору

271. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноньимъ (ok), 15-Ноя-23, 00:40 
Чатжпт что ты несёшь?
Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

279. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от noc101 (ok), 15-Ноя-23, 10:43 
> Чатжпт что ты несёшь?

Как сложно быть глупым. Прими мои соболезнования.
Я для тебя скинул официальный документ, где расписаны битрейты. Но тебе нравится ходить обосранным. Ходи дальше.

Ответить | Правка | К родителю #271 | Наверх | Cообщить модератору

138. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от noc101 (ok), 12-Ноя-23, 09:14 
>>> Нормальный битрейт для 4К - 144Мб/c
>> И где ты такой битрейт видел?
> На блюрей дисках. Гугл.

Интересно, наверное мои блюреи не правильные, не видел ни разу такого битрейта...

Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

139. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 12-Ноя-23, 10:41 
> Интересно, наверное мои блюреи не правильные, не видел ни разу такого битрейта...

Нам всем не страшно не повезло, ведь наш стандарт блюрея ограничивает максимальный битрейт на 100 Мбит/с, а евоный - нет.

Ответить | Правка | Наверх | Cообщить модератору

178. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от noc101 (ok), 13-Ноя-23, 13:11 
>> Интересно, наверное мои блюреи не правильные, не видел ни разу такого битрейта...
> Нам всем не страшно не повезло, ведь наш стандарт блюрея ограничивает максимальный
> битрейт на 100 Мбит/с, а евоный - нет.

Я понял! Я понял!! Я понял!!!
Он перепутал битрейт и скорость чтения диска! Лол

Ответить | Правка | Наверх | Cообщить модератору

180. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (180), 13-Ноя-23, 13:42 
Если ты понял три раза, то и умножай 144 на три, получишь скорость чтения.
Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

191. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от noc101 (ok), 13-Ноя-23, 15:31 
Слушай!!! Спасибо тебе! У меня теперь битрейт поднялся до 432Мбит!!! Я теперь смотрю видео в 16К!
Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

213. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (180), 13-Ноя-23, 19:52 
Спасибо мало. Теперь тебе придётся поделиться монитором - добавленные пиксели моя интеллектуальная собственность. Корпус можешь оставить себе.
Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

254. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от noc101 (ok), 14-Ноя-23, 16:03 
> Спасибо мало. Теперь тебе придётся поделиться монитором - добавленные пиксели моя интеллектуальная
> собственность. Корпус можешь оставить себе.

У меня виртуальные пиксели! Бери все! Мне не жалко! ))

Ответить | Правка | К родителю #213 | Наверх | Cообщить модератору

80. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноним (-), 11-Ноя-23, 20:40 
> Нормальный битрейт для 4К - 144Мб/c, если сжимать хорошо и правильно

Может, вам вообще RAW фреймы с диска гнать? NVME может даже попытаться осилить это в реалтайме. Ну или зафиг нам кодеки если такие потоки брать? Для гарантированого лосслеса нежатые фреймы самое то.

Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

116. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 11-Ноя-23, 23:59 
Бредить ненужно. Таблетки пить нужно. И всё у вас будет хорошо.

Можно ещё с диалап интернета на адсл перейти, и вайфай домой поставить хотябы n стандарта.

Ответить | Правка | Наверх | Cообщить модератору

158. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноним (-), 13-Ноя-23, 01:08 
> Бредить ненужно. Таблетки пить нужно. И всё у вас будет хорошо.
> Можно ещё с диалап интернета на адсл перейти, и вайфай домой поставить
> хотябы n стандарта.

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

А перейти с чего там на чего там - да окей, вооооооон там в той же РФии есть куча мест где операторы точно не откажутся от спонсора новых БСок чтобы битрейт разогнать. Потому что 30 хомяков в селе усть-пердищенск будут отбивать стоимость соты чуть менее чем вечность.

Ответить | Правка | Наверх | Cообщить модератору

165. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (163), 13-Ноя-23, 06:39 
Вообще с головой хватит и SATA.
Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

202. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 16:31 
> Вообще с головой хватит и SATA.

Для 4K то? Оно уже на 1080p @ 30FPS впритык так то...

Ответить | Правка | Наверх | Cообщить модератору

212. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (209), 13-Ноя-23, 19:48 
1080p@30 24-bit — ≈1,5 гигабит/с.
Да, 4К уже упрётся в интерфейс. Но это если видео будет в 4:4:4.
Ответить | Правка | Наверх | Cообщить модератору

214. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (180), 13-Ноя-23, 20:02 
>> Нормальный битрейт для 4К - 144Мб/c, если сжимать хорошо и правильно
> Может, вам вообще RAW фреймы с диска гнать?

А вот кстати. Если количество пользователей в разы больше, чем количество кадров во всём потоке. Интересно получается. Даже если сопоставимо, то достаточно синхронизировать малость. Скажем, максимум секунда задержки перед началом воспроизведения особой роли не играет, зато 1 кадр отдаётся на 60 зрителей.

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

83. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 20:53 
Тут вопрос в том, что лучше 1080p с битрейтом, скажем, 3Мб/с или 4K с битрейтом 5Мб/с. Так-то понятно, что оба сорта, но выбирать "хомячкам" не приходиться. На ютубе и того меньше.
Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

108. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Прохожий (??), 11-Ноя-23, 22:14 
> 1080p с битрейтои в 5Мб будет качественнее 4к с битрейтом 5Мб.

Зависит от конкретного видеопотока вообще-то. В общем случае такое заявлять нельзя.
Это во-первых. Во-вторых, вот у меня на компе лежит WebDL 4k. Там рейт 18 Mb/s. Так что где ты раскопал 5 Mb - не знаю.

> Шутка в том что весь этот 4к в стримах - пшик.

Нет, конечно. Разница с FullHD заметна на глаз на соответствующем железе. Тот же Нетфликс специальное ПО использует для оценки качества кодирования.

> Нормальный битрейт для 4К - 144Мб/c

Это, конечно, чушь полная. У меня есть превосходное по качеству видео с рейтом 18 Mb/s. Каждая деталюшечка видна в статических сценах, например, текстура кожи героев. А в динамике оно и не надо, всё равно не заметишь ничего. Зерно - это дефект плёнки, а не что-то ценное, что надо кодировать. От зерна лучше избавляться при кодировании.

> На 5Мб нетфликса - это мыло сплошное если не квадраты.

Мыло - возможно. Квадраты встречались только в очень тёмных местах, где, если специально не смотреть, никогда их не увидишь.

Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

118. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 12-Ноя-23, 00:03 
> и не надо, всё равно не заметишь ничего

Остальное могли и не писать ничего.

> В общем случае такое заявлять нельзя.

Можно. Вы с математикой хотите спорить?

Нет, то что можно сделать абсолютно ужасно с любым битрейтом и разрешением спорить смысла нет. Можно конечно.

Ответить | Правка | Наверх | Cообщить модератору

129. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Прохожий (??), 12-Ноя-23, 02:35 
> Остальное могли и не писать ничего.

То есть, вы ничего не поняли из написанного? Надо разжевать?

>> В общем случае такое заявлять нельзя.
> Можно. Вы с математикой хотите спорить?

Я сейчас буду преувеличивать, но это для того, чтобы продемонстрировать вам, что вы сами с ней не дружите, это во-первых. Во-вторых, вы вообще не понимаете, как работают современные кодеки, типа h.265. В-третьих, вы также не имеете никакого представления, в чём разница между статической и динамической сценами в видеоряде с точки зрения кодека.

Итак. Представим себе кадр, изображение которого - это сплошной белый цвет. Далее, представим себе, что все остальные кадры такие же. Внимание вопрос. Сколько битов надо, чтобы закодировать один такой кадр? Будет ли битрейт, необходимый для кодирования такого видеоряда зависеть хоть как-то от разрешения отдельного кадра? Подумайте на досуге, прежде, чем отвечать.

Ответить | Правка | Наверх | Cообщить модератору

143. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 12-Ноя-23, 13:18 
> Итак. Представим себе кадр, изображение которого - это сплошной белый цвет. Далее

То, что вы считаете интеллектуальным подвигом, для меня - недопустимым уровень деградации.

Так что бросайте держать собоселника за идиота.
Мы о видео говорим, а не о статических белых картинках. На что я обратил ваше внимание в предыдущем комментарии, но до вас похоже не дошло.

Обсуждать со мной то как вы смотрите на сохнущую краску ненужно.

Ответить | Правка | Наверх | Cообщить модератору

148. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 12-Ноя-23, 23:03 
> Можно. Вы с математикой хотите спорить?

Я бы хотел на эту математику посмотреть. Интерес в том, что разрешение не принято менять только для эффективности кодирования, из-за чего темы "разменивания разрешения на bits-per-pixel" и "оптимального разрешения как функции от битрейта" особо не исследованы.

Только кто её покажет? У тебя её нет и есть серьёзные ошибки в других комментариях (про якобы знание о UHD BD и про интерпретацию RD curves).

Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

75. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 11-Ноя-23, 20:21 
> Вы упускаете огромный пласт технологий где h.265 взлетел и до сих пор
> летает - DVB и всякие блюреи.

Которые так то - вымирающее легаси по большому счету. Я вообще блюрей диск ни разу в жизни не видел. Зачем это недоразумение нужно вообще?

> DVB это все телеки и всё что може принимать наземное, кабельное, спутниковое
> и мобильное ТВ.

При том там H.264 чаще всего - за 265 жаба поддушивает. Да и нынче телики уже не у каждого первого есть так то. Их эра заканчивается.

> Всякие ператы на трекерах до сих часто делают h.264 потому что полно
> нытиков у которых телек или их супер мега дорогой аппаратный плеер
> к телеку умеет только его, AV1 рипов очень мало, думаю ещё
> и потому что кодировать в него затратно: пока ты в него
> кодируешь все успеют выкать 264/265 релизы по несколько раз.

Как раз AV1 тяжелый из за своей продвинутости. Кодеру больше вариантов приходится перебирать если уж вариантов партиций дофига, а всякие CDEF и глобальная компенсация движения тоже ни разу не легкие фичи, комбинаций как вообще кодировать некий регион - дохрена, вот кодек и упирается перебирая все эти кучи вариантов. Если рекордный битрейт-качество не так критичны, можно -speed 3..4 или аналогичного ему -cpu-used (в терминах ffmpeg) и кодирование кадра по слайсам врубить. Или вообще юзать воон ту прогу с doom9 которая ffmpeg'ом видео на сегменты режет и пускает параллельное кодирование всей толпы, так даже EPYC можно тредами загрузить от и до.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

87. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (31), 11-Ноя-23, 21:35 
>Я вообще блюрей диск ни разу в жизни не видел. Зачем это недоразумение нужно вообще?

Как раз они и нужны. У WEB-DL качество всегда будет хуже при любом кодеке, чем у блюрея. То, что хомячкам приучили к ютубу и прочим нетфликсам не значит, что на них стоит всем равняться теперь.

Ответить | Правка | Наверх | Cообщить модератору

119. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (24), 12-Ноя-23, 00:08 
Насчет качества можно поспорить. Но даже если и так, обычный человек всё равно зайдет в онлайн-кинотеатр и выберет то, что сегодня захотела посмотреть его левая пятка вместо возни с дисками.
Ответить | Правка | Наверх | Cообщить модератору

160. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 01:15 
>>Я вообще блюрей диск ни разу в жизни не видел. Зачем это недоразумение нужно вообще?
> Как раз они и нужны. У WEB-DL качество всегда будет хуже при
> любом кодеке, чем у блюрея.

У лично меня блюрей приводов вообше нет. Никак, никаких и нигде. И не будет никогда. Все мое мнение о "нужности" этого булшит-бинго с заведомо протроянеными приводами где диск имеет полное право угробить юзеру привод если ему что-то не нравится.

Алсо, в допустим ноуте и тем более планшете/смарте такую дылду чисто технически втыкать некуда.

> То, что хомячкам приучили к ютубу и прочим нетфликсам не значит, что на них
> стоит всем равняться теперь.

Вот ща буду за свои бабки приводы с троянами покупать и брать под козырек рэкетирам из MAFIAA и прочих MPEG LA.

Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

145. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Ivan_83 (ok), 12-Ноя-23, 18:04 
Чтобы было понятно я не топлю за телеки и тоже считаю это умирающей темой, у нас дома нет работающей связки которую можно включить и посмотреть DVB.

Блюрей я тоже не видел.
Но DVB очень медленно вымирающее явление, более того местами его разумно сравнивать со старлинком в плане доставки контента, и старлинк сильно проигрывает по деньгам.

Нет, как раз h.265 сильно стараются пропихнуть везде где он ещё не используется в DVB, потому что там полосы дорогие и не расширяемые, а купить какой то транскодер в h.265 это не так дорого.
Абоненты негодуют что любимые телеки и ресирверы приходится обновлять но операторы все равно внедряют.

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

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

117. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (24), 11-Ноя-23, 23:59 
Про DVB - не всё так просто. Пока массовый пользователь не обновит оборудование (ТВ или хотя бы приставку), никакого H266 там не случится. Даже H265 не сказать, что случился, т.к. у огромного числа пользователей поддерживается только H264.

Про блюреи уже сказано - пережиток прошлого. Собственно, и цифровое ТВ движется туда же, т.к. массовый пользователь активнее переходит на YouTube, Netflix и прочие Twich'и, которые, как уже сказано, сидят на открытых кодеках.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

127. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 12-Ноя-23, 00:43 
Самый крупный сервис, Amazon Prime Video, использует H.265 и 264.
Ответить | Правка | Наверх | Cообщить модератору

57. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Vladjmir (ok), 11-Ноя-23, 19:18 
AV1 даёт приемлемое качество видео не низких битрейтах, что актуально для слабых смартфонов (дешевле 15 000 руб.). Пиндосы в своей википедии пишут:

"По оценкам инженеров Facebook, AV1 позволяет на 50 % уменьшить битрейт при одинаковом качестве по сравнению с H.264, и на 30 % — по сравнению с VP9, при этом — чем выше разрешение, тем эффект сжатия лучше. Включение аппаратной поддержки AV1 позволяет получить преимущества улучшенного видеокодека, перенеся работу по декодированию с программного обеспечения на GPU (особенно это важно для ноутбуков, так как позволяет снизить энергопотребление)"

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

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

58. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноним (20), 11-Ноя-23, 19:25 
Картинка хуже. На 5% эффективнее vp9 экономит битрейт, на 200% дороже кодирует, на 500% дороже декодирует. Это если брать лучшую и совершенную реализацию libaom, у конкурентов не о чем писать домой. AVC -- кодек 20 летней давности, на технологиях прямиком из 70-90х, любые сравнения современных кодеков с ним смешны.
Ответить | Правка | Наверх | Cообщить модератору

68. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 11-Ноя-23, 19:42 
AVC это стандарт, а не кодек.
Ничего устаревшего в нём при этом нет от слова совсем.
Математические основы не имеют тенденцию устаревать. При этом сами алгоритмы кодирования продолжают совершенствоваться и по сей день. Внезапно есть не один и не 10 и даже не 100 способов кодировать в AVC.

h265 слегка расширенный AVC с поднятой планкой для размеров внутренних структур.

vp9 - выродок для любителей жепега. Чем-то он выигрывает у h264 только на шакальных битрейтах.

Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноним (-), 11-Ноя-23, 20:05 
> vp9 - выродок для любителей жепега. Чем-то он выигрывает у h264 только на шакальных битрейтах.

Так перепиши всё на ассемблере!!! Не только же одними ивент лупами ограничиваться, верно?!

Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (-), 11-Ноя-23, 20:37 
> Так перепиши всё на ассемблере!!! Не только же одними ивент лупами ограничиваться, верно?!

Спокойствие, сэр, этим уже занята фирма ARM. И в AV1 и в VP9 и даже в сабже порой. Хорошо, кстати вкалывают. Видимо RISCV начинает поджимать, приходится придумывать как повышать привлекательность своих ядер. Конкуренция - это хорошо :)

Ответить | Правка | Наверх | Cообщить модератору

92. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноним (92), 11-Ноя-23, 21:46 
А потом уязвимости, рутующие телефон от открытия видео в браузере?

Ответить | Правка | Наверх | Cообщить модератору

189. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 15:09 
> А потом уязвимости, рутующие телефон от открытия видео в браузере?

С вашим настроем вы просто обязаны уже выкопать яму не менее 2x2x1 и упаковаться в нее. Для надежности можно сразу земличкой и присыпаться, так уж точно все плохое останется позади.

Ответить | Правка | Наверх | Cообщить модератору

78. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноним (-), 11-Ноя-23, 20:35 
> AVC это стандарт, а не кодек.
> Ничего устаревшего в нём при этом нет от слова совсем.

Именно поэтому ISO обезянил в новые кодеки фичи с AV1... "то же самое только еще патентов напихали в угоду хозяевам" - крутой способ разработки стандартов.

Я почему-то думал что стандарты нужны для interop, а не спонсирования вымогателей. ISO с этим явно не справился свалившись в обслуживание интерсов пары особо наглых контор.

> Математические основы не имеют тенденцию устаревать. При этом сами алгоритмы кодирования
> продолжают совершенствоваться и по сей день. Внезапно есть не один и
> не 10 и даже не 100 способов кодировать в AVC.

При том у VP9

> h265 слегка расширенный AVC с поднятой планкой для размеров внутренних структур.

Поэтому он примерно на одном уровне с VP9 по битрейт-качество. А AV1 его жестко делает, соотношение на примерно 15% лучше по тестам, IIRC.

> vp9 - выродок для любителей жепега.

VP9 это для тех кто не хочет качать терабайты, но хочет видеть видео с нормальным качеством. Ютуб вообще 264 оставил только как fallback для легаси с никаким качеством - но даже так этот крап больше бандвиза жрет чем VP9 с куда более приличной картинкой.

> Чем-то он выигрывает у h264 только на шакальных битрейтах.

H.264 умеет делать совершенно непотребную картинку даже на ломовых битрейтах, а уж на битрейтах характерных для интернета VP9 его буквально в пару раз обставляет, можно получить сравнимую картинку чуть не с вдвое меньшим битрейтом. Даже если юзать x264 со всеми его наворотами.

А смысл использования кодека так то - сделать файл поменьше при том что на глаз не заметно подвоха. Если кодировать в именно Q-based без загонов насчет битрейтов и проч, VP9 жестко обижает H.264 - а AV1 - показывает мастеркласс VP9 процентов на 30 запросто. Заметьте, при Q вообще понятие битрейта отсутствует - он "какой нужен для этого визуального уровня качества".

Кодирование в целевой битрейт выдает динозавра. Адекватные люди давно кодят в Q для себя, или constrained-Q с лимитом на burst битрейта - для раздачи по интернету народу. Дабы пики трафика не перегрузили сервер или канал юзера. Можно посмотреть что гугл сватал как настройки этсамого, недурно работает.

И даже большая часть релизеров вареза ЭТО уже поняли, те которые не совсем ископаемые. На doom9 есть немало идей как осмысленно крутить параметры кодеков, если надо что-то этакое. А для AV1 даже сделали менеджер сегментации, на хрусте при том, кажись, надстройка для сабжа позволяющая супер-многоядерные процы грузить от и до нарезками на эн сегментов и потом сведением оных сабжем опять же. Это уже почти готовая кодинг-ферма для хостинга, во всяком случае иллюстрирует идею как это про делают :)

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

123. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 12-Ноя-23, 00:19 
> можно получить сравнимую картинку чуть не с вдвое меньшим битрейтом.

Если сравнивает лоботомиррваный, то можно.

На ютубе том же "сравнимая" картинка только у всяких стримеров игр. Как только реальное видео h264 с большим рейтом рвет VP9 в хлам.

> Я почему-то думал что стандарты нужны

Я ничего не говорил о патентных проблемах этого стандарта.

Речь шла о технической стороне. Не устаревший, и даже не кодек.

> А смысл использования кодека так то - сделать файл поменьше при том что на глаз не заметно подвоха. Если кодировать в именно Q-based без загонов насчет битрейтов и проч, VP9 жестко обижает H.264 - а AV1 - показывает мастеркласс VP9 процентов на 30 запросто

Смотреть на график, главное сядьте.
https://streaminglearningcenter.com/wp-content/uploads/2019/...

2 процента на 5Мб разницы между av1 и h264

Но это ещё фигня на дефолтах.

Ответить | Правка | Наверх | Cообщить модератору

134. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноним (135), 12-Ноя-23, 06:39 
> 2 процента на 5Мб разницы между av1 и h264

Там написано, что если тебе не нужны эти 2%, ты с AV1 (энкодер не указан) можешь задать битрейт в 2 раза ниже, чем с x264.

Ответить | Правка | Наверх | Cообщить модератору

147. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 12-Ноя-23, 21:36 
Зачем минусовать? Там всего три стрелочки дорисовать надо, если словами* непонятно: https://imgur.com/a/qE9VDNd (https://i.imgur.com/MsWf0Ce.png)

*
>> 2 процента на 5Мб разницы между av1 и h264
> Там написано, что если тебе не нужны эти 2%, ты с AV1 (энкодер не указан) можешь задать битрейт в 2 раза ниже, чем с x264.

Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

194. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 15:41 
> Зачем минусовать? Там всего три стрелочки дорисовать надо, если словами* непонятно:

Анон, ты шикарен. Ты бываешь на doom9 или имеешь какой-то более известный handle? Так воткнуть местным экспертам даже я бы не смог :). Взял и показал самым безжалостным образом как битрейт ополовинить нахрен с равным качеством.

И кстати...
1) С тех пор AV1 активно пилили. VP9 пилили менее активно - ибо зачем упираться с прошлым поколением если можно с nextgen пободаться? Хотя ряд изменений портировали в обе стороны. А 265 пилит полтора инвалида. Они тот темп врядли смогут, и скорее всего отставание усилилось.
2) У AV1 есть наглый чит. Если качество картинки и битрейт наше все, то можно врубить HBD процессинг даже для LBD. Это медленнее, но повышенная точность пайплайна - зарубает rounding error и проч. И это ведет к весьма измеримому снижению битрейта при эквивалентном качестве, сугубо predictors лучше работают - ну кодеку и надо передавать меньше данных для компенсации того что "не угадали".

Если вкратце описывать современные видеокодеки: декодер пытается угадать чем должен быть новый кадр. А кодер передает ему дельту ошибки предсказания. Чем лучше предсказание - тем меньше кодеру передавать.

Ответить | Правка | Наверх | Cообщить модератору

192. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 15:34 
> Если сравнивает лоботомиррваный, то можно.

Да вот знаете, side by side что с H.264 не делай а на битрейте который AV1 не просто ок но и картинка близка к идеалу, из H.264 выжать что-то кроме мути и квадратиков малореально, даже если placebo x264 вкрутить со всем мыслимым обвесом high-профайла (который потом половина хардварных декодеров не сожрет, ага). А кодировать в сто мегабитов - вы там сами, мне на данном этапе развития технологий такие кодеки с такими параметрами не надо. Туда же стройными рядами идут любители инновационного MPEG2.

Как угодно но у 264 сильно меньше фич для уменьшения объема residual данных и prediction у него намного хуже. Он IIRC вообще не умеет в глобальную компенсацию движения - а передать глобальное движение вместо кучи локальных motion-vectors выгодно по размеру данных. IIRC даже 265 умеет заметно меньше на эту тему.

Вариантов кодирования партиций у AV1 куда больше. Это тормозит кодинг но позволяет кодеру выбрать наиболее удачное кодирование, скостив объем данных.

CFL (Chroma From Luma, предиктор такой, пользующийся что chroma и luma здорово корелируют) в 264 тоже нет, и не помню есть ли что сравнимое в 265 хотя-бы. А, представляете, если предсказать контент по одной из компонент, данных residual'ов сильно меньше. Почему-то.

CDEF это вообще весьма крутое изобретение. Это придумали авторы Thor, Daala и VP9 собща. Это то ради чего они объединились. Это еще не lapped transform - но весьма годная идея: кодер сам подбирает loop filter максимально адекватно для входного контента и сигналит декодеру. Этот замечательный фокус позволяет почти забыть о "мпеговских квадратиках". Потому что границы блоков так стыкованы намного лучше с самого начала. H264 вообще клал не этот топик с прибором и просто разваливается на квадраты. Можно конечно 100 мегабит накидывать ему, но это не сильно лучше чем в MPEG2 жать получается.

> На ютубе том же "сравнимая" картинка только у всяких стримеров игр. Как
> только реальное видео h264 с большим рейтом рвет VP9 в хлам.

Вообще-то на ютубе VP9 как раз обычно и лучше выглядит и трафа в среднем на треть меньше. Из-за этого гугол вообще перестал крутые разрешения в 264 кодить: для многих мувиков 264 рассматривается как фалбэк для легаси клиентов и выше 720p потоков может не оказаться в принципе, а если хотите больше - тогда умейте VP9. Если оно "горячее" то рядом и AV1 будет вскоре. Не собирается гугол платить за бандвиз в разы. Заодно икота видео юзеров бесит сильнее чем плохая картинка, а с ломовым битрейтом оно на это по сети так или иначе обречено, гугл купирует эту проблему на подлете. Улучшая UX.

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

>> Я почему-то думал что стандарты нужны
> Я ничего не говорил о патентных проблемах этого стандарта.
> Речь шла о технической стороне. Не устаревший, и даже не кодек.

На мой вкус я не вижу там ничего groundbreaking. А вот в AV1 виду ряд довольно годных трюков которые разработали так то настоящие гуры видеокодинга, типа Xiph'овского Monty. И в отличие от каких-то нонеймов крышующих патентных троллей я знаю кто такой Монти и чем он знаменит.

> https://streaminglearningcenter.com/wp-content/uploads/2019/...

Ну дык там AV1 всех в конечном итоге делает, как я и сказал. Это кажется господа из MSU Lab или как их там? Их стиль графиков.

> 2 процента на 5Мб разницы между av1 и h264
> Но это ещё фигня на дефолтах.

Я просто покодил разные мувики сам, составил впечатление как оно. H.265 реально может рубаться скорее с VP9 - который так то прошлое поколение кодека. А h.264 вообще в полном заду. Никакая магия не может его догнать до битрейт-качество даже как у VP9.

И вопрос: ну и в чем "супер крутость" ваших кодеков состоит? Особенно чтобы еще и иметь гимор с патентами и прочим "не играется в линухе" и проч? Все же не зря Daala, Thor и VP10 встретились в одном кодеке. Это дало именно тот эффект который я ожидал.

И как видно чем ниже битрейт - тем больше разрыв. Потому что круть кодека вылезает там. На ломовом битрейте и MPEG2 - кодек, типа.

Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

268. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 15-Ноя-23, 00:14 
> И вопрос: ну и в чем "супер крутость" ваших кодеков состоит?

О супер крутости речи не шло.
Оно работает, и хорошо.
Проблем с совместимостью и воспроизведением на линуксе не имеет.
Играется на любом утюге.

Никаких 100мб на 1080p ненужно конечно. Блюрей можно смело с 50 до 25 обрезать с отличным качеством. Можно и ниже.
При этом кодирование достаточно быстрое.

Плацебо даёт результаты иногда хуже чем верислов. Подкрутить можно вручную.

AV1 да, технически навороченный. Именно из за чего кодирование ну очень медленное, в железе реализовывать декодирование не просто, и ещё сложнее кодирование. Поддержка железа всё ещё оставляет желать лучшего.

На ютубе h264 варианты показывают лучшее качество на динамических сценах, vp9 буквально в квадраты разваливается.

Да, на 1080p. Ютуб внезапно в другом разрешении отказывается выдавать практически всё.

Ответить | Правка | Наверх | Cообщить модератору

272. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 15-Ноя-23, 00:58 
> Никаких 100мб на 1080p ненужно конечно. Блюрей можно смело с 50 до
> 25 обрезать с отличным качеством. Можно и ниже.

А если AV1 это забацать... впрочем я обычно предпочитаю Q-mode как более эффективный в целом подход. И там битрейт - "уж какой получится". Если его не заклампить в constrained-Q конечно.

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

Это дает дополнительный бонус в эффективности - со всеми кодеками. Идея не моя, это гугл придумал, и другие профи. И в этом смысле никакая магия не сделает файло H.264 сравнимым в размере с AV1 при равном визуальном качестве.

> При этом кодирование достаточно быстрое.

Ну конечно быстрее AV1 но вообще - AV1 заметно разогнали и он уже на speed=3 с тайлингом - ну может раза в 3 тормознее VP9. Уже вполне терпимо во многих случаях, не зря вон те пахали столько. Это конечно не топовый сетап а компромисс, но 264 и даже 265 и это не достанут. Не дано им - фичи потока убогие.

> Плацебо даёт результаты иногда хуже чем верислов. Подкрутить можно вручную.

Ну, блин, я уже почти не кодирую в 264. А смысл? Это как в Div3 5 лет назад кодировать.

> AV1 да, технически навороченный. Именно из за чего кодирование ну очень медленное,

Оно так то регулируемо. Просто перфекционизм надо строить, доли процента выигрыша speed=0 (aka cpu-used) не стоят обрушения скорости кодинга в разы - на 0 вырубаются все эвристики раннего завершения. И получается... примерно как с placebo, так что даже чуть хуже может стать.

Есть еще крайне забавная крутилка в виде форсирования HBD процессинга для LBD, оно снижает ошибки округления и вот именно визуально - в градиентах - и особенно на умеренном битрейте - разница очень крутая и видна на глаз (в стопкадре конечно). Это правда стоит процентов 30 по скорости, но когда файло и меньше и лучше выглядит - это круто, а соотношение 30% complexity vs 10% gain у кодировщиков считается весьма крутым и редкая фича нового формата настолько же круто работает.

> в железе реализовывать декодирование не просто, и ещё сложнее кодирование.

Корпорации присоединились к AOM не просто так. И их проблемы были учтены. Сорц кодека сразу сделан под high-level synthesis. Его реалтаймный subset - может быть синтезирован в железо.

> Поддержка железа всё ещё оставляет желать лучшего.

Да вроде уже все кому не лень запилили. И легион китайцев, и все GPUшки новые, что интель, что амд, что нвидия. Старый хардвар конечно да, но всякие либы типа dav1d неплохо и в софте подразогнались так то. А вон там ARM фигачит для своих железок все что отдаленно мультимедию напоминает, AV1 и VP9 - в первых рядах, сабжу тоже достается. А может и еще чему, я ж вижу только комиты того на что pull делаю.

> На ютубе h264 варианты показывают лучшее качество на динамических сценах, vp9 буквально
> в квадраты разваливается.

На ютубе большая часть H.264 это жуткая муть с чуть ли не шевелящимися квадратами и немеряным битрейтом. Это такой откровенный fallback насколько я вижу. А HiEnd вариантов типа 2144 и 4K в 264 вообще вроде бы и нету. Там чаще вообще выше 720 нихрена нету, я бы сказал что это phase out с явным допущением что "264 == legacy client". Типа древнего тв и что там. Да, совсем не закроют это еще сколько-то лет, для старых клиентов, но напрягаться ради древностей они явно не собираются.

> Да, на 1080p. Ютуб внезапно в другом разрешении отказывается выдавать практически всё.

По моим наблюдениям порой 1080p версии в 264 тупо нет, и более 720 не дают. А VP9 - вот оно. Закономерность я не понял честно говоря. Видимо какой-то неспешный phaseout. Впрочем 264 на 1080 бандвиз жрет как не в себя и потому и фиг с ним. Чем ниже бандвиз тем меньше риски икоты по любым причинам.

Есть исключение: live стримы обычно 264. А в VP9 рюхаются когда трансляция завершена (сейчас довольно быстро уже). Гугель я так понимаю использует весьма осмысленный подход к оптимизации общего gain. Чем жирнее и горячее мувик тем охотнее его тяжелыми плотными кодеками обработают в первых рядах, не забыв урезать всякие 264 и проч - если кто древний, пусть fallback и кушает. В целом логика похоже минимизирует общий битрейт хостинга.

Ответить | Правка | Наверх | Cообщить модератору

273. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноньимъ (ok), 15-Ноя-23, 01:48 
> Я не вижу смысла оперировать конкретным битрейтом по всему мувику

Я кодирую только с постоянным качеством. Средний битрейт просто общая мера в данном обсуждении. Можно заменить на "размер".

> По моим наблюдениям порой 1080p версии в 264 тупо нет

По моим она есть ВСЕГДА. То есть я не встречал такого видео на ютубе у которого бы не было.
Например:
yt-dlp -F GHfKmNWjB2w
299 mp4   1920x1080   60    │    1.31GiB 2735k https │ avc1.64002A   2735k video only          1080p60, mp4_dash
303 webm  1920x1080   60    │  697.58MiB 1421k https │ vp09.00.41.08 1421k video only          1080p60, webm_dash

Типичный вывод.

При этом AV1 оно вообще не отдаёт.

Проверил для нескольких видео. Создалось впечатление, что ютуб кодирует в AV1 только UHD видевы.

Ответить | Правка | Наверх | Cообщить модератору

283. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 15-Ноя-23, 15:58 
> Типичный вывод.

Субъективно, большая часть видео на ютубе - не 60p, для начала. Или мы разные видео смотрим, хз. Но вы правы, я перепроверил, через dash 1080p 264 чаще доступен. Но через браузер оно вообще не даст явно 264 выбрать. Автоматически юзая VP9 если клиент его умеет, а по возможности и AV1.

Поэтому чтобы вообще ВОН ТО увидеть - надо очень конкрертно извращаться. Полтора фрика с этим даунлоадером ютуба точно не напрягают, а в браузере это увидеть вообще хз как. Видимо взяв какой-то совсем легаси браузер не умеющий VP9/AV1 но уже умеющий DASH. Видимо таких клиентов мизер - для них видимо все же оставили.

А вот "old api" для старых клиентов и проч - совершенно точно урезали до 720p максимум. Гугол явно делает то что срезает ему максимум бандвиза первым делом а остальное - потом.

> При этом AV1 оно вообще не отдаёт.

Ну так оно кодируется неспешно, backlog - эвона какой. Весь ютуб. Поэтому как я понимаю они и кодируют первым делом то что больше всего бандвиза создает. Чтобы бандвиз - убавить.

> Проверил для нескольких видео. Создалось впечатление, что ютуб кодирует в AV1 только
> UHD видевы.

Что самое жирное и генерит им бандвизу - то и кодируют. Постепенно и остальное перекодируют. Они как-то так же и VP9 выкатывали.

Ответить | Правка | Наверх | Cообщить модератору

275. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 15-Ноя-23, 04:55 
> Есть еще крайне забавная крутилка в виде форсирования HBD процессинга для LBD

Чем в седьмой раз это говорить, лучше ответь (под #251), почему она лучше повышения разрядности в старых кодеках. По твоему описанию получается, что по сути ничем. Только UX: старые кодеки не подталкивают к её повышению ради эффективности и в них информация о меньшей разрядности исходника потеряется.

Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

277. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 15-Ноя-23, 08:53 
> По твоему описанию получается, что по сути ничем

* что по сути ничем не отличается.

- - - - - -
Пощупал и понял, что для понимания надо минимально рабочие примеры делать гораздо крупнее, а я столько ждать не буду. И что нужна максимальная чистота эксперимента, а я всё равно её не обеспечу, не разбираясь в опциях (например, вроде aomenc'у следует делать 2 прохода даже для CRF, он это делает по умолчанию, вроде обязан сделать оба прохода за один запуск, но при этом падает, не падает только по одному проходу на запуск).

- - - - - -
ffmpeg -f lavfi -i testsrc=mandelbrot=s=1280x720 -t 10 -pix_fmt yuv420p -f yuv4mpegpipe - | aomenc --pass=<1/2> --passes=2 --fpf=pass.stat --cpu-used=6 --cq-level=30 --end-usage=q [*] --output=out[*].webm -

[1] без доп. опций (5.84 MiB)
[2] --use-16bit-internal (5.85 MiB, метрики как у [1] в пределах погрешности)
[3] --bit-depth=10 (5.63 MiB, SSIM чуть выше, VMAF чуть ниже, добавление --use-16bit-internal на результат не влияет, как и должно быть)

Сравнение с lossless через -lavfi ssim и -lavfi libvmaf.

Ответить | Правка | Наверх | Cообщить модератору

278. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 15-Ноя-23, 09:36 
ffmpeg -f lavfi -i mandelbrot=s=2000x2000 -vframes 1 -pix_fmt yuv420p -f yuv4mpegpipe - | aomenc --passes=1 --end-usage=cbr --target-bitrate=1000 [*] --output=out[*].webm -

[1] без доп. опций (186 KiB)
[2] --use-16bit-internal (186 KiB, хэш видео совпадает)
[3] --bit-depth=10 (183 KiB, SSIM растёт, VMAF на этот случай не заточен?)
[4] --bit-depth=12 (179 KiB, SSIM растёт)

--use-16bit-internal всегда включён и не отключается?.. Или влияет только на какую-то межкадровую фигню?..

Ответить | Правка | К родителю #277 | Наверх | Cообщить модератору

285. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 15-Ноя-23, 16:19 
> ffmpeg -f lavfi -i mandelbrot=s=2000x2000 -vframes 1 -pix_fmt yuv420p -f yuv4mpegpipe -
> | aomenc --passes=1 --end-usage=cbr --target-bitrate=1000 [*] --output=out[*].webm

Я не знаю что это за перверсии и зачем так сложно, но в сабжевом ffmpeg + libaom последней версии интерфейснутом "нативно" для LBD контента HBD path форсится явным указанием -pix_fmt yuv420p10le. После чего libaom врубает HBD пайплайн и жует это как будто оно HBD. Чудес, конечно, не случится, но более мелкий и более симпатичный визуально файл за счет лучшей работы предикторов - весьма приятный сюрприз.

Ответить | Правка | К родителю #278 | Наверх | Cообщить модератору

284. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 15-Ноя-23, 16:13 
> Чем в седьмой раз это говорить, лучше ответь (под #251), почему она
> лучше повышения разрядности в старых кодеках.

Это не "повышение разрядности" в смысле - контента. Но повышение точности пайплайна за счет юзания HBD обсчета, даже если в итоге и выгрузят LBD. AV1 скорее всего выигрывает от повышения точности предикторов больше остального: он очень далеко идет в предсказании следующих кадров - и минимизации передаваемого "prediction error", ему этот топик, имхо, важнее. Откуда и возможность срезать еще с 10% бандвиза, да еще и картинку улучшив на вид. Остальные наверное могут попробовать жтот фокус, но у всяких 264/265 просто нет возможностей битстрима чтобы этим воспользоваться на полную.

В таком виде просто unbeatable, 264 на этом фоне выглядит как ср@ный xvid, 265 примерно современный AV1 по датам разработки - даже с VP9 едва может рубаться. И остальные потуги ISO - извините но кодек это 10% спеки и 90% имплементация. Если ISO решило узнать этот момент сложным способом - будет им. А желаюшие могут чекатуить какое там еще vvc у фраунхофера, удачи в разработке этой шляпы с такими заводилами.

> По твоему описанию получается, что по сути ничем. Только UX: старые кодеки не
> подталкивают к её повышению ради эффективности и в них информация о меньшей
> разрядности исходника потеряется.

Я просто не встречал форсирования HBD-path для LBD контента и впервые этот трюк был найден мной на Doom 9 в топике про кодирование вот именно AV1. Насколько этот фокус можно провернуть с другими кодеками... я всерьез это изучил для AV1 и остался доволен потраченным временем, оно того стоило. Если вы считаете аналогично для иных кодеков - ну вот и отпишитесь? Меня кодиорвание в 264 интересует на уровне кодирования в дивикс когда я AV1 уже могу взять. А 265 мне вообще не в п... ни в красну армию с его свойствами. Не понимаю на что там патентные тролли расчиытвали.

Ответить | Правка | Наверх | Cообщить модератору

289. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 16-Ноя-23, 05:15 
> но у всяких 264/265 просто нет возможностей битстрима чтобы этим воспользоваться на полную.

Citation needed. Это слишком серьёзное заявление, особенно с учётом слов про безразличие к работе этих кодеков. Давайте "это" определим как повышение эффективности кодирования через повышение разрядности исходника либо через использование опции типа --use-16bit-internal в AV1 (не важно, через что именно, интересен практический результат в %).

> Если вы считаете аналогично для иных кодеков - ну вот и отпишитесь?

Исследовать эту сторону у всех трёх кодеков было бы хорошо и полезно. Но в принципе есть вариант попроще - избегать голословных заявлений.

Ответить | Правка | К родителю #284 | Наверх | Cообщить модератору

292. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 16-Ноя-23, 16:14 
> Citation needed. Это слишком серьёзное заявление, особенно с учётом слов про безразличие
> к работе этих кодеков.

Моя логика проста. Если у вас нет всяких CFL, CDEF или Global motion compensation то и улучшить их работу вы "почему-то" не сможете при прочих равных. Странно, да?!

Если продвинутые фичи из-за повышения разрядности процессинга станут точнее предсказывать и отыграют еще больше, скостив residuals сильнее - окей, а вон те чем это будут крыть? А, ничем? Ну я так и подумал. Поэтому ожидаемый результат - увеличение разрыва.

А безразличие - сейчас. Это не значит что я совсем не разбираюсь как это работает: я вообще начинал кодировать с MPEG-1 и видел эволюцию технологий с того момента. Поэтому на концептуальном уровне я понимаю отличия и как оно эволюционировало. Просто в какой-то момент технологии становятся не актуальными чтобы их плотно трекать. И я могу и не знать до какого top notch сейчас догнать какой-нибудь xvid сейчас. Ну и 264 уже как-то так же стал. А 265 вообще не понятно зачем нужен кроме очередного вымогательства, он кажется будет весьма короткоживущей технологией ибо с AV1 тягаться не могет, условия лицензирования фейл, и зачем это надо хз. Судя по истошному клепанию стандартов исой они тоже что-то подсыковывают.

> Давайте "это" определим как повышение эффективности кодирования
> через повышение разрядности исходника либо через использование опции типа
> --use-16bit-internal в AV1 (не важно, через что именно, интересен практический
> результат в %).

Ну вот AV1 кажет весьма недурное улучшение за счет роста точности предсказаний, даже если контент и LBD. У меня типично получилось в пределах 10%, детали, конечно, от видео зависят.

Учитывая что AV1 и без этого всех делал, это такой бонусный "форсаж" позволяющий вообще соревноваться только с секундной стрелкой, демонстрируя так называемым якобы "крутым кодекам" дюзы. Самым наглым и бесцеремонным образом из возможных - подняв вооон ту кривую вверх еще.

>> Если вы считаете аналогично для иных кодеков - ну вот и отпишитесь?
> Исследовать эту сторону у всех трёх кодеков было бы хорошо и полезно.

Ну если вам интересны эти кодеки - так займитесь. Я уже почти не кодирую в 264 и просто ничего не выиграю от этого знания чтобы на него мое время тратить. А в 265 кодировать я вообще смысла для себя не вижу. Он видимо скоро умрет, там уже 266 пыжатся делать. Но есть большая разница между хотеть и мочь. Что хочет получить MPEGLA, Franuhofer и прочие ISO я вижу. Теперь посмотрим как они кодить умеют.

> Но в принципе есть вариант попроще - избегать голословных заявлений.

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

Ответить | Правка | К родителю #289 | Наверх | Cообщить модератору

298. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 17-Ноя-23, 04:08 
> Моя логика проста.

Не надо логики, надо экспериментов, статей. Логики хватит, из-за неё вон результаты 10-битного кодирования приписывались одному лишь HBD-path'у на 8 битах.

Ответить | Правка | К родителю #292 | Наверх | Cообщить модератору

304. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 17-Ноя-23, 17:57 
>> Моя логика проста.
> Не надо логики, надо экспериментов, статей. Логики хватит, из-за неё вон результаты
> 10-битного кодирования приписывались одному лишь HBD-path'у на 8 битах.

Ну так вход при этом LBD и от декларации иного формата пикселей он не становится HBD.

Изначально вообще можно ожидать что станет жирнее, а когда оказывается наоборот, да еще с улучшением картинки, феномен уже понимаемо требует научное объяснение. На Doom9 вроде дали устраивающее меня объяснение что так предикторы точнее работают, откуда и уменьшение данных. Но если энных предикторов нет - улучшать нечего.

Вообще, объективное сравнение кодеков очень гиморное и времяемкое/ресурсоемкое занятие. У разных кодеков свои идеи чему реально соответствует тот или иной Q например. Откалиброваться на более-менее идентичное визуальное качество - сущий ад. А ABR/CBR тестит совсем не то, привнося особенности аллокации битрейта, которые при реальном кодировани видеть как раз и не захочется первым делом. Метрики - есть, но они показометры. Я дал конкретный пример - fade in в BBB. Метрики не очень видят разницу. И на движущейся картинке не сильно заметно. Но в стопкадре - "дискретизация" перфекционистов выморозит. Особенно если они видели оригинал.

Если интересно: самый критичный к отклонениям от идеала сегмент BigBuckBunny это fade in от 16 до примерно 25-26 кадра с начала последовательности. Смотреть результат на ХОРОШЕМ мониторе (как минимум калиброваный IPS с честными битами, HBD бонус) - и слегка в темноте, на свету в лимиты зрения упрется. На чем то хуже дискретизацию нагнет ваш хардвар и будет не понятно о чем я. В этом смысле шестибитные "офисные" матрицы совсем не прокатят. И вот так получается что в циферках метрик вроде фигня, quality of life improvement - весьма измеримый и это топик о котором можно говорить. Жмем мы все же не для метрик, а ради хорошей картинки. И как обладатель неплохого монитора я в этом топике шкурно заинтересован.

И в этом контексте я для себя придумал жать RAW контент и считать за "приемлимый результат" пока я не вижу явных артефактов. Это не универсальное сравнение кодеков и с такой "калибровкой" можно (а может и нужно) поспорить, у меня просто не было более удачных идей как оттестировать практически интересные кейсы. И да, есть трабла, так можно недооценить кодек - как на том примере с HBD path vs LBD path, LBD-path AV1 будет недооценен. Более того - такая постановка эксперимента требует хороший хардвар, офисный монитор с урезаной битностью покажет оба варианта одинаково хреново и экспериментатор вообще разницу не увидит.

Жать какие-то фракталы в 1 проходном режиме? Ну, здорово, а чего полезного мне будет с этого знания? Реальный контент на это не похож. И кодирую я в 2 прохода. Даже если я составлю впечатление о относительном перфомансе кодеков для этого кейса - ок, и куда это знание? Я не собираюсь кодировать фракталы в 1 проход. То что соотношения останутся те же на других кейсах - ниоткуда не следует.

Как конкретный пример вариабельности соотношений "силы кодеков": если хочется выпятить x264, можно аниме взять. Там довели это почти до совершенства, гуры после твиков умудряются в почти идеальную картинку при издевательском битрейте, делая почти невозможное. Оно может даже сможет AV1 обставить до сих пор. И вычислительная сложность ниже. Казалось бы, EPIC WIN?! Есть только 1 catch: это только в узких допущениях для специфичного контента. Шаг в сторону - и все гораздо печальнее для x264. А это весьма нишевой случай. Мне например вообще малоинтересный, а какой-нибудь битард со мной жестко заспорит. Откуда и моя идея брать контент и сценарии кожирования похожие на то что я буду юзать в реальных сценариях. Т.е. фильмобразное нечто, 2 прохода, Q-mode чтобы не изучать проблемы аллокатора бандвиза. И да, это "приблизительно" и частично "субъективно" но представления о эффективности кодеков даст. Ну а размер файла все же объективная метрика. Да, это не избавлено полностью от субъектива. Но я кодирую для себя а не для красивых PSNR или VMAF. И в этом плане стоит сказать что допустим tune={ssim,psnr,vmaf,...} у кодека зачастую улучшает метрику, но с точки зрения юзера картинку - гадит, являясь "антифичой" для накрутки формальных бенчей в угоду фактическому визуальному качеству.

Если есть какие-то удачные идеи как бенчмаркать более-менее реалистичные кейсы с реалистичными параметрами - я бы с удовольствием послушал.

Ответить | Правка | К родителю #298 | Наверх | Cообщить модератору

306. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 20-Ноя-23, 11:49 
> Ну так вход при этом LBD и от декларации иного формата пикселей
> он не становится HBD.

Непонятно, к чему этот ответ и ведь становится всё-таки. Технически мы сделали то, что требуется энкодеру. Пустота в младших битах теперь-10-битного-исходника нас не волнует, пока не видно бандинга. Энкодер к этой пустоте интереса тоже не испытывает.

> На Doom9 вроде дали устраивающее меня объяснение
> Но если энных предикторов нет - улучшать нечего.

Проблема в том, что первое объясняет, почему повышение разрядности в принципе работает.
А вывод про AV1 сделан уже тобой самостоятельно и, например, не объясняет, почему от повышения разрядности в H.265 пользы меньше, чем в H.264, несмотря на более продвинутое предсказание.
>  8-bit h.265 has higher-precision motion vectors than 8-bit h.264, so that part of the reasoning doesn't apply to x265. - https://video.stackexchange.com/a/21595
> Do we have any evidence that 8-bit sources encode better in 10-bit than 8-bit in AV1? While that was true for H.264, it was much less so for HEVC, and I don't see why AV1 would have any regressions versus HEVC in that regard. - https://forum.doom9.org/showthread.php?p=1892081#post1892081
> Смотреть результат на ХОРОШЕМ мониторе (как минимум калиброваный IPS с честными битами,
> HBD бонус)
> ...
> офисный монитор с урезаной битностью покажет оба
> варианта одинаково хреново и экспериментатор вообще разницу не увидит.

Гхм, хороший монитор пригодится, чтобы видеть меньше бандинга, а не наоборот.

Вообще, 8 бит* для SDR-видео немного не хватает и почему-то именно в тёмных местах. Гамма-коррекция должна контраст-между-соседними-уровнями-яркости делать одинаковым для глаза на всём диапазоне яркости, но она не идеально справляется (плюс старые стандарты не изменить), да и в реальности не все условия из телевизионщических стандартов соблюдаются.

Но решение есть - создавать видео с более высокой разрядностью (избегать видимого квантования), а потом при понижении разрядности дизерить его во избежание бандинга. Вообще "дизерить при каждом понижении разрядности" - универсальное правило для фото-видео-звука... и проектирования 6-битных матриц мониторов.

В исходнике BigBuckBunny наверняка так и сделано (один ползунок в Blender?). Но подмешанный высокочастотный шум плохо переживает перекодирование (а если переживает, то жрёт битрейт) и бандинг всё-таки вылезает. Но если при перекодировании поднять разрядность, то мы частично вернёмся** к тому, с чего начали - к нормальным >8-битным градиентам без дизеринга. Точнее, теперь за дизеринг для 8-битных экранов отвечает плеер.

В x264/x265 ещё можно было тёмным местам задать качество повыше через --aq-mode=3 (Auto-variance AQ with bias to dark scenes).

* на самом деле ещё хуже - 7.88 бит (16-235).

** Получается, для этого трюка достаточно выкидывания высоких частот энкодером - о предварительной ручной отмене дизеринга можно не думать. Думать (о фильтрации в vapoursynth, например) придётся, если только исходник уже пострадал от бандинга.

Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

310. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 24-Ноя-23, 05:16 
> Непонятно, к чему этот ответ и ведь становится всё-таки. Технически мы сделали
> то, что требуется энкодеру. Пустота в младших битах теперь-10-битного-исходника нас не
> волнует, пока не видно бандинга. Энкодер к этой пустоте интереса тоже не испытывает.

Мой пойнт:
1) Исходник от этого лучше не стал и битов в нем столько сколько было, столько есть.
2) Единственный реальный профит с этого маневра - задействуется более точный code path энкодера, где меньше ошибок округления и проч.

> Проблема в том, что первое объясняет, почему повышение разрядности в принципе работает.

Насколько я понял из их объяснений, предсказания становятся более точными. Кодек такого плана грубо говоря пытается максимально предугадать текущий кадр из предыдущих и может быть следующих кадров, а также референсов (сие специфично для AV1/VP9). А ошибка от предсказания кодируется и передается как текущий кадр. И чем там меньше - тем лучше сжатие будет, соответственно.

В этом смысле - у 265 вроде бы нет части продвинутых предикторов как у AV1. Большая часть фич AV1 как раз про улучшения предсказаний, на чем и получается снижение residuals. И чем лучше это сделано тем меньше размер энного кадра. Если хорошо угадалось, размер энного кадра может быть издевательский.

> А вывод про AV1 сделан уже тобой самостоятельно и, например, не объясняет,
> почему от повышения разрядности в H.265 пользы меньше, чем в H.264,
> несмотря на более продвинутое предсказание.

Вот это кстати интересный вопрос. Я не настолько в 265 заинтересован чтобы детально копать как там унутрях процессинг сделан на тему ошибок округлений и проч. И я вполне допускаю идею что эффект варьируется в зависимости от того как кишки процессинг делали. Но эту рукоятку неплохо иметь под рукой - с более высокими разрядностями процессинг медленнее.

Для AV1 с его фичами скорость и рукоятки важнее. Из-за брутфорса немеряного числа вариантов кодирования он ессно медленнее в нащупывании оптимального представления. Это одна из причин по которым есть теории что "революции" с падением битрейта в разы скоро кончатся - кодеки станут слишком медленными с 1 стороны, diminishing returns с другой.

>> Do we have any evidence that 8-bit sources encode better in 10-bit than 8-bit in AV1?

Вот этот эффект я могу на 100% подтвердить для libaom+сабж. Я экспериментировал и - оно и мельче, и выглядит лучше. Это довольно редкое комбо в мире кодеков и я очень хорошо это запомнил, а 10-bit входит в базовый профайл AV1, как я понимаю compat не портится.

> Гхм, хороший монитор пригодится, чтобы видеть меньше бандинга, а не наоборот.

Офисный испортит картинку и так и сяк, разница не очевидна. Кстати в BBB этот эффект на именно движущейся картинке - малозаметен. Но на стопкадре, при HQ таргете кодирования все ж бесит, если знать что ищешь. Если целью было сделать визуально-идеальную картинку... ну... она или идеальная, или уж нет. Найти артефакт сжатия - вполне критерий для такого goal.

> Вообще, 8 бит* для SDR-видео немного не хватает и почему-то именно в
> тёмных местах. Гамма-коррекция должна контраст-между-соседними-уровнями-яркости делать
> одинаковым для глаза на всём диапазоне яркости, но она не идеально
> справляется (плюс старые стандарты не изменить), да и в реальности не
> все условия из телевизионщических стандартов соблюдаются.

Ну и вот в результате - для AV1 даже на Q, когда битрейта точно хватает - если стопкадр на fade in рассматривать, таки, в темноте видно дискретизацию. А на 10bit - как в оригинале, идеально.

Учитывая что мувик еще и меньше получается, я для себя пришел к выводу что в энных случаях я таки готов убить на 30-40% больше времени ради такого "перфекционизма".

> Но решение есть - создавать видео с более высокой разрядностью (избегать видимого
> квантования), а потом при понижении разрядности дизерить его во избежание бандинга.

Дизеринг так то нагадит сжатию, увы. Кодек либо грохнет шумодавом, либо если не грохнет, предикторам это что-то типа шума - ошибка предсказания подскочит, файло станет заметно жирнее за счет роста residuals. А вон то круто тем что файло и визуально лучше и мельче, необычное сочетание требующиее объяснения "как это возможно?!".

> Вообще "дизерить при каждом понижении разрядности" - универсальное правило для
> фото-видео-звука... и проектирования 6-битных матриц мониторов.

К сожалению это может нагнуть сжимаемость картинки, нагадив предикторам. Хинт: денойз повышает сжимаемость материала. В случае САБЖА для видео в темноте можно попытаться скроить достаточно агресивный пайплайн из 3-мерных денойзеров и решарперов, в виде когда это с одной стороны делает кодеку проще, с другой не особо убивает картинку, особенно в движении, да и шумовые артефакты разогнаные кодеком - сомнительная радость, чтобы идеально сохранять ЭТО.

> В исходнике BigBuckBunny наверняка так и сделано (один ползунок в Blender?). Но
> подмешанный высокочастотный шум плохо переживает перекодирование (а если переживает,
> то жрёт битрейт) и бандинг всё-таки вылезает.

Не вижу там никакого особого шума честно говоря. Просто очень плавный computer-generated градиент в начале мувика. Он неравномерный - и потому ошибки дискретизации на этом могут вылезти вполне видимыми "контурами". На движущейся картинке маскируется, fade in близок к идеалу. Но если знать что ищешь, в стопкадре, с хорошим моником, в темноте, таки, найдется. А с 10 битами таки - визуально как оригинал.

> Но если при перекодировании поднять разрядность, то мы частично вернёмся**
> к тому, с чего начали - к нормальным >8-битным градиентам без дизеринга. Точнее,
> теперь за дизеринг для 8-битных экранов отвечает плеер.

Для меня первое выглядело не столько дизерингом сколько просто "дискретностью", плоские регионы, явно "дискретные", как изолинии на карте. Как будто 1-2 бита LSB местами просто профакались при процессинге. А любой дизеринг с которым сталкивается кодек должен портить сжатие - весьма заметно предикторы нагибает.

> В x264/x265 ещё можно было тёмным местам задать качество повыше через --aq-mode=3
> (Auto-variance AQ with bias to dark scenes).

У AV1 тоже такая штука есть. Но мануально твикать вот именно его - на любителя: в зависимости от мувика может получиться как лучше так и хуже, эффект весьма зависит от характера контента. И результат варьируется от неплохого улучшения до "что это за фигня?!". Если кодить в fire and forget его лучше не трогать. Если хочется максимум для конкретного мувика, вариант. Но вообще AV1 даже и без этого мастеркласс может дать по битрейт-качество.

> * на самом деле ещё хуже - 7.88 бит (16-235).
> ** Получается, для этого трюка достаточно выкидывания высоких частот энкодером - о
> предварительной ручной отмене дизеринга можно не думать. Думать (о фильтрации в
> vapoursynth, например) придётся, если только исходник уже пострадал от бандинга.

Я таки подозреваю что конкретика в ощибке может здорово варьироваться от кишок кодера. Может програмеры в x265 решили что раз он не быстрый то возьмем дескать разрядность с запасом, в большем числе мест - и тогда относительный выигрыш от маневра просядет. Но таком случае они, вероятно, заметно нагнули скорость в дефолтном code path. Ну как, lanes в SIMD либо столько либо столько. И если не влезло в байт - ну, упс, значит это заметно медленнее. x265 в этом смысле проще, у него меньше продвинутых фишек и его время не так сильно жмет. Ну так он в результате и оказыается под кривой AV1 - хоть что с ним делай, а фич у формата меньше. Так что реально он скорее конкурент VP9 какому получился. Вот только тот бесплатный и даже уже по сути устаревший, однако. И продать такое - но с кучей патентов и за деньги - по моему исо уже совсем охамело с такими соотношениями.

Кстати качнул сравнения MSU за 2022 - и я уж не знаю в чем фокус, может гугл им там не заплатил, или конкуренты доплатили, или там что, но libaom у них был супер-архаичной версии. Он и жал куда хуже - и делал это намного тормознее. Так что их результаты тестов для libaom там имеют нулевую real world ценность: на практике соотношения у libaom намного лучше. В чем пойнт бенчить именно так - ну а кто их там знает. Довольно забавно что одного из самых сильных конкурентов так беспардонно задвинули, и все как бы честно - ну кто там циферку версии будет в деталях изучать?! А я вот дотошный и знаю какой путь оно за это время прошло. Ну и корректирую мои выводы на тему валидности такого бенча соответственно.

Ответить | Правка | К родителю #306 | Наверх | Cообщить модератору

312. Скрыто модератором  +/
Сообщение от Аноним (135), 24-Ноя-23, 21:10 
Ответить | Правка | К родителю #310 | Наверх | Cообщить модератору

270. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноньимъ (ok), 15-Ноя-23, 00:33 
Добавлю. Что крутые фичи - это хорошо. Но они как раз могут вносить проблемы, визуальные артефакты, без должной точной настройки, которая может идти десятилетиями. Спорить о технических подробностях не могу. Могу только согласиться в остальном.
Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

276. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Смузихлёб (ok), 15-Ноя-23, 08:37 
> Добавлю. Что крутые фичи - это хорошо. Но они как раз могут
> вносить проблемы, визуальные артефакты, без должной точной настройки, которая может идти
> десятилетиями. Спорить о технических подробностях не могу. Могу только согласиться в
> остальном.

Дружок, ты уж определись в какой области ты эксперт.

Ответить | Правка | Наверх | Cообщить модератору

136. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноним (135), 12-Ноя-23, 07:55 
> Математические основы не имеют тенденцию устаревать.

Конечно, имеют. Например, в математической основе PNG - отсутствие арифметического кодирования. Это задаёт потолок, который не пробить даже софтинами-оптимизаторами. Математически устарел, жив из-за широкой совместимости.

А вот обратная ситуация. Полёт математической мысли ограничивается суровой реальностью. В математической основе JPEG есть арифметическое кодирование. Но сначала он был огорожен патентами, а потом его поддержку ради совместимости решили не включать. Чтобы пресечь создание файлов, которые могут у других не открыться.

Хз, куда там ещё можно двигаться в H.264 и что по качеству нового в новых версиях x264. Математика позволяет заабузить 10-битную разрядность на 8-битных исходниках ради эффективности, но об этом давным-давно известно и тут снова выходит на сцену суровая реальность - 10-битные профили H.264 не поддерживаются аппаратными декодерами, проще на 10-12 бит H.265 перейти.

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

199. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (-), 13-Ноя-23, 16:23 
> Конечно, имеют. Например, в математической основе PNG - отсутствие
> арифметического кодирования.

Откуда на опеннет такие эксперты лезут? В zlib внезапно есть хаффман, статический и динамичский, не сильно хуже и заметно быстрее.

> Это задаёт потолок, который не пробить даже софтинами-оптимизаторами. Математически устарел,
> жив из-за широкой совместимости.

У png так то еще фильтры есть. А потолок задает скорее винтажный zlib с словариком 32К так что совпадения на большей дистанции он не ловит. А 32 кило на современных объемах данных это чего такое?

Просто с тех пор более удачные варианты lossless кодирования картинок придумали. Но в вот именно честном lossless они png обычно не так уж и сильно обставляют.

> А вот обратная ситуация. Полёт математической мысли ограничивается суровой реальностью.
> В математической основе JPEG есть арифметическое кодирование. Но сначала он был
> огорожен патентами, а потом его поддержку ради совместимости решили не включать.
> Чтобы пресечь создание файлов, которые могут у других не открыться.

Основная фича JPEG вовсе не в этом а в DCT, разница между арифметиком и хаффманом - как максимум какие-то считанные проценты. Хаффман это дискретная версия арифметика по сути, так что хуже только за счет округления вероятностей.

> Хз, куда там ещё можно двигаться в H.264 и что по качеству

Туда где ему самое место, т.к. присоединиться к MPEG2, DivX и проч. AV1 это все жесточайше рвет на британский флаг по битрейт-качество.

> нового в новых версиях x264. Математика позволяет заабузить 10-битную разрядность на
> 8-битных исходниках ради эффективности, но об этом давным-давно известно и тут
> снова выходит на сцену суровая реальность - 10-битные профили H.264 не
> поддерживаются аппаратными декодерами, проще на 10-12 бит H.265 перейти.

Зато в AV1 можно провернуть фокус когда на выходе таки LBD стрим но процессинг делается в HBD, и ошибок округления меньше. Так что битрейт при равном качестве может еще с десяток процентов потерять из-за более удачных предсказаний всего чего можно. К сожалению за это и кодирование на 30-40% медленнее, но кодирование на треть дольше при снижении битрейта на 10% считается весьма хорошим соотношением.

Ответить | Правка | Наверх | Cообщить модератору

251. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 14-Ноя-23, 11:33 
> Откуда на опеннет такие эксперты лезут? В zlib внезапно есть хаффман, статический
> и динамичский, не сильно хуже и заметно быстрее.

Я их по косточкам не разбирал. Но что тогда ещё такого наворотили во FLIF?

Исходный коммент звучал так, словно в H.264 есть свой Тьюринг-полный язык, как в ZPAQ. Вот это была бы защита от устаревания.

> в вот именно честном lossless они png обычно не так уж и сильно обставляют.

Не знаю, что такое нечестный lossless, но между JXL и PNG - пропасть. Её исследовали тут:
https://www.reddit.com/r/AV1/comments/fjddcj/lossless_image_.../

> разница между арифметиком и хаффманом - как максимум какие-то считанные проценты.

На гигантской выборке из одной картинки jpegtran -arithmetic говорит, что 13%.

> Зато в AV1 можно провернуть фокус когда на выходе таки LBD стрим
> но процессинг делается в HBD

На выходе декодера? Выглядит как украшательство, чтобы сообщить о разрядности исходника. Чтобы повышение разрядности выглядело более официально, а не как хак.

Аналог вот этого?
--internal-bitdepth to define the internal bit-depth used in bitstream (default: 10).
https://github.com/fraunhoferhhi/vvenc/blob/2217e1030c32a98b...

Что там вообще происходит?
https://gitlab.com/AOMediaCodec/avm/-/issues/26
https://github.com/xiph/rav1e/pull/2746

Ответить | Правка | Наверх | Cообщить модератору

257. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 14-Ноя-23, 18:14 
> Что там вообще происходит?
> https://gitlab.com/AOMediaCodec/avm/-/issues/26

Исправлю себя, это репа AV2. Кстати, гугол решил запихнуть его внутрь AV1 Image File Format: https://www.phoronix.com/news/AVIF-Experimental-AV2

Тут я на стороне комитетов. У них получается опубликовать стандарт, когда гугол намекает покопаться в последних исходниках. Получается не ломать обратную совместимость, потому что захотелось.

Ответить | Правка | Наверх | Cообщить модератору

260. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 14-Ноя-23, 18:31 
> Получается не ломать обратную совместимость, потому что захотелось.

Это к решению положить AV2 в контейнер для изображений в AV1.

Ещё один повод продвигать JPEG-XL, но в браузер его почему-то добавляет Apple, а не Mozilla. Mozilla прекрасно объяснила свой отказ:
> On the whole, having fewer formats is better for the Web - https://www.phoronix.com/news/Mozilla-Neutral-On-JPEG-XL

Ей бы ещё удалить поддержку своего APNG с такой мотивировкой.

Ответить | Правка | Наверх | Cообщить модератору

282. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 15-Ноя-23, 15:38 
> Тут я на стороне комитетов. У них получается опубликовать стандарт, когда гугол
> намекает покопаться в последних исходниках. Получается не ломать обратную совместимость,
> потому что захотелось.

Да? Ну попробуйте проиграть AV1-in-mp4 container в обратно совместимом виде. Как ни странно такое комбо было энное время одобрено ISO. Видимо догадываются что иначе их совсем уйдут на мороз.

Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

288. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 16-Ноя-23, 04:15 
> Да? Ну попробуйте проиграть AV1-in-mp4 container в обратно совместимом виде. Как ни
> странно такое комбо было энное время одобрено ISO. Видимо догадываются что
> иначе их совсем уйдут на мороз.

А что, MP4 позиционируется как single coding container format (как AVIF), чтобы в него новые кодеки класть нельзя было?

Старые плееры не проигрывают новые кодеки, это очевидно. MP4 стал не таким ограниченным? Ну и хорошо.

Оно и сейчас одобрено. Теги кодеков добавляют через двери MP4 Registration Authority, в 2019 AV1 добавили, потом VP8 и VP9:
https://github.com/mp4ra/mp4ra.github.io/commit/d55151fac9f1...
http://mp4ra.org/#/codecs

Обратная совместимость там есть, лишняя дорожка в AV1 не ломает плееры.
ffmpeg -i in.mkv -i in.mkv   -map 0:v:0   -map 1:v:0 -c:v:1 libaom-av1  -map 0:a:0   h264-av1-aac.mp4

Ответить | Правка | Наверх | Cообщить модератору

290. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 16-Ноя-23, 06:37 
> Обратная совместимость там есть, лишняя дорожка в AV1 не ломает плееры.

* обратная совместимость в том смысле, в котором к ней можно высказывать претензии
* не ломает старые плееры без поддержки AV1

Ответить | Правка | Наверх | Cообщить модератору

293. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 16-Ноя-23, 16:34 
> А что, MP4 позиционируется как single coding container format (как AVIF), чтобы
> в него новые кодеки класть нельзя было?

Я просто намекаю что обратная совместимость штука зачастую весьма условная. Вплоть до того что видя MP4 - еще не гарантия что он проиграется.

> Старые плееры не проигрывают новые кодеки, это очевидно. MP4 стал не таким
> ограниченным? Ну и хорошо.

Да он и не был ограниченным как формат. Как впрочем и матрешка лежащая в основе webm. Но вот сказ про обратную совместимость выглядит забавно когда теперь появятся MP4 которые у вон тех играться не будут.

> Оно и сейчас одобрено.

Да, это просто опечатка, по задумке было "ISO с неких пор одобрил AV1 в MP4 контейнере".

> Теги кодеков добавляют через двери MP4 Registration Authority,
> в 2019 AV1 добавили, потом VP8 и VP9:

Вот про VP8/9 я не в курсе был честно говоря. Интересно в чем прикол. "Эксперты" ISO хотят оставаться нужными хоть для чего-то, не кодеков так хоть контейнеров? :)

> Обратная совместимость там есть, лишняя дорожка в AV1 не ломает плееры.

Кто ж вам лишнюю то будет? Ее одну и сделают такой. Основную. А кодировать в 100500 вариантов будут только пару хостингов типа ютуба, которым надо смарттв старые поддерживать и проч. У них эенег много - могут себе позволить.

> ffmpeg -i in.mkv -i in.mkv   -map 0:v:0   -map
> 1:v:0 -c:v:1 libaom-av1  -map 0:a:0   h264-av1-aac.mp4

Не понимаю пойнт этих упражнений.

Гугл если что сильно иначе это делает. У dash есть общий header (для разных форматов потоков ессно разный) и чанки потока в энном формате. При том это отдельно для аудио и видео треков. Таких нарезок может быть несколько, что аудио что видео форматов. Клиенту чтобы свичнуть формат трека надо качнуть только мелкий хедер общий для последовательности и далее чанк этой последовательности с нужного места в изменившемся формате. И это имеет смысл - клиент может выбрать поток под возможности по простому и даже адаптивно. Если канал просел - более тощий по бандвизу вариант тягать. А потом если стало лучше прозрачно перейти на более жирный. Свичить вот именно кодек - гугл обычно не практикует, выбирая самый эффективный по битрейт-качество, но технически это как я понимаю возможно.

Единственное реальное отличие ютуба от стандартного DASH - очень замороченный урл сервера с хидерами и чанками, куда их плеера отправляет нехилый редиректор на JS с основательным декодированием урлы, что как раз и портит карму копипастерам (гугл их изредка по@бывает, меня логику редиректора).

Ответить | Правка | Наверх | Cообщить модератору

294. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 16-Ноя-23, 18:34 
> Я просто намекаю что обратная совместимость штука зачастую весьма условная. Вплоть до того что видя MP4 - еще не гарантия что он проиграется.
> Но вот сказ про обратную совместимость выглядит забавно когда теперь появятся MP4 которые у вон тех играться не будут.
> выглядит забавно

Это потому что вас проприетарии покусали. Поэтому и сочетание в примере такое - AV1 в MP4, а не H.266 в MP4 или AV1/H.266 в MKV.

Представьте, что кто-то бы заявил о недостатке обратной совместимости в MKV из-за поддержки ~любых новых кодеков. Вы бы возразили, что это глупое требование, и что адекватная обратная совместимость заключается в такой-то совместимости между 1-4 версиями спецификации матрёшки и в способности плееров не падать при виде незнакомых дорожек. А для непокусанных это возражение относится ко всем не-single-coding контейнерам, не только свободным.

> Не понимаю пойнт этих упражнений.

Это для непокусанных.

Ответить | Правка | К родителю #293 | Наверх | Cообщить модератору

305. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 18-Ноя-23, 20:40 
> Это потому что вас проприетарии покусали.

Это очень крутое и техническое обоснование за фичу. А играть надо плеером с форматом ехешника от justine.lol видимо. Хотя там код 1 раз как раз.

> Поэтому и сочетание в примере такое - AV1 в MP4, а не H.266 в MP4 или AV1/H.266 в MKV.

Это сочетание выделяется из толпы - встретились форматы разных standard body, при том конкурирующих. Не часто такое увидишь.

> Представьте, что кто-то бы заявил о недостатке обратной совместимости в MKV из-за
> поддержки ~любых новых кодеков.

Как сказать? WEBM довольно жестко специфицирован как subset матрешки в том числе и чтобы убавить такие проблемы. И таки качая webm сюрпризов сильно меньше, хоть и фич тоже.

> Вы бы возразили, что это глупое требование, и что адекватная обратная
> совместимость заключается в такой-то совместимости между 1-4 версиями
> спецификации матрёшки и в способности плееров не падать при виде
> незнакомых дорожек.

Вообще, именно поэтому и сделали webm как более специфицированный частный случай. Идеально конечно не получилось т.к. технологии на месте не стоят но "дикий запад" в форматах ведет к тому что половина файлов не играется, софт не может корректно понимать формат и это ведет к множеству проблем от "этот файл у нас не играется" до каких-нибудь странных вулнов. Бесконечная расширяемость при цели устаканиться на формате для interop может сыграть и злую шутку в виде обломаных юзерей "мой MP4 плеер не играет MP4?!"

В этом смысле у мпеговского контейнера были подвиды типа 3GP в чем-то похожие по смыслу - subset того же контейнера, но - с характерным ожидаемым типом кодеков и ограничениями. Заодно никто .mp4 их не называл, расширение .3gp и 3g2 потом.

> А для непокусанных это возражение относится ко всем не-single-coding
> контейнерам, не только свободным.

Да. И кстати "свободный" контейнер достаточно вольное определение - а что, на ISO BMFF или его расширения еще и патенты есть? Само по себе оно ж древнее как помет мамонта и берет начало из раннего квиктайма аж. Структурно это что-то типа варианта fourcc, и известно это все с как минимум 90х.

>> Не понимаю пойнт этих упражнений.
> Это для непокусанных.

Это для желающих странного - мувик становится жирным аки опеннетный тролль. Может тогда RAW туда завернуть - и пусть эта тля подавится?

Ответить | Правка | К родителю #294 | Наверх | Cообщить модератору

307. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 20-Ноя-23, 13:50 
> Это очень крутое и техническое обоснование за фичу.

То было единственное возможное объяснение, почему MP4 с новыми кодеками - это плохо, когда WebM с ними - это хорошо.

> Как сказать? WEBM довольно жестко специфицирован

Не слишком я ценю идею ограничений. Запрет для веба навороченных функций матрёшки, наверное, был полезен. Но остальное - нет.
- H.264 был запрещён для продвижения VP8.
- Локально, вне браузера, можно проиграть всё, что декодирует ffmpeg.
- Все понимают, что в MP4 для веба не надо класть Dirac или H.265. AV1 в WebM как единственный вариант тоже сгодится.
- Что такое MP4-плеер?

VP8 права на жизнь не имеет. Чтобы в нём получить гарантированно правильные цвета, надо в конец видео добавить настроечную таблицу, наверное - гениальная спецификация.

> Это для желающих странного - мувик становится жирным аки опеннетный тролль. Может
> тогда RAW туда завернуть - и пусть эта тля подавится?

Это синтетический пример к =>
> * обратная совместимость в том смысле, в котором к ней можно высказывать претензии

Ответить | Правка | К родителю #305 | Наверх | Cообщить модератору

308. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 20-Ноя-23, 13:52 
> AV1 в WebM как единственный вариант тоже сгодится.

* тоже не сгодится

Ответить | Правка | К родителю #307 | Наверх | Cообщить модератору

311. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 24-Ноя-23, 05:55 
> То было единственное возможное объяснение, почему MP4 с новыми кодеками - это
> плохо, когда WebM с ними - это хорошо.

На чисто человеческом уровне - AV1 вообще совсем не "MPEG4". Вот как его ни рассматривай, к MPEG не относится никак. Это может добавить бардака и непоняток. Когда у вас вроде MP4 - но на самом деле внутри нечто не имеющее отношения к MPEG это круто. Или нет.

Webm в этом плане - более логичен, там несколько кодеков от более менее одних и тех же затейников. И никто не занимается стандартизацией туда x264/5/6/whatever. В матрешку - можно. Но это не будет "webm". Так что если проигрываемость конкретной матрешки там и тут полная лотерея, с webm все куда более определенно.

В чем трабл? Допустим мы декодер. И вот нам на вход MP4. Это технически BMFF, распарсить то пожалста. Но вот что он еще и играться будет - ага, ща. С webm в этом плане на стороне плеера сильно проще. И это специально. Кому надо форма играемый у 50% клиентов?!

> Не слишком я ценю идею ограничений. Запрет для веба навороченных функций матрёшки,
> наверное, был полезен. Но остальное - нет.

Зато это делает файло проигрываемым и интероперабельным. И его может смотреть весь глобус. Не делая админам и сапортам мозг. И это сильный аргумент.

> - H.264 был запрещён для продвижения VP8.

С другой стороны - оно игралось на всех клиентах умеющих webm. Кому нужно поддержку видео которое играется с шансами 50/50. И как при этом видео на сервак выкладывать? 50% юзерей придет делать мозг сапорту? Ну, круто, вау.

> - Локально, вне браузера, можно проиграть всё, что декодирует ffmpeg.

Ну, понимаете, если я видео грузил энному юзеру - я так то не знаю что у них там за версия ffmpeg и чего она там (не)умела. А локально - откуда мой файл у вон того юзера вообще извините возьмется, так то? В этом смысле уменьшенный фичесет - штука полезная, качая webm можно быть более-менее уверенным что это еще и играется. AV1 конечно немного подпортил картинку.

> - Все понимают, что в MP4 для веба не надо класть Dirac или H.265.

Ну это как сказать. Качая рандомный MP4 из чьего-то хомяка, кто ж их там знает чем они это сняли или сжали.

> AV1 в WebM как единственный вариант тоже сгодится.

Ну реально все ж придется уметь AV1/VP9/VP8 - но это лишь 3 кодека видео + Opus/Vorbis для аудио. Все же более подъемное требование для клиента. Требования вида "вы ОБЯЗАНЫ юзать" ffmpeg - тоже не в ладах с здравым смыслом. Что за вендорлок такой? Сабж хорошая либа, но в обязаловку его потребовать? Ох... это фиговый дизайн стандартов и софта.

> - Что такое MP4-плеер?

Агаблин, юзеры были очень рады заметить что их хардварные приставки, плееры и что там еще с "поддержкой MP4" могут сжевать далеко не любой MP4.

> VP8 права на жизнь не имеет. Чтобы в нём получить гарантированно правильные
> цвета, надо в конец видео добавить настроечную таблицу, наверное - гениальная
> спецификация.

Ну он древненький и базовый. Технически в нем нихрена интересного кроме golden frames. Единственное что хорошего я о нем могу сказать - он легкий и шустро играется даже на антикварных компах, почти как xvid. На этом его достоинства и кончаются. Но VP9 нехило подтянули на его базе, сделав нечто - уделывающее x264 на минуточку, и рубящееся скорее с x265 и ко. А вот это уже серьезное демо намерений.

> Это синтетический пример к =>
>> * обратная совместимость в том смысле, в котором к ней можно высказывать претензии

Оно так то забавно - но убивает смысл использования кодека :). С таким успехом можно было MPEG2 какой взять и дать немеряный VOB или что там, при том на это уже и патентные тролли забили или патенты истекли поди. А совместимо оно даже с античными плеерами эпохи царя гороха и пузатых CRT. По своему круто. И даже жмется быстро как понос. Но вот соотношение размера файла к качеству картинки... эм... а без этого всего кодеки так то нафиг не нужны :)

Ответить | Правка | К родителю #307 | Наверх | Cообщить модератору

313. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 24-Ноя-23, 22:13 
> На чисто человеческом уровне - AV1 вообще совсем не "MPEG4". Вот как
> его ни рассматривай, к MPEG не относится никак. Это может добавить
> бардака и непоняток. Когда у вас вроде MP4 - но на
> самом деле внутри нечто не имеющее отношения к MPEG это круто.
> Или нет.

Если не знать о противостоянии "электротехников движущихся картинок" и "альянса за отсутствие отчислений", то ничего странного не видно.

> Webm в этом плане - более логичен, там несколько кодеков от более
> менее одних и тех же затейников. И никто не занимается стандартизацией
> туда x264/5/6/whatever. В матрешку - можно. Но это не будет "webm".
> Так что если проигрываемость конкретной матрешки там и тут полная лотерея,
> с webm все куда более определенно.
> ...
> оно игралось на всех клиентах умеющих webm. Кому
> нужно поддержку видео которое играется с шансами 50/50. И как при

Лотереи не может быть, H.264 поддерживался лучше VP8/VP9. Под этой новостью вспоминали про оживление старых компьютеров через форсирование выбора H.264 на ютубе, чтобы аппаратное декодирование работало.

> В чем трабл? Допустим мы декодер. И вот нам на вход MP4.
> Это технически BMFF, распарсить то пожалста. Но вот что он еще
> и играться будет - ага, ща. С webm в этом плане
> на стороне плеера сильно проще. И это специально. Кому надо форма
> играемый у 50% клиентов?!

Ну, положи AV1 внутрь WebM. Так можно. HDR-видео тоже можно сделать, похоже. Профиль поднять выше аппаратно декодируемого? Тоже можно. Без здравого смысла никуда и его нужно почти столько же, сколько с MP4.

> Зато это делает файло проигрываемым и интероперабельным. И его может смотреть весь
> глобус. Не делая админам и сапортам мозг. И это сильный аргумент.

Весь глобус смотрит видео на ютубе. Где вообще выкладывают видео в нетронутом виде?.. На имиджбордах, а где ещё?

> Требования вида "вы ОБЯЗАНЫ юзать" ffmpeg - тоже не
> в ладах с здравым смыслом. Что за вендорлок такой? Сабж хорошая
> либа, но в обязаловку его потребовать? Ох... это фиговый дизайн стандартов
> и софта.

В браузер целиком ffmpeg не добавить (придут за отчислениями за некоторые кодеки), но вне браузера это здравый смысл для разработчика плеера. Раньше были кодек-паки, сегодня - ffmpeg (точнее, libavcodec?).

> Агаблин, юзеры были очень рады заметить что их хардварные приставки, плееры и
> что там еще с "поддержкой MP4" могут сжевать далеко не любой
> MP4.

MP3-плееры я знаю, а MP4 - нет.

> Ну он древненький и базовый.

Но метаданные для отображения цветов без неоднозначности были до VP8 в H.264 (VUI), а спецификацию VP8 забросили, хотя могли расширить. На самом деле не могли, там выделили 1 бит под эти метаданные.
o  0 - YUV color space similar to the YCrCb color space defined in
      [ITU-R_BT.601]
o  1 - Reserved for future use

> Оно так то забавно - но убивает смысл использования кодека

Попробую в третий раз - дорожка в AV1 не ломает плееры, больше ничего от контейнера требовать не нужно. Вот AVI был гораздо более хрупкий. Класть несколько видеодорожек без какой-то особой необходимости тоже не нужно.

Ответить | Правка | К родителю #311 | Наверх | Cообщить модератору

281. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 15-Ноя-23, 15:32 
> Я их по косточкам не разбирал.

Оно и видно: png и jpg имеют мало общего, сравнить их может только дилетант. Png это по сути как .bmp.gz. Массив пикселей сжатый zlib (deflate). Правда есть фильтры. Но это битмап. Хорошо работает с чем-то типа скриншотов, схем, line-art и прочего computer-generated и т.п.. - где есть повторяющиеся области. А для фоток - сжатие маргинальное. Распаковка - бит в бит с оригиналом.

А JPG делался для фоток и real world. Другой класс алго. Использует DCT, загрубляет коэффициенты, потом энтропию кодит, за счет чего и жмет. С потерями как правило. Для line art и проч не подходит - засирает резкие переходы артефактами DCT, оно пытается грубо говоря представить все как градиент. С контрастными линиями работает фигово. Сравнивать их? А они для разного! К каждый хорош (или плох) по своему. У википедиков даже от таких гениев есть плашка "No Jpegs" - с перечеркнутым срачем джыпега на lineart.

> Но что тогда ещё такого наворотили во FLIF?

А вот его я в деталях не смотрел, увы. Еще кстати AVIF есть. AVIF to AV1 is what WEBP to VP8, I-frame от AV1 грубо говоря. Предсказуемо мощнее жыпега. Но и его я в деталях не смотрел, сжатие картинок мне менее интересно.

> Исходный коммент звучал так, словно в H.264 есть свой Тьюринг-полный язык, как
> в ZPAQ. Вот это была бы защита от устаревания.

Как показал его пример, результат получается специфичным, тормозным и не имеет хождение кроме как курьез "насколько можно сжать, если долбануться?!". Кроме того - по сути выполнять ремотный код, хоть и VM не есть безопасно как показали хардварные вулны.

>> в вот именно честном lossless они png обычно не так уж и сильно обставляют.
> Не знаю, что такое нечестный lossless,

Честный = bit-identical битмап на выходе, разумеется. Работа в режиме "архиватора". Если результат бит в бит, это лосслес. Иначе как максимум "visually lossless".

> но между JXL и PNG -  пропасть. Её исследовали тут:
> https://www.reddit.com/r/AV1/comments/fjddcj/lossless_image_.../

Покорно благодарю но я не буду читать ред-байду с кучей JS. Извините. Моя ремарка лишь к тому что вы явно не поняли что JPG и PNG - разные классы технологий, для разного.

> На гигантской выборке из одной картинки jpegtran -arithmetic говорит, что 13%.

Из одной картинки? А в чем прикол? Попробовал на разных. Получил 8..11%. Не так уж плохо, но и не groundbreaking чтобы лизать кому-то пятки.

Меня вообще фирма RadGameTools хорошо отучила от кр00тых проприетарных форматов. Я как-то перегнал несколько мувиков в Bink и стер оригинал. Агаблин, нюанс в том что играется оно только их убогим плеером, распаковка в другие форматы не предусмотрено, так что бесплатный сыр от пропертариев оказался мышеловкой. И только САБЖ и сильно опосля решил мою проблему Get Data Back!

>> Зато в AV1 можно провернуть фокус когда на выходе таки LBD стрим
>> но процессинг делается в HBD
> На выходе декодера? Выглядит как украшательство, чтобы сообщить о разрядности исходника.

Это encoder-only трюк. Он выдаст LBD стрим на выход если вход LBD. Но внутрях при обработке заюзает HBD-path. Который, конечно, медленнее. Зато точнее. Пойнт в том что ошибки округления и дискретизации не будут портить картинку. Обычно малозаметно, но в плавных градиентах, особенно темных, ошибки дискретизации и округления могут стать видны "на глаз".

Характерный пример: BigBuckBunny - начальный fade in. Или любое что на это похоже, плавный градиент, особенно темноватый, бывает и в real world и в синтетике. В HBD-path AV1 это точнее отпроцессит, даже если и оформит выход как обычный поток. В метриках сильно не видно - но на глаз отсутствие "лестниц" и "дискретности" в градиенте приятнее. Как бонус - предикторы из-за отсутствия ошибок округления еще более точно угадывают - меньше данных ошибки передавать. И файло в итоге меньше, порой процентов на 10 при том же Q. Получается забавный парадокс: и визуально лучше - и меньше файло. Но, увы, ценой +30-40% к времени кодирования, HBD path by design медленнее, более широкая математика, больше данных летает.

> Чтобы повышение разрядности выглядело более официально, а не как хак.

Там нет повышения разрядности, конечно. Снижение ошибок от дискретности математики и округлений. Чтобы на выходе HBD был - вход должен быть HBD. А парадокс в том и состоит что от HBD-path выигрывает даже LBD контент. Этот эффект обнаружен и обоснован гурами с Doom9.

> Аналог вот этого?

Я vvenc не интересуюсь, так что ничего не скажу по его фичам. Получить "то же самое но обвешаное патентами и не играемое в вебе" мне малоинтересно.

> Что там вообще происходит?

Если вопрос про вон то - просто форсирование обсчета как HBD контента в LBD. Я думаю мы все можем согласиться что LBD - частный случай HBD, не так ли? И поэтому его можно отпроцессить HBD codepath. С понятной потерей перфоманса, ведь разрядности больше и данных прибавилось.

> https://gitlab.com/AOMediaCodec/avm/-/issues/26
> https://github.com/xiph/rav1e/pull/2746

Похоже на то. Для ffmpeg+libaom трюк делается так: -pix_fmt yuv420p10le. Формат выходного потока останется LBD/YUV 4:2:0 но это не помешает ему быть визуально лучше и в q-mode еще и меньше по весу из-за улучшения предсказаний.

Кто хочет может закодить с этим и без - и сравнить. Ожидаемый результтат в q-mode: кодирование на 30-40% медленнее но файло до 10% меньше и визуально лучше в ряде мест типа вот таких градиентов.

Ответить | Правка | К родителю #251 | Наверх | Cообщить модератору

287. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 16-Ноя-23, 02:40 
> png и jpg имеют мало общего, сравнить их может только дилетант.

Ох ты ж, не сравнивай, куда тебя понесло?

JPEG, очевидно, к тому, что в нём Хаффман заменяется на арифметическое кодирование одной вышеупомянутой командой. Если ты хотел сказать "результаты сравнения Хаффмана и арифметика в JPEG никак нельзя переносить на lossless-картинки, потому что...", то ты этого не сказал. В JPEG они слишком легко сравниваются, уж извините, а препарированием PNG для замены Хаффмана мы оба не занимались, во FLIF тоже не лезли.

> курьез "насколько можно сжать, если долбануться?!"

Зато математика долгоживучая - пример хороший, сферичность в вакууме его не портит.

> Покорно благодарю но я не буду читать ред-байду с кучей JS. Извините.
> Моя ремарка лишь к тому что вы явно не поняли что
> JPG и PNG - разные классы технологий, для разного.

Зачем писать "в честном lossless они png обычно не так уж и сильно обставляют", если на доказательства обратного начинается "не буду извините вы явно не поняли"? Одна таблица по ссылке. Оптимизированный PNG получился на 46% больше, чем JXL. В 2020 году, на солидном датасете.

> чтобы лизать кому-то пятки.

Патенты истекли, для чтения стандарта жипега даже к itu.int приближаться не надо - его скопировали на w3.org. Так что лизать пятки - дело добровольное. И сугубо личное, я не осуждать не стану.

> > https://gitlab.com/AOMediaCodec/avm/-/issues/26
> > https://github.com/xiph/rav1e/pull/2746
> Если вопрос про вон то

Не, про ситуацию с поддержкой. С первой ссылкой я промахнулся - это AV2, а багтрекер aom (AV1) не пролил свет на --use-16bit-internal в aomenc, в rav1e аналога, как видно, ещё нет, SVT-AV1 пока остаётся за кадром.

> Похоже на то. Для ffmpeg+libaom трюк делается так: -pix_fmt yuv420p10le. Формат выходного
> потока останется LBD/YUV 4:2:0

То есть ты делаешь так: ffmpeg [-i in.mkv]* -pix_fmt yuv420p10le -c:v libaom-av1 out.mkv и получаешь на выходе 8 бит? Это невозможно. Хорошо, добавляем -aom-params bit-depth=8 - ошибка, этот параметр не из тех, которые разрешено передавать из ffmpeg в libaom. Тогда возвращаемся к pipe как ниже ("зачем так сложно") - ffmpeg отдаёт yuv420p10le, а aomenc --bit-depth=8 его принимает. Но понижать разрядность отказывается, согласен только повышать. Выходит, ты просто кодируешь 10-битное видео и что-то себе придумываешь про high/low bit depth. Ты ни разу в MediaInfo/ffprobe закодированного файла не смотрел?

* Ниже предлагал вместо этого генерировать видео ради воспроизводимости у нас: [-f lavfi -i mandelbrot=s=2000x2000 -vframes 1]

> Это encoder-only трюк. Он выдаст LBD стрим на выход если вход LBD.
> ...
> Там нет повышения разрядности, конечно ... Чтобы на выходе HBD был - вход должен быть HBD.
> ...
> Для ffmpeg+libaom трюк делается так: -pix_fmt yuv420p10le.

- на входе энкодера 10 бит (HBD) из-за yuv420p10le
- повышение разрядности уже произошло из-за yuv420p10le
- на выходе HBD - на входе HBD, почему ты не замечаешь?

Ответить | Правка | Наверх | Cообщить модератору

291. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 16-Ноя-23, 09:06 
Я сделал невероятное (невероятно глупое) открытие: в исходниках aomenc написано, что с --verbose он сигнализирует о выборе LBD/HBD encoding path.
https://aomedia.googlesource.com/aom/+/refs/tags/v3.7.0/apps...

Поэтому:
1. --use-16bit-internal работает и выбирает HBD coding path для 8 бит
2. для 8 бит по умолчанию выбирается LBD coding path
3. в ffmpeg опцию указать через --aom-params use-16bit-internal нельзя
4. на "видео" из одного кадра опция не влияет - результат сходится побайтово
5. кажется, от неё вообще пользы мало
6. а от повышения разрядности польза есть
7. говоря о выборе HBD coding path ты на самом деле имел в виду повышение разрядности
8. повышение разрядности очевидно включает в себя и выбор HBD coding path

Ответить | Правка | Наверх | Cообщить модератору

295. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (171), 16-Ноя-23, 18:36 
> Ох ты ж, не сравнивай, куда тебя понесло?

Так это не я полез JPG с PNG сравнивать.

> JPEG, очевидно, к тому, что в нём Хаффман заменяется на арифметическое кодирование
> одной вышеупомянутой командой. Если ты хотел сказать "результаты сравнения Хаффмана и
> арифметика в JPEG никак нельзя переносить на lossless-картинки, потому что...", то
> ты этого не сказал.

А вы неплохи в чтении мыслей. ИМХО потому что JPG и PNG деланы под радикально разный контент и сценарии использования EntropyCoder. PNG намного ближе к "обычному архиватору" в этом плане и в архиверах разница от замены хаффмана на арифметика считанные проценты.

> В JPEG они слишком легко сравниваются, уж извините,

В любом случае - это прикольная находка, спасибо.

> а препарированием PNG для замены Хаффмана мы оба не занимались, во FLIF тоже не лезли.

Я изучал более-менее generic компрессоры которые от PNG не так уж отличаются и что там арифметики могут видел. Единственное крупное отличие PNG от архивера - префильтры. Современные архиверы впрочем умеют в префильтры и сами порой, а арифметик как EC из фавора выпал. Потому что тормоз, а со временем придумали ряд способов которые не патентованы и лучше работают. Наиболее свежее на тему - выводки ANS (asymmetric numeral system). Сочетает скорость хаффмана и сжатие арифметика. За что и юзается в НОВЫХ компрессорах.

>> курьез "насколько можно сжать, если долбануться?!"
> Зато математика долгоживучая - пример хороший, сферичность в вакууме его не портит.

Скорее программирование. К данным подшит по сути анпакер в формате виртуальной машины как я понимаю. По своему забавно, но единственная практическая ценность - несколько маньяков сделали убер-сжатие близкое к теоретическим лимитам. Но жмет пару кило в час и что хуже, распаковывает тоже, и рам жрет.

> Зачем писать "в честном lossless они png обычно не так уж и сильно обставляют",

Под честным lossless имеется в виду кодирование того что удобно для PNG. Всякие фоточки и проч - PNG для них и не создан. На lineart LZ может конеретно развернуться и взять свое. А если основное отыгрывается энтропией и преобразованиями, PNG туда никогда и не метил. Он "замена гиф".

> явно не поняли"? Одна таблица по ссылке. Оптимизированный PNG получился на
> 46% больше, чем JXL. В 2020 году, на солидном датасете.

Остается вопрос какие цели датасет преследовал. Ну и с практической точки зрения - да, PNG точно можно улучшить. Он старый. Зато...
1) Жрется вообще всем от чуть ли не с IE6, позволяет полноцветные картинки, и проч.
2) Не так уж и плохо жмет, если юзать по назначению. Т.е. схемы, графики, скрины программ, вот это все.
3) На его основе сделан APNG. Он жмет анимахи лучше GIF. И имеет забойнейший плюс: вот там реально обратная совместимость. Декодеры которые не знают про APNG - покажут первый фрейм который является валидным статичным PNG. И юзеры хоть что-то увидят. А не как вон там - это MP4, но у вас он играться не бу, дескать, что бардак и лулзы создает.

А так бандвиз от картинок напрягает только сильно некоторые сайты. Это ж не видео где даже пара мувиков может создать боль если на него юзеров набежит.

> Патенты истекли, для чтения стандарта жипега даже к itu.int

Ну так мышиная возня экспертов исы и сместилась куда-то в другие варианты. Может закончиться тем что все пробурчат что "раз AV1 везде есть, поюзаем AVIF, код уже есть!" и исовские эксперты надеящиеся подпихнуть чего-то патентованого опять обломятся.

> Не, про ситуацию с поддержкой. С первой ссылкой я промахнулся - это
> AV2, а багтрекер aom (AV1) не пролил свет на --use-16bit-internal в
> aomenc, в rav1e аналога, как видно, ещё нет, SVT-AV1 пока остаётся за кадром.

Я у себя просто нарулил билд ffmpeg с x264/x265/libaom/libvpx и еще немного, все из перечисленного гитовых версий. Как билдить Н.Е.Х. на хрусте и интерфейсить их либу в кастомную локацию узнает кто-нибудь другой. У SVT1 дурные требования к хардвару и приоритеты, откровенно обслуживает интересы интела. Libaom хорошо жмет и девелопается сбалансировано, без неинтересных мне загонов "под последний интелский проц" или "фигня, зато на хрусте". Так что если эти штуки вам интересны и вы понимаете почему - вот и изучите что они могут. Мне оказался интереснее libaom по общему набору свойств, я его и изучил. А чтобы составить мнение как это vs 264/265 я взял последние версии одних из наиболее мощных кодеков, x264 вообще чуть ли не лучшая реализация 264 считается, да и x265 явно не хучший как референс. Ну и VP9 логично взять как того кто серьезно сел на пятки 265. Тем более что я умею VP9 кодировать "выше среднего", что делает его интересным "референсом" на тему "насколько я этот уровень побью?".

> То есть ты делаешь так: ffmpeg [-i in.mkv]* -pix_fmt yuv420p10le -c:v libaom-av1
> out.mkv и получаешь на выходе 8 бит? Это невозможно.

Упс, я перепроверил - таки выход формально апгрейдится. А вот откуда я взял что он так и останется LBD - вот это вопрос.

> просто кодируешь 10-битное видео и что-то себе придумываешь про high/low bit
> depth. Ты ни разу в MediaInfo/ffprobe закодированного файла не смотрел?

Да вот почему-то отложилось что в ffprobe видел идентичные для файлов выводы. А нифига, пишет про 10le для второго. А за дотошность спасибо, очень круто когда кто-то разбирается в топике - и снабжен скепсисом и перепроверяет. Я так тоже проверил ваши (?) слова про arith vs jpg :P. У меня вышло 8..11%, поменьше чем у вас, но тоже неплохо так то.

> * Ниже предлагал вместо этого генерировать видео ради воспроизводимости у нас: [-f
> lavfi -i mandelbrot=s=2000x2000 -vframes 1]

Я ради воспроизводимости юзаю нежатые RAW последовательности от Xiph, они более похожи на real world сценарии. И не испорчены чужими артефактами, любой новый артефакт как на ладони. Потому что метрики это круто, но финальный судья - зритель.

В BigBuckBunny например есть пара сложных для кодеков мест: начальный fade in и титры. В первом они норовят сартефачить, ибо деликатный плавный темноватый градиент - мерзко смотрится в стопкадре если отличается от идеала. И с 8-битным процессингом он в AV1 грубоват даже если бандвиза хватает и проч. А форсирование 10le - совсем другая история. И титры в конце - нехило стресстестят motion compensation а заодно - и к каким артефактам может привести. Ну или TOS3K - 3000 нежатых фреймов Tears Of Steel, там и фильмообразный контент и sci-fi. Эти кадры не зависят от декодеров, постпроцессинга, .... и похожи на обычный нормальный контент. Чем и интересны.

Более того - я сравнивал сугубо 2-проходное кодирование. Тупо потому что извините, но 1-проходным я не пользуюсь почти. Мне не интересны сценарии далекие от того чем я потом буду пользоваться для себя. Если я трачу время - я должен поиметь с этого какой-то измеримый бонус для себя, а не просто изучение всей мыслимой фигни на планете как энтомолог.

> - на входе энкодера 10 бит (HBD) из-за yuv420p10le
> - повышение разрядности уже произошло из-за yuv420p10le
> - на выходе HBD - на входе HBD, почему ты не замечаешь?

Да, я все же прогнал что выход как HBD не маркируется. Но реально лучше выглядит даже LBD, допустим тот же BBB из yuv420p (y4m, укачан, по моему, с xiph.org). Особенно вон тот градиент в начале.

С LBD пайпом AV1 может казать любые цифры, обставляя в кривых вон тех, в целом визуальное качество лучше. Но! Если на начальном fade in нас встречает в стопкадре дискретизация градиента, это обидно. И радости с офигенных метрик вот так - сильно меньше. Метрики метриками, А глаза глазами. А с вон тем - и файло меньше (даром что "HBD") и - вот - последняя претензия к качеству картинки испарилась. После этого я уже не знаю что ему предъявить, так что можно просто взять и насладиться кодированием вместо этого :)

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

Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

297. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (135), 17-Ноя-23, 04:08 
> Так это не я полез JPG с PNG сравнивать.

Ну не я же. Можно было просто извиниться за невнимательность и непрошеные лекции.

Если ты увидел такое сравнение в #136, то там ещё и H.264. Но лекция о разнице между видео и картинками не нужна. Коммент должен был подтолкнуть Аноньимъ'а и сочувствующих к рассказу о потенциале H.264*. Мол, вот PNG, упёршийся в свой предел, вот JPEG, где неиспользованный потенциал перед носом, но использовать этот потенциал - ССЗБ, вот H.264, где потенциал есть в 8=>10 бит, но применение которого ограничивается отсутствием аппаратного декодирования профиля high10. А где же ещё потенциал, вдруг тут рассказали бы что полезное про нейронки или ROI.

* Ведь он многозначительно сказал вот это и захотелось услышать о новых способах кодирования:
> Внезапно есть не один и не 10 и даже не 100 способов кодировать в AVC.

Нафига в контексте перспектив H.264 переходить на поиск основного ограничения PNG? https://xkcd.com/386/ это сильный мотив, но мы говорили о потенциальных фишках H.264. Пусть будет не основное. Совсем не ограничение, потому что пренебрежимо малое? Тут я поверю или эксперименту, или разработчикам lossless-кодеков, которые после PNG арифметик иногда выбирали, но не анониму, открывшему повышение разрядности через 10 лет после остальных.

> По своему забавно, но единственная практическая ценность -
> несколько маньяков сделали убер-сжатие близкое к теоретическим лимитам. Но жмет пару
> кило в час и что хуже, распаковывает тоже, и рам жрет.

Ну, не обязательно жать на максимальных настройках. Там ещё в формат фич добавили (инкрементальное обновление архивов и т.д.). Только на убер-сжатие нацелены экспериментальные PAQ'и, а ZPAQ даёт их стандартизированный вариант. PAQ'и только для рекордов, без совместимости между версиями и т.д., а это адаптация для практического использования, если хочется странного.

> Под честным lossless имеется в виду кодирование того что удобно для PNG.
> Всякие фоточки и проч - PNG для них и не создан.
> На lineart LZ может конеретно развернуться и взять свое. А если
> основное отыгрывается энтропией и преобразованиями, PNG туда никогда и не метил.
> Он "замена гиф".

Если бы это имело отношение к "они [например, JXL, FLIF] png обычно не так уж и сильно обставляют" и другому комменту не противоречило...
> Честный = bit-identical битмап на выходе, разумеется.
> Остается вопрос какие цели датасет преследовал.

Он сгруппирован по страницам, можно смотреть на результаты в разных сценариях. Разве что можно пожалеть, что это несвободные изображения с местами протухшими ссылками.

> Может закончиться тем что все пробурчат что "раз AV1 везде есть,
> поюзаем AVIF, код уже есть!"

Получится катастрофа. JPEG XL позиционируется как royalty-free, имеет lossless-пережатие JPEG'ов, он лучше гугловских кодеков в lossless и проигрывал только в сильно сжатом lossy, ЕМНИП. Променять его на зоопарк из WebP, AVIF и потенциально WebP 2, AVIF@AV2? Можно, если перепутать интересы пользователей с интересами Google. L, по словам одного из его разработчиков, - Long term. Один кодек лет на 30 со всеобщей поддержкой снова бы не помешал.

С AV1 иначе - он хорош и он поддерживается в софте и железе, когда его конкурент опаздывает на вечеринку и больше не имеет мягкого лицензирования в духе H.264.

> Так что если эти штуки вам интересны и вы понимаете почему - вот и изучите что они могут

Интересно было понять, о чём ты говоришь и почему фича противоречила твоему описанию. Тогда до кучи про SVT-AV1, вроде оно:
--hbd-md  Enable high bit depth mode decision (0: OFF, 1: ON partially[default],2: fully ON).

Ответить | Правка | Наверх | Cообщить модератору

112. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (24), 11-Ноя-23, 23:48 
libaom - это референсная реализация, а отнюдь не лучшая. Лучший на сегодня декодер - libdav1d, лучший кодер - SVT-AV1.
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

114. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (20), 11-Ноя-23, 23:54 
> лучший кодер - SVT-AV1.

Отличная шутка. Будем откровенны, лучший кодер это nvenc тогда уж. Libaom это не только референсная реализация, но и единственная практически применимая. С libvpx ситуация ровно та же (более того, libaom её форк).

Ответить | Правка | Наверх | Cообщить модератору

132. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (24), 12-Ноя-23, 04:56 
NVENC хорош для realtime. Для хранения в хорошем качестве софтовый кодер лучше.

А про libaom vs. SVT-AV1 - можете дальше смеяться, то второй уделает первый и по скорости, и по качеству. Последние релизы SVT-AV1 очень сильно подняли скорость, и стало возможным использовать более тяжелые пресеты.

Ответить | Правка | Наверх | Cообщить модератору

140. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (20), 12-Ноя-23, 11:00 
А на каком битрейте? Потому что с достаточным битрейтом сомнительная затея сравнивать. Это надо кметь, и понимать, куда смотреть и на каких сценах. Я просто хочу качество/эффективность не хуже vp9, и только libaom подбирается, и если бы не артефачил столько, было бы лучше. В 3 ветке качество очень сильно просело правда, в 2 было лучше, но её закопали.
Ответить | Правка | Наверх | Cообщить модератору

203. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 16:43 
> А на каком битрейте? Потому что с достаточным битрейтом сомнительная затея сравнивать.
> Это надо кметь, и понимать, куда смотреть и на каких сценах.

Поэтому нормальные люди давно используют Q-mode, или constrained-Q (для сети) а не целят в average bitrate как динозавры кодирования мыслящие до сих пор "сидюками" зачем-то.

> Я просто хочу качество/эффективность не хуже vp9, и только libaom подбирается,

Кодируй в Q-mode и ты увидишь кто на что на самом деле способен "без искусственных ограничений". Если надо декод на слабом проце или передачу по сети, лучше constrained-Q с ограничением на максимальный битрейт, чтобы сеть и декодер не грузить накрепко в интенсивных сценах.

NB: визуальное качество разных кодеков на одном и том же Q может и не совпадать 1 в 1, стоит проверять на вшивость глазами и метриками типа PSNR/SSIM/VMAF/... - хоть они и те еще показометры.

> и если бы не артефачил столько, было бы лучше. В 3
> ветке качество очень сильно просело правда, в 2 было лучше, но её закопали.

Это все про что? Если у тебя мощный прцо и ты хочешь libaom в режиме "ultimate" - гоняй его на скорости 1-2 (0 очень уж медленный), без нарезки на тайлы (ускоряет кодирование но снижает битрейт-качество).

И еще, даже LBD мувики лучше в HBD режиме кодировать. На doom9 есть пример как это делать...  это даст +30% времени на кодирование, зато...
1) Достигнутый битрейт будет процентов на 10 ниже (конкретнее от мувика зависит).
2) Картинка будет визуально лучше. Особенно в темных градиентах и проч где раньше ошибки округления вызывали странные лестницы и проч, станет идеально.

...а когда ты поймешь насколько это крутой кодек на его полной мощности, если проца есть, все эти 26x станут даром не :)

Ответить | Правка | Наверх | Cообщить модератору

162. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (162), 13-Ноя-23, 05:00 
>AV1 даёт приемлемое качество видео не низких битрейтах, что актуально для слабых смартфонов (дешевле 15 000 руб.). Пиндосы в своей википедии пишут:

Совершенно не бъётся с моими экспериментами. Чем меньше битрейт, тем больше нагрузка на CPU. Что логично -- выше степень сжатия равно выше вычислительная сложность.

Чтобы смотреть 1080р на Raspberry Pi 4, я делаю перекодирование с ключом -fastdecode, что делает видео раза в три больше, но по крайней мере вписывается в бюджет CPU.

С большим битрейтом оно может упираться в ширину канала, или даже в пропускную способность памяти девайса после декодирования, так что мест, где "слабый смартфон" может тормозить, тут полным-полно.

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

200. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 16:28 
> Совершенно не бъётся с моими экспериментами. Чем меньше битрейт, тем больше нагрузка
> на CPU. Что логично -- выше степень сжатия равно выше вычислительная сложность.

Это как? Чем меньше данных процессить - тем меньше вычислений. Это частично отыгрывает вычислительную сложность. А детали экспериментов описаны не были.

> -fastdecode, что делает видео раза в три больше, но по крайней
> мере вписывается в бюджет CPU.

Можно попробовать не звереть с битрейтом или качеством, при q-mode перейти на constrained-q и указать максимумом битрейт на котором декодер еще затыкается. И да, не забудьте frame-parallel, чтобы разные ядра можно было юзать.

И декодером - чего?

Ответить | Правка | Наверх | Cообщить модератору

66. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (-), 11-Ноя-23, 19:37 
> Технически av1 куда более ущербен

Почему-то гуры медиакодинга говорят ровно обратное, как минимум относительно H.265. У него больше вариантов кодирования партиций, есть очень продвинутые вещи типа CDEF или глобальной компенсации движения в куче вариантов, куда больше чем в 265, всякие фокусы для улучшения предсказаний коэффициентов,.... MPEG вообще не придумал ничего умнее чем понемногу оттуда обезьянить в новые кодеки. Ничего реально инновационного эти корпоративные холуи толкающие патенты в угоду нескольким жирнокорпам типа эплов и прочих нокий не придумали.

> и, видимо, никогда не займёт заметного места в индустрии.

Да вообще ерунда - поддерживается всеми современными телефонами, планшетами, GPU от нвидии, амд и интел (через вулкан вывешено именно хардварное декодирование, там экстеншн для этого есть)

> Благодаря его полнейшему провалу, адекватные альтернативы, если и появятся,
> никогда уже не смогут повторить хотя бы и такой "успех".

Благодаря этому "провалу" у ISO/MPEGLA/etc аппетиты резко поубавились, технологии шагнули вперед, H.265 с его патентами не смогли выкручивать внаглую руки - особенно в вебе, а ютуб так то гонит изумительную картинку при мизерном битрейте всему глобусу. У вас наверное более массовый сервис есть, работающий лучше.

> По крайней мере, до тех пор, пока превосходящие проприетарные технологии
> не отойдут в общественное достояние и не появится достаточно заинтересованных
> производителей (что, скорее всего, не случится).

Это какие превосходящие проприетарные технологии? Так что у того же H.265 лучший кодек x265 однако. Он опенсорсный, но еще патенты есть. Конечно, можно кормить амеровский эпл и какие там еще нокии - но зачем?

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

82. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (20), 11-Ноя-23, 20:53 
Только x265 от индусов не использует алгоритмы, которые представлены, например, в JCTVC (и, я уверен, в нормальных проприетарных кодерах тоже), в результате, картинка весьма ощутимо отличается не в лучшую сторону. А вся эта продвинутость AV1 обламывается по причине искусственной ограниченности, толку от теории, если на практике доставить не способны?
Ответить | Правка | Наверх | Cообщить модератору

205. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 16:51 
> Только x265 от индусов не использует алгоритмы, которые представлены, например, в JCTVC
> (и, я уверен, в нормальных проприетарных кодерах тоже),

Это что - я еще за кодер должен платить? С ограничениями на какой оси и системной конфиге оно работать будет? А оно мне точно надо в таком виде когда я могу бесплатно сабж с libaom взять? :)

> в результате, картинка весьма ощутимо отличается не в лучшую сторону.

И, конечно, нам покажут пруфы, с указанием конфиг, скринами, объективными метриками и проч? А то в виденых бенчах AV1 делал все живое. И я лично научился из него такое выжимать что нахрен мне ваши проприетарные кодеры вперлись, скажем прямо. Спасибо народу с doom9, крутые ребята.

> А вся эта продвинутость AV1 обламывается по причине искусственной ограниченности,
> толку от теории, если на практике доставить не способны?

Там как раз искусственных ограничений минимум. А вот проприетарная хня будет ставить искусственные палки в колеса. Ибо маркетинг. И уж точно не сожрет "что угодно -> AV1".

Представляете, сабж может даже пачку PMG -> AV1 заделать. Или скажем APNG <-> AV1. А попробуйте так вообще проприетарным кодером. Или вон тот bink из проприетарной гамесы можно во что-то перегнать. В том числе и это. А прпертарь так может? А, нет? И кстати сабж до кучи еще и неплохой скринрекордер так то, если кому командлайн по вкусу. И камеру открыть он тоже не обломается. Конечно сразу в AV1 это не стоит, разве что на реалтайм пресетах. Но ваша гребаная проприетарь и 5% от этого не умеет. А денег будет вымогать за десятерых.

Ответить | Правка | Наверх | Cообщить модератору

206. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (20), 13-Ноя-23, 17:08 
Рассуждения дилетанта. Ффмпег сам по себе очень кривая поделка. Глючные фильтры и конверсии, никакущая поддержка основных форматов (таких, как mp4, хотя стандарт -- вот же он, открытый, бери не хочу, но нет) или там wave, теги никуда не годятся, да все файлы кривые в итоге и хорошо, если не совершенно битые. Кстати, его части использовались в проприетарных продуктах. Но, части. Не те, на которые ты наяриваешь.
Ответить | Правка | Наверх | Cообщить модератору

223. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 21:15 
> Рассуждения дилетанта.

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

Хорошо быть капитаном^W дилетантом, как говорится :)

> Ффмпег сам по себе очень кривая поделка. Глючные фильтры и
> конверсии, никакущая поддержка основных форматов (таких, как mp4, хотя стандарт --

Да вообще-то это по сути единственная прога которая у меня сожлала вообще все на что у меня фантазии хватило, от apng и и гифок до bink и smk из разных гамез, под который иных кодеков так то толком и нету, только проприетарный SDK от RadGameTools по цене чугунного моста и с кучей условий, включая NDA. Это конечно охрененные условия, особенно чтобы мувик разок в жизни конвертнуть. Сам не понимаю чего я в очередь не выстроился за этой проприетарью. Спасители человечества мля, что б мы без таких делали. А, да, vcmi (открытый движок геруев III) еще и играет заставки через ffmpeg'овские либы. Так что теперь я могу не спрашивать всяких проприетарных деятелей на каком мне проце ОС и ее версии играть в геруев III (честно купленных, между прочим). И я могу сделать удобно себе - а не каким-то проприетарным хренам. Вообще довольно логично чтобы за мои бабки было удобно - мне :)

> вот же он, открытый, бери не хочу, но нет) или там
> wave, теги никуда не годятся, да все файлы кривые в итоге
> и хорошо, если не совершенно битые. Кстати, его части использовались в
> проприетарных продуктах. Но, части. Не те, на которые ты наяриваешь.

А мне до этого всего какое дело, интересно? Мой профит с ffmpeg - универсальная штука которая жрет все что шевелится, делает меня всемогущим в вопросах видео, и конкурентов у него - ну вот просто нет.

Для себя я сделал как минимум
1) Bulk transcode с авто-детектом разворота камеры на момент съемки чтобы при игрании этого потом не тратить ресурсы на поворот видео в правильный ракурс.
2) Я смог скроить мощный пайплайн фильтров вытягивающий совершенно непотребные видео снятые в темноте где в оригинале было нихрена не видно. А после некоторых приключений с подбором параметров фильтров случилось практически волшебство, стало вполне понятно что на видео и проч. Мощные трехмерные денойзеры в паре с решарпингом и подстройкой параметров типа яркости и контраста - эээ.... а я такое суперкомбо в другой программе и не изображу за обозримое время.

Ответить | Правка | Наверх | Cообщить модератору

207. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (20), 13-Ноя-23, 17:11 
А, ну и встроенные кодеки дно примерно всегда. Глючное и устаревшее.
Ответить | Правка | К родителю #205 | Наверх | Cообщить модератору

2. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от adolfus (ok), 11-Ноя-23, 12:39 
Однажды понадобилось замедлить воспроизведение и внезапно обнаружился лютый ПЦ -- у mplayer при этом соответственно меняется и высота звука.
Ответить | Правка | Наверх | Cообщить модератору

4. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (4), 11-Ноя-23, 13:08 
Классическая проблема ускорения/замедления видео
Ответить | Правка | Наверх | Cообщить модератору

7. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от FF (?), 11-Ноя-23, 13:19 
Сколько здесь тех, кто слушал кассеты?
Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +7 +/
Сообщение от Аноним (20), 11-Ноя-23, 13:31 
Тут в основном любители бобин, кассеты всё больше смузиподелки низкого качества.
Ответить | Правка | Наверх | Cообщить модератору

14. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (14), 11-Ноя-23, 14:16 
пластики же!
Ответить | Правка | Наверх | Cообщить модератору

37. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (37), 11-Ноя-23, 17:11 
Восковые
Ответить | Правка | Наверх | Cообщить модератору

62. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +4 +/
Сообщение от Третий П (?), 11-Ноя-23, 19:33 
Настоящий линуксоид слушает только трекерную музыку. Ну или оркестр матричных принтеров и флоппи-дисководов на худой конец.
Ответить | Правка | Наверх | Cообщить модератору

167. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от ryoken (ok), 13-Ноя-23, 08:29 
Спасибо, напомнили. Послушал Флопотрон :).
Ответить | Правка | Наверх | Cообщить модератору

246. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 14-Ноя-23, 01:16 
> Спасибо, напомнили. Послушал Флопотрон :).

Почесал репу. Повертел в руках девайс где кусок флопаря и чип драйвера степера от него же интерфейснут к своему МК. Допрогал немного фирмварины в управлении степпером. Спасибо, чувак! Теперь он до кучи еще и динамик такой. Мерзенький конечно, но попиликать шаговым моторчиком - это утонченно, не отнять.

Впрочем, кажись, не уникальная идея - некоторые ESC трехфазником тоже умеют бибикать

Ответить | Правка | Наверх | Cообщить модератору

169. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от Аноним (169), 13-Ноя-23, 09:43 
Эффект Допплера?
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

5. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Третий П (?), 11-Ноя-23, 13:12 
Так это же весело.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

6. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от FF (?), 11-Ноя-23, 13:18 
Может не меняется высота, а не сделано ее удержание. Ускорение != Растяжение.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

11. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от крокодил мимо.. (?), 11-Ноя-23, 14:01 
> Однажды понадобилось замедлить воспроизведение и внезапно обнаружился лютый ПЦ -- у mplayer при этом соответственно меняется и высота звука...

иногда полезно читать man.. у mpv и mplayer специально фильтры (scaletempo[2]) и настройка --audio-pitch-correction (mpv, у mplayer аналогично) для контроля поведения при изменении скорости воспроизведения..

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

36. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +6 +/
Сообщение от all_glory_to_the_hypnotoad (ok), 11-Ноя-23, 17:07 
А мне однажды понадобилось увеличить картинку с веб сайта и, представляешь, там оказались какие-то пиксели!
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

229. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Минона (ok), 13-Ноя-23, 22:30 
Волоски это были, а не пиксели.
Ответить | Правка | Наверх | Cообщить модератору

174. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от mos87 (ok), 13-Ноя-23, 12:23 
man mpv

--audio-pitch-correction=<yes|no>
              If this is enabled (default), playing with a speed different from normal automatically inserts the scaletempo audio filter. For details, see  audio  filter
              section.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

314. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от adolfus (ok), 25-Ноя-23, 22:57 
> man mpv
> --audio-pitch-correction=<yes|no>

Опции при запуске не катят -- нужно запустить трек и гоняя его взад-вперед менять скорость, не меняя высоту тона.
Скорость нужно менять в процессе воспроизведения, используя клавиатурные комбинации, поскольку запускается mplayet из терминала.
Может будет достаточно в полтора раза темп уменьшить, а может в два -- это станет известно только в процессе.

Ответить | Правка | Наверх | Cообщить модератору

181. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от voiceofreason (?), 13-Ноя-23, 13:45 
Так и должно быть. Попытки менять длительность сохраняя питч (или наоборот) звучат максимально неестественно и режут ухо.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

216. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 13-Ноя-23, 20:37 
> Однажды понадобилось замедлить воспроизведение и внезапно обнаружился лютый ПЦ -- у mplayer
> при этом соответственно меняется и высота звука.

Vlc юзайте. Там есть фича поддерживать тембр звука. Звучит все равно специфично. Но лучше чем вон то.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

8. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +3 +/
Сообщение от anonymous (??), 11-Ноя-23, 13:26 
напомню что nlmeans офигенный шумодав, наверно самый продвинутый из опенсорсных. Ранние версии умели даже в соседние кадры заглядывать но в текущем почему то этого нет. Медленный конечно но вот теперь вулканом ускоряется.
Ответить | Правка | Наверх | Cообщить модератору

142. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (142), 12-Ноя-23, 12:18 
bm3d ещё очень хорош. Но его через vulkan в ffmpeg пока не сделали.
Ответить | Правка | Наверх | Cообщить модератору

10. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (10), 11-Ноя-23, 13:58 
А на рыксе 580 можно будет через вулкан ускорять AV-1?
Ответить | Правка | Наверх | Cообщить модератору

16. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от iPony129412 (?), 11-Ноя-23, 14:31 
Нет.
Это же аппаратные возможности.
Поэтому только в худшую сторону может (это не реализовали).
Ответить | Правка | Наверх | Cообщить модератору

18. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –3 +/
Сообщение от Аноним (20), 11-Ноя-23, 14:49 
Нет, иди покупай RTX 4090 для полноценной поддержки. Но сдался тебе этот av1, это же шлак абсолютный. Ты просто не хочешь иметь дел с поставщиками, которые тебе это пихают.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

34. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 11-Ноя-23, 17:01 
Там и ускорять нечего, видео на ютубе и без ускорения летают. А качественных видео, пожатых AV1 и не сыщешь, зато вот H.265 хоть отбавляй (все торрент-трекеры ими забиты). Google пускай дальше продвигает всякое говно, на мобилке то все равно нет разницы.
Ответить | Правка | Наверх | Cообщить модератору

154. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (163), 13-Ноя-23, 01:04 
> на ютубе и без ускорения летают

На достаточно мощном _десктопе_ — да.

Ответить | Правка | Наверх | Cообщить модератору

159. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 01:12 
У меня и на смартфоне хоть H264, хоть VP9 летают на ютубе. А какой-нибудь BDRemux даже с ускорением H264 тормозит, потому что битрейт там в разы выше.
Ответить | Правка | Наверх | Cообщить модератору

183. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от voiceofreason (?), 13-Ноя-23, 14:22 
Так в андроиде этих проблем изначально не было, как и в шинде. Да и на маке.
Ответить | Правка | Наверх | Cообщить модератору

198. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (31), 13-Ноя-23, 16:20 
А где они тогда есть? На устройствах 15-летней давности?  Потому что у меня и на линуксе все норм, по крайней мере, на десктопе.
Ответить | Правка | Наверх | Cообщить модератору

12. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (13), 11-Ноя-23, 14:04 
VVC декодер не завезли и как-то патчи со скоростью черепахи review'ят.

Жаль.

Ответить | Правка | Наверх | Cообщить модератору

17. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (17), 11-Ноя-23, 14:34 
Вот бы transcode возродили...
Ответить | Правка | Наверх | Cообщить модератору

19. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (19), 11-Ноя-23, 14:50 
>Добавлен парсер, кодировщик и декодировщик медиаконтейнеров в формате EVC (Essential Video Coding), развиваемом рабочей группой MPEG в качестве стандарта MPEG-5.

Лишь бы Матрёшку не стандартизировать.

Ответить | Правка | Наверх | Cообщить модератору

76. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Tron is Whistling (?), 11-Ноя-23, 20:32 
У матрёшки есть проблемы со стримингом. В теории решаемые - формат позволяет переупорядочить, но тем не менее.
Ответить | Правка | Наверх | Cообщить модератору

94. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (94), 11-Ноя-23, 21:49 
У webm (который - обрезанная матрёгка) нет, а у матрёшки - есть?
Ответить | Правка | Наверх | Cообщить модератору

124. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Tron is Whistling (?), 12-Ноя-23, 00:20 
Внезапно да. Те же куи в начало перенесены + ещё кое-что по мелочи.
В mkv тоже можно куи в начало перенести, но не все плееры этого ожидают.
Ответить | Правка | Наверх | Cообщить модератору

176. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от mos87 (ok), 13-Ноя-23, 12:45 
Как я понял, главное создать можно хз как - что всё будет плохо. На совести создающего.
Ответить | Правка | Наверх | Cообщить модератору

247. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (247), 14-Ноя-23, 01:22 
> У матрёшки есть проблемы со стримингом. В теории решаемые - формат позволяет
> переупорядочить, но тем не менее.

Не более чем у того же .mp4 - тот тоже может как быть fast start так и не быть, если индекс в конце. А так webm - subset матрешки и есть. Это вот какие бы у него проблемы с стримингом, весь ютуб так и работает. Там DASH в общем то унутрях. Сабж умеет это даже нарезать в том же стиле. Гугол у себя просто обфусцирует URL сегментации видимо чтобы не очень сэйвили качественный контент.

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

259. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (259), 14-Ноя-23, 18:25 
> У матрёшки есть проблемы со стримингом. В теории решаемые - формат позволяет
> переупорядочить, но тем не менее.

Не больше чем у MP4 какого. Webm прекрасно стримится. А то что можно сделать дурной файл - так и в mkv и в mp4 и в много чем еще - можно.

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

77. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Tron is Whistling (?), 11-Ноя-23, 20:33 
(идея положить куи в конец файла была норм для 2002, когда стриминг был в зачаточном состоянии, да, зато предварительное чтение контента с диска могло занимать феерическое время, поэтому что получилось, то и получилось)
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

96. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (94), 11-Ноя-23, 21:50 
range queries - и нет проблем. Если сервер не поддерживает ranges, то ффтопку его.
Ответить | Правка | Наверх | Cообщить модератору

120. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +2 +/
Сообщение от Tron is Whistling (?), 12-Ноя-23, 00:12 
Ещё раз. Стриминг. Нет в стриминге range, например однонаправленный радиоканал (вещание) точно никаких range не осилит.
Ответить | Правка | Наверх | Cообщить модератору

121. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Tron is Whistling (?), 12-Ноя-23, 00:13 
Если ближе к "цифре" - в том же мультикасте например удачи с range queries.
Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

100. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (100), 11-Ноя-23, 21:58 
Помогите новичку (неделю назад впервые поставил Ubuntu!!!) выбрать видеоплеер. Я читал на дваче, что нужно выбирать между этим ffmpeg и какмим-то mpv. Так вот!!! Какой лучше?!!!
Ответить | Правка | Наверх | Cообщить модератору

113. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Vladjmir (ok), 11-Ноя-23, 23:52 
Поставь все плееры и выбери, какой тебе больше всего понравится.
Ответить | Правка | Наверх | Cообщить модератору

137. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (137), 12-Ноя-23, 08:24 
База это MPV
а так у тебя выбор есть
для новичка вот https://pingvinus.ru/programs/multimedia/audio-players
Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

157. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от Аноним (163), 13-Ноя-23, 01:08 
Не слушай троллей, выбирай Xine.
(немного прифигел, что оно ещё живое)
Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

177. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +1 +/
Сообщение от mos87 (ok), 13-Ноя-23, 12:48 
почему модератор этот жыр оставляет?
Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

102. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Смузихлёб (ok), 11-Ноя-23, 21:59 
> Реализована возможность задействования API Vulkan для аппаратного декодирования видео в форматах H264, HEVC и AV1.

Какие-то реальные преимущества от этого есть?

Ответить | Правка | Наверх | Cообщить модератору

110. "Выпуск мультимедиа-пакета FFmpeg 6.1"  –1 +/
Сообщение от VladSh (?), 11-Ноя-23, 22:22 
Есть.
Ответить | Правка | Наверх | Cообщить модератору

128. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от MrGold (ok), 12-Ноя-23, 01:05 
Только что тестил.
RTX 4060 8GB + Flussonic 23.08.
Транскод - 20 потоков (live) 1080p 6mb/s to 3mb/s .
Все входящие потоки  h264.
При транскодировании в h265 и AV1 почти нету разницы в использовании ресурсов GPU , Enc - 60% Dec - 70%.
Ответить | Правка | Наверх | Cообщить модератору

226. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (226), 13-Ноя-23, 22:04 
Такое сравнение мне не интересно. Интересно на процессорах разницу посмотреть. Или с видеокартами разных цифр GT, 64 бит которые AV1 поддерживают. У меня Nvidia 1030 GT 64бит. Лишних денег нет и не нужна огромная печка ради видео и интернета. В игры не играю. 64бит вариант видеокарты куплен с понимание, что покупаю и для чего.  
Ответить | Правка | Наверх | Cообщить модератору

227. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (226), 13-Ноя-23, 22:05 
с пониманием
Ответить | Правка | Наверх | Cообщить модератору

228. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (226), 13-Ноя-23, 22:15 
Продолжил бы использовать дальше Nvidia 710 GT 64бит. Но сменил монитор. Понадобился HDMI 2.0. А у 710 HDMI 1.4.
Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

233. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (233), 13-Ноя-23, 23:11 
Если рассматривать кодеки для нас, а не для них как им надо. Как бы вы не рассуждали, а пока так: сжатие или транскодирование с x264 для слабых процессоров или средних, и видеокарт без поддержки AV1 кодирования остаётся лучшим вариантом качество, время, размер. Это если не для коммерческого использования кодировать. Если что-то связанное с деньгами тогда наверно компромис VP9. Мне хранить видео не надо. Я обработал видео, отдал, посмотрели и всё. А есть вариант MJPEG видео кодек тот, что в FFDshow, кодирует с битрейтом диапазон 10000 - 60000 клбит, тоже визуально смотрится не плохо. Есть PNG видео кодек битрейт 50000 клбит и подобные с битрейтом десятки тысяч клбит. В зависимости от размера получаемого видео и качества использую когда меня это устраивает x264 с настройкой сжатие без потерь.
Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

234. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (233), 13-Ноя-23, 23:16 
А когда меня не устраивает размер получаемого файла кодированного x264 с настройкой сжатие без потерь. Кодирую x264 с потерями.
Ответить | Правка | Наверх | Cообщить модератору

235. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (233), 13-Ноя-23, 23:22 
И качество видео для меня, для моих задач второстепенно, главное смысл понятен и всё. На меня ровняться не совсем конкретно. Я предпочту меньше время затраченное на кодирование и меньше размер получаемого файла в ущерб качеству.
Ответить | Правка | К родителю #233 | Наверх | Cообщить модератору

248. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (247), 14-Ноя-23, 01:26 
> и всё. На меня ровняться не совсем конкретно. Я предпочту меньше
> время затраченное на кодирование и меньше размер получаемого файла в ущерб
> качеству.

Это к сожалению может привести к тому что на выходе будут "шевелящиеся квадратики". Нэффективный кодек с мелким битрейтом - выглядит как-то так.

А так жмите в MP4 какой простой. Ну там H.264 main profile. Или если еще быстрее, есть и более лажовые профайлы, типа simple - и прочие xvid, но там как раз с соотношением битрейт-качество печально. Если получите мелкий файл - будете смотреть на квадратики.

Ответить | Правка | Наверх | Cообщить модератору

249. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (249), 14-Ноя-23, 05:40 
"MJPEG видео кодек тот, что в FFDshow, кодирует с битрейтом диапазон 10000 - 60000 клбит" Кодировать этим кодеком можно и с меньшим битрейтом. Если использовать MJPEG 10000 клбит это то с чего я начну смотреть на качество сжатия у MJPEG, а дальше или понижать или повышать или оставлять. 10000 клбит это условно, битрейт переменный, выбор из quantizer 1-31 и quality 0-100.
Ответить | Правка | К родителю #233 | Наверх | Cообщить модератору

250. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (249), 14-Ноя-23, 05:43 
quantizer 1-31 или quality 0-100.
Ответить | Правка | Наверх | Cообщить модератору

261. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (256), 14-Ноя-23, 18:35 
1030 аппаратно не поддерживает av1, если что
Самое новое, что поддерживает аппаратно - это av1
Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

280. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (256), 15-Ноя-23, 15:09 
Поправка - поддерживает не av1, а VP9
Ответить | Правка | Наверх | Cообщить модератору

299. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (249), 17-Ноя-23, 09:13 
Я пишу из виртуализации. Я даже не смотрел какие кодеки поддерживаются в 1030. Меня аппаратное ускорение видеокартой не интересует, только если кодирование видеокартой, а не декодирование. 720p мне хватает. VP9 предполагал, что да, AV1 предполагал, что нет. Понятно почему не интересует процессор с 720p и 1080p справляется с запасом то что в ютьюбе и на сайтах, то видео что не с битрейтом десятки тысяч клбит.
Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

300. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (249), 17-Ноя-23, 09:22 
А вообще проверял, но как-то уже забыл сколько на процессоре вытянет в плеере в хоосте. 1080p 30 кадров 20000 клбит наверно вытянит процессор на уровне 50-60% нагрузки. А с 60 кадрами не знаю не помню. Я в своё время это проверял, но забыл за ненадобностью смотреть видео в разрешении 1080p и выше.
Ответить | Правка | Наверх | Cообщить модератору

301. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (249), 17-Ноя-23, 09:28 
Конечно я не против, чтобы декодирование и кодирование всё было средствами видеокарты если это быстрее процессора. Я когда покупал видеокарту тоже на это не смотрел.
Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

302. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (249), 17-Ноя-23, 09:31 
Сжатие видео файла через видеокарту, кодировать и декодировать файл только видеокартой.
Ответить | Правка | Наверх | Cообщить модератору

170. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Tester (??), 13-Ноя-23, 10:46 
когдато под wince arm собирал 0.6, успехов проекту
Ответить | Правка | Наверх | Cообщить модератору

255. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (255), 14-Ноя-23, 17:16 
>обавлен парсер, кодировщик и декодировщик медиаконтейнеров в формате EVC (Essential Video Coding), развиваемом рабочей группой MPEG в качестве стандарта MPEG-5.

МПЕГЛА сильна ругацца?

Ответить | Правка | Наверх | Cообщить модератору

262. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (256), 14-Ноя-23, 18:37 
Почему никто не говорит, опередил ля av1 по скорости (и качеству) хотя бы x264 placebo?
Последние тесты, которые видел, показывали, что он медленнее в 800 раз
Ответить | Правка | Наверх | Cообщить модератору

296. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (-), 16-Ноя-23, 19:10 
> Почему никто не говорит, опередил ля av1 по скорости (и качеству) хотя
> бы x264 placebo?
> Последние тесты, которые видел, показывали, что он медленнее в 800 раз

Вы явно коменты не читали.
1) Если что в вулкан добавили вообще хардварные кодеры. Они так то быстрые, но битрейт-качество при этом хуже чем у софтварных.
2) Последние тесты какого года? В целом нехило разогнали, у меня получалось с практичными настройками примерно 25-30% от VP9 на пресете "good" cpu-used=1. Это конечно тоже не ракета, но кодируется мувик все же 1 раз за все время.
3) По битрейт качество x264 нечего ловить. Вон там аноним показал на картинке графиков битрейт-качество как при равном качестве VP1 сделает файло в 2 раза меньше. Это намного более мощный кодек. Он и 265 с отрывом обставляет, тот скорее с VP9 сравнивать уместно.

Ответить | Правка | Наверх | Cообщить модератору

263. "Выпуск мультимедиа-пакета FFmpeg 6.1"  +/
Сообщение от Аноним (256), 14-Ноя-23, 20:23 
Конечно, новинки  - это неплохо, а открытый кодек так или иначе лучше для всех, чем закрытый.
Но вопрос в доступности. Есть ли смысл кодировать av1 на домашнем компе (а это 6 ядер и меньше обычно)?
И это не говоря о том, что аппаратное воспроизведение av1 означает покупку новой видеокарты. А с бюджетками дело плохо. Это минимум за 15к (intel arc a310), или за 23к(RTX 3050), или 30к от AMD - RX 7600, или смену процессора на новый с новой встройкой, а это не меньшие деньги за переезд на новую платформу(CPU+RAM+материнка).
И это ради относительных преимуществ.
Чем  для меня визуально хороший видеофайл в x264 будет лучше визуально хорошего видеофайла в av1? Да ничем.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру