Главная | Настройки | NSFW
Тема:
Доски


[Ответить в тред] Ответить в тред

[Назад] [Обновить тред] [Вниз] [Каталог] [ Автообновление ] 138 / 36 / 39

Anonymous No.94184
Обсуждения кодеков тред.
Anonymous No.94185
>>2424
>>2429
Потому что кодеки vp9 и av1 в контейнере webm обладают более эффективным сжатием и лучше подходят для онлайн просмотра, чем устаревший avc/h.264 в твоем mp4.
Хочешь запостить видео? Сконвертируй! Благо есть куча средств для этого, например православный ffmpeg
Anonymous No.94186
>>94185
У H.264 есть аппаратное ускорение, мань.
Anonymous No.94187
>>94186
Сестра, vp9 имеет также аппаратное ускорение как на мобильниках, так и на ПК(Intel QSV ускоряет vp9 и hevc начиная со скайлейков), не даром же его гугл использует для ютуба
Anonymous No.94188
>>94187
> начиная со скайлейков
Ну повезло владельцам этих камней, ч0.
Anonymous No.94189
>>94187
Процент людей со скайлейком и определенными процами для мобильников на порядок меньше вездесущего H.264.
Anonymous No.94190
>>94189
Не забывай про видеокарты, они заимели аппаратное ускорение раньше. Мобильные процы имеют поддержку с 2014 года, т.е. 6 (!) лет назад. Шестилетнее оборудование - это уже довольно старое.
Anonymous No.94191
>>94187>>94186
>(Intel QSV ускоряет vp9 и hevc начиная со скайлейков)
>У H.264 есть аппаратное ускорение
А покажите браузер, который это умеет? У меня ни лисичка, не хромонога не умеют, так что кулер в небо улетает - а вот открытие тех же видео в нормальном видеоплеере требует в разы меньше ресурсов компьютера. Av1 в хромоноге даже лучше работает, чем в видеоплеере, так что дело не в накладных расходах браузера.
Anonymous No.94192
>>94191
Для хрома попробуй включить флаг chrome://flags/#ignore-gpu-blacklist в режим Enabled - это должно принудительно перенести обработку видео на видеокарту.
Можно еще добавить ключ запуска --enable-native-gpu-memory-buffers
В фаерфоксе вроде поумолчанию должно работать.
Anonymous No.94193
>>94192
Хм, помогло, спасибо. Теперь 3.8% в видеопроигрывателе и где-то 5.1% в хромоноге, что намного лучше прыгающих от 17% до 22% в лисичке.

>Можно еще добавить ключ запуска --enable-native-gpu-memory-buffers
А не знаешь случаем как решается проблема того, что если я запускаю браузер не напрямую, а кликая по ссылке (браузер выключен и настроен как браузер по умолчанию) - то он запускает без параметров запуска?
Anonymous No.94194
>>94193
>Хм, помогло, спасибо
Пожалуйста, а Кишка меня продолжает банить за пролапсы(
>А не знаешь случаем как решается проблема того, что если я запускаю браузер не напрямую, а кликая по ссылке
По-моему никак. Он же с параметрами по-умолчанию будет запускать.
Вот если браузер уже запущен и ты кликаешь где-то еще по ссылке - тогда ссылка откроется в запущенном с нужными параметрами хроме. Но ты это итак знал.
Anonymous No.94195
15726301371400.png (11 KB, 541x142)
>>94194
>По-моему никак.
Я вот так сделал, браузером по умолчанию стоит мой ексешник, который уже запускает ексшеник хромоноги с нужными мне параметрами.
Но это такой костыль, что я бы хотел его избежать.
Anonymous No.94196
>>94195
Неплохо. Кстати, по-моему управлять параметрами запуска можно через реестр виндовс. Я проверить это не могу, не под виндой сижу.
Anonymous No.94197
>>94190
https://en.wikipedia.org/wiki/VP9#Hardware_implementations
Да-да, с 2007 имеют поддержку.
VP9 нахуй не нужен, пока не будет работать без проблем на любой кофеварке. Гуглу просто похуй на то, что у вас пека греется, ему важнее траф экономить. Только почему мне не должно быть похуй на проблемы гугла с таким отношением?
Anonymous No.94198
>>94197
Что поделать, если хочешь пользоваться сервисами гугла, придется под него подстраиваться. Он ничего не потеряет если ты уйдешь.
Ну и другая проблема, что vp9 уже устарел. Сейчас все медиакомпании начали переход на av1, включая всякие нетфликсы и ютубы. Производители железа тоже подтягиваются. Это выгодно всем корпорациям - и трафик экономится и железки новые покупают и сервисы можно доставлять в регионах с плохим интернетом в нормальном визуальном качестве.
Anonymous No.94199
15726368161120.png (37 KB, 957x346)
15726368161371.png (39 KB, 966x367)
> экономия
впговно не в ту сторону экономит, пчел
Anonymous No.94200
>>94199
Экономит при одинаковом визуальном качестве. То что при таком же битрейте или битрейте выше - качество будет лучше чем у avc. Ну и еще все зависит от способа кодирования. Вряд ли гугл использует двухпроходное кодирование с наилучшим и долгим сжатием. Гугл в этом вопросе вообще не показатель. Кодируй и сравнивай сам.
Anonymous No.94201
>>94199
что это? как расшифровать?
Anonymous No.94202
>>94200
> разговор за гугл и его экономию
> Гугл в этом вопросе вообще не показатель
Понял+принял.
> Кодируй и сравнивай сам
Скодировал, сравнил, впговно в помойке, где ему и положено с его рейтконтролем.
Anonymous No.94203
>>94202
По-твоему в чем смысл кодирования гуглом в vp9/av1? Чтобы тебе поднасрать?
Хуево ты кодировал, если у тебя выходит качество в более эффективном годеке хуже чем в устаревшем. У тебя наверное и mp3 лучше заходит чем aac.
Anonymous No.94204
>>94203
Пообщавшись достаточно со свидетелями впговна убедился, что это они не осилили устаревшие технологии.
Anonymous No.94205
>>94204
avc нужно уметь готовить, там тысячи режимов кодирования под различные задачи и типы видео. с vp9 и другими - тоже самое. научись готовить.
Anonymous No.94206
>>94205
Смешно.
Anonymous No.94207
>>94205
Зачем использовать кодек, у которого сплошные минусы? Лучше H.264 вливать, оно будет играть на любой перделке.
Anonymous No.94208
>>94202
>впговно в помойке, где ему и положено с его рейтконтролем.
Vp9 отстаёт от h264 только в случае, если перекодируется 25 мб исходник в h264 в 20 мб. Тогда vp9 на 20 мб будет выглядеть хуже, из-за того, что меняется характер артефактов, и то, такое не всегда. Во всех остальных случаях даже на средних настройках в однопроходном режиме vp9 лучше h264.
В помойке оказался только h265. Даже h264 выглядит лучше. Может быть h265 и обладает более хорошим psnr/ssim при том же размере, но вот характер артефактов (диагональные линии вместо квадратов) абсолютно дикий, что в глаза бросается намного больше шумоквадратов. Ещё обещали на 25% более хорошее качество при сохранении времени кодирования, но вот этого я даже близко не обнаружил.


https://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/
Сравнение. Указано время кодирование и размер файлов. Почему-то некоторое время сайт лежал, но сейчас поднялся снова.

>>94197
>VP9#Hardware_implementations
Есть nvenc, который кодирует h264 на видеокарте. Но даже на самых хороших настройках его соотношение качества к размеру отвратительное. То есть аппаратный энкодинг вообще ни о чём, по крайне мере в случае h264.
Вот ffmpeg-строчка, -vcodec libx264 -preset:v medium -profile:v high -level 5.1 -crf 40 - попробуй найти параметры аппаратного энкодера, при котором он выдаст хотя бы такое же соотношения качества к размеру. Он очень сильно отстаёт, где-то на уровне ultrafast.
Anonymous No.94209
>>94208
Я с тобой, сектант, спорить не собираюсь, люди имеющие хоть какое-то отношение к кодированию видео имеют схожее с моим мнение.
Anonymous No.94210
>>94208
>Есть nvenc, который кодирует h264 на видеокарте.
Шизофреник, ты нить разговора потерял?
Я запускаю ФУЛОШДИ в H.264 и мой процессор почти не загружен.
Я запускаю ФУЛОШДИ в VP9 и ВЖЖЖЖЖЖ нагрузка пошла.
А теперь представь, как хуево от этого мобильному процессору. Нахуй мне КОДИРОВАТЬ, а?
Anonymous No.94211
>>94210
Потому что он скозал, не нравится не кодируй, мне не нравится, я не кодирую.
Anonymous No.94212
>>94202
>Скодировал, сравнил, впговно в помойке
Так ты даун кодируй из несжатого исходника, из оригинала, а не из h.264 в vp9. Естественно, что сжатое переимать - качество ухудшится.
Anonymous No.94213
>>94210
Это твои проблемы что у тебя устаревшее железо. Когда-то аппаратного декодера небыло и для h264, и что теперь? Это твои личные проблемы.
На мобильниках процы отлично декодируют vp9 аппаратно уже более пяти лет. У многих смартфоны по пять лет не задерживаются.

И если vp9 и av1 такие хуевые, что же все враз начали на них переходить? Ты можешь подскажешь им, может одумаются, тебе же виднее.
Anonymous No.94214
>>94213
>у тебя устаревшее железо
А теперь иди смотреть ссылку выше.
Core i7-6700 устаревший? А GeForce RTX 2080? А Ryzen 7 3XXX?
>Когда-то аппаратного декодера небыло и для h264
Логично, что его не было, когда он только вот появился. Только вот так себе аргумент, на самом-то деле, ведь на тот момент аппаратного ускорения видео вообще нигде практически не было, жуйте DivX.
>На мобильниках процы отлично декодируют vp9 аппаратно уже более пяти лет.
Особенно иронично твой пост смотрится на фоне того, что кодеку всего 5 лет, лол.
>И если vp9 и av1 такие хуевые, что же все враз начали на них переходить?
То-то во всех потребительских камерах и плеерах есть поддержка H.264, и даже H.265, но никак не VP9 =)
Anonymous No.94215
>>94214
Непонятно тогда отчего же vp9 стал вытеснять avc? А теперь еще и av1 пожаловал. Так почему же?
Anonymous No.94216
>>94215
>vp9 стал вытеснять avc?
Где? Иди купи какой-нибудь блюрей и посмотри, что там используется.
VP8/9 - мертворожденные уродцы без задач, никто не стал даже заморачиваться с реализацией аппаратного ускорения для хуитки, которая нигде и не используется.
>av1 пожаловал
Куда пожаловал? Пока еще пытаются довести до ума, чтобы не сжирал процессор целиком.
Anonymous No.94217
>>94216
Ну зайди на сайт опенмедиа, нетфликс сделал ав1 приоритетным кодеком, ютуб уже начал вводить, фейсбук тоже, ну и т.д. Я говорю про ав1 как формат для интернетов, а не блюрей, кому они сейчас нужны, если все смотрят в основном либо онлайн либо скачивают.
Anonymous No.94218
>>94217
>нетфликс сделал ав1 приоритетным кодеком, ютуб уже начал вводить, фейсбук тоже, ну и т.д.
Т.е. полторы штуки и в качестве эксперимента. Года через 3 может и родят чего.
>а не блюрей, кому они сейчас
Ты удивишься, но до сих пор живы DVD с MPEG2.
>если все смотрят в основном либо онлайн либо скачивают.
То-то на русракере маняме в VP9 кодируют xD
Anonymous No.94219
>>94218
У вп9 есть плюс: на низких битрейтах нету артефактов и "квадратиков" как на авц. Да картинка от этого замыливается, но при учете что это низки битрейт - гораздо лучше авц. Собственно, что авц, что ав1 - создавались именно для интернета и для поддержки низких битрейтов.
Anonymous No.94220
>>94219
>на низких битрейтах
Не актуально, уже 4G вводят. Да даже 3G хватит при условии хорошего качества связи. А еще для мобильников важна батарейка, тут идет в ход аппаратное ускорение.
VP8/9 хорош только в одном единственном случае - если тебе нужен кодек без лицензионных отчислений-роялтей и прочей хуйни. Все.
Anonymous No.94221
>>94220
Ну как это не актуально. Актуально экономить трафик. Как для владельцев мобильных так и для корпораций.
Anonymous No.94222
>>94221
Выше уже выяснили, что ютубу похер, так что если на корпорации не работают упоротые сектанты, то никакой экономией трафика там не пахнет.
Anonymous No.94223
15726434469040.png (54 KB, 800x666)
15726434469421.png (70 KB, 1190x820)
>>94216
>Пока еще пытаются довести до ума, чтобы не сжирал процессор целиком.
Его бы наоборот доводить, чтобы он хотя бы процессор мог сожрать целиком.




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

Найденные графики говорят что vp8≈h264, vp9≈h265, av1≈.. - во всех случаях кодек "для архивирования" появляется на несколько лет раньше эквивалентного кодека для стриминга.
Anonymous No.94224
>>94221
>Актуально экономить трафик.
Кому надо экономить траф, тот не смотрит видосики. А кому не надо, у тех давно уже безлимит, ау.
>Как для владельцев мобильных так и для корпораций.
Разве что только копрорациям. А пока они не родят аппаратное ускорение в каждой затычке - могут идти нахуй.
Anonymous No.94225
>>94223
И опять следов качественного архивного кодирования на использующих сервисах не выявлено.
Anonymous No.94226
>>94185
> av1
Да, ценой неадекватно долгого энкодинга. Минута hd видео давится несколько часов.
> vp9
Больше нет, чем да, если говорить именно об использовании vp9 в тредах на АИБ. На практике - незначительное преимущество.
https://arhivach.ng/thread/419349/
Первые посты в треде.

О тактическом умалчивании того, что в webm контейнер можно запихать и vp8, который по эффективности сжатия, конкурент разве что мертворожденному pre-avc мусору, типа spark, indeo, realvideo, может еще чему-то подобному, упоминать стоит?

В чем проблема раскрыть этот секрет полишенеля, и сказать, что webm-only политика служит как
-защита от дублей, aka перезалив из твиттера, телеги, инсты, ютуба, и вконтакта, из-за которых по борде разлетаются десятки версий одного и того же
-защита от быдла и быдлоконтента: чтобы залить видео, надо его заэнкодить, а пока энкодер будет рожать, можно и перехотеть постить
-дань культуре: каждый раз качать и жать никто не будет, придется собирать пак, как раньше собирали паки с картинками.
Anonymous No.94227
>>94226
>Да, ценой неадекватно долгого энкодинга. Минута hd видео давится несколько часов.
Так это пока. Он даже в ffmpeg работает в экспериментальном режиме. Нету пока и поддержки со стороны железа. Вроде следующие железки должны его поддерживать. Кому надо будет кодировать - купят.
Имхо, av1 - хорошая замена gif. Фалы очень маленькие и гифки годируются в av1 не так уж долго.
Про vp8 и т.д. умалчивают потому что качество проигрывает даже avc.

Что мне не нравится в вебм - звук либо opus либо vorbis. А они проигрывают aac/he-acc_v2/aac/sbr
Anonymous No.94228
>>94227
>av1 - хорошая замена gif.
У gif есть несколько мощнейших преимуществ:
1. Оно работает везде
2. Оно не жрет почти нихуя
Anonymous No.94229
>>94227
> А они проигрывают aac/he-acc_v2/aac/sbr
Что за бред?
Anonymous No.94230
>>94229
ну разные версии кодеков aac это
Anonymous No.94231
15728666480890.jpg (58 KB, 454x454)
>>2624
15 минут ждал, пока на этом сайте 1.8 мб мп4 сконвертится в вебм, а там 403 вместо моего видева:(
Anonymous No.94232
>>94231
господи, ну сделай сам, скачай ffmpeg и запусти примерно такую команду:
ffmpeg -i /путь/до/файла/видео.mp4 -map 0:0 -map 0:1 -c:a opus -ab 64k -strict -2 -async 1 -c:v libvpx-vp9 -b:v 600k -maxrate 1200k -bufsize 1200k -pix_fmt yuv420p -vsync 0 -auto-alt-ref 0 -vp8flags -altref -qmin 4 -qmax 63 -copyts -sn -y /путь/до/файла/вебм.webm
Лучше конечно в два прохода, но делай хотябы так.
Anonymous No.94233
>>94231
Если ты на винде, то можешь скачать готовые проги:
https://qwinff.github.io/downloads.html
или эту: https://tumba.ch/op/res/2940.html
Anonymous No.94234
15728697267050.webm (4311 KB, 640x640, 00:00:17)
>>94232
Уже скачал и попробовал команду
ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v 2M output.webm
размер вырос в 2.5 раза, качество вроде норм.
Сейчас попробую разобраться с твоей командой.
>>94233
Нет, у меня линукс к сожалению
Anonymous No.94235
>>94234
Танцульки, уважаемо.
Anonymous No.94236
>>94234
А как он не вырастет, если у тебе указанно в команде битрейт 2000кб/с ! Ты бы еще 100M поставил, размер был бы 400 мегабайт.
И в твоей команде нет параметров для кодирования звука.
Ты сначала узнай битрейт оригинала, потом кодируй с чуть меньшим битрейтом на 30-50%(в зависимости от видео).
Anonymous No.94237
>>94236
>Ты сначала узнай битрейт оригинала, потом кодируй с чуть меньшим битрейтом на 30-50%(в зависимости от видео).
Почему с меньшим? Битрейт видео 772, битрейт аудио 64.
>>94235
:3
Пост отредактировал Anonymous
Anonymous No.94238
>>94237
Потому что у vp9 и hevc степень сжати сильнее чем у avc/h264 и vp8
## System ## No.94239
Тред перенесен из >>/d/2666
Anonymous No.94241
>>94232
>-b:v 600k -maxrate 1200k -bufsize 1200k
Почему советуешь это, а не не [-b:v 0 -crf N]?

>>94234
Дай ссылку на исходник/залей на файлообменник - я тебе покажу как кодировать в vp9 сейчас.
Anonymous No.94243
>>94239
Какой ахуенный трипкод!
Anonymous No.94244
>>94241
https://anonfile.com/0bu2R696n8/15682329044750_mp4
Anonymous No.94251
>>94241
>-crf
Потому что он не сможет предугадать желаемый размер исходя из crf, и будет проще задать переменный битрейт, чтобы уложиться в желаемый размер файла.
Если бы он был на винде, то с crf проще работать ерез эту прогу(официальный тред проги): https://tumba.ch/op/res/2940.html
Anonymous No.94252
15728827028480.webm (4564 KB, 640x360, 00:00:30)
>>94232
-ab 64k
Я так понимаю, аб - аудио битрейт, да?
Не нашел этого в документации, https://ffmpeg.org/ffmpeg.html это официальные доки?
Anonymous No.94255
>>94252
да, это битрейт звуковой дорожки.
Anonymous No.94258
15728830255990.webm (840 KB, 640x640, 00:00:17)
>>94234
размер
Anonymous No.94259
>>94255
Не вижу этого флага в доках.
>>94258
Ты просто битрейт уменьшил или еще что-то?еще отзеркалил, да
upd. какой кодек и сколько конвертилось?
Пост отредактировал Anonymous
Anonymous No.94264
>>94259
блин, не убрал параметр отзеркаливания, я это не специально.
да, битрейт уменьшен до 320кб/с, но закодированно в два прохода. В сравнении с 2000кб/с смотрится как бы мало отличимо, чего не скажешь о размере.
Старайся брать битрейт адекватный качеству. Если исходник изначально не супер-мега 8k hdr, зачем нужен высокий битрейт?
Anonymous No.94266
15728838860810.png (12 KB, 622x262)
>>94251
Ставишь жуткий cpu-used и realtime пресет. Или кодируешь 10% видео и по ним бинарным поиском подбираешь нужное значение.
Если промахнёшься по размеру и там будет 18 мб вместо 20 мб, мне кажется качество всё-равно будет лучше, чем если гвоздями прибить ровно 20 мб.


>>94244
Ничего не понятно. Видео изначально очень плохого качества и в маленьком разрешении, там артефакты даже нет смысла исследовать. А ещё видео снято в 25/24 фпс, но перекодировано в 30 фпс - из-за чего иногда кадры дублируются и предсказание движения ломается - что не идёт на пользу сжатию. Плохой экземпляр для экспериментов.

>>94259
>еще отзеркалил, да
Чтобы нельзя было выбрать один и тот же кадр и сравнить качество.

>Не вижу этого флага в доках.
Он выпадает если ввести [ffmpeg -h]
Ещё можно указать -b:a.
Anonymous No.94269
15728842689610.webm (604 KB, 640x640, 00:00:17, av1)
15728842691671.webm (639 KB, 640x640, 00:00:17)
Ага, дефолтный av1 немного быстрее самых медленных настроек vp9. И vp9 сыпется с артефактами при более-менее таком же размере.
По хорошему надо бы без звука кодировать. Но если что в оригинале 64кбит, и тут я тоже поставил 64 кбит, но уже опуса.
Anonymous No.94270
>>94266
>Чтобы нельзя было выбрать один и тот же кадр и сравнить качество.
Нет, я просто до этого несколько видео подряд отзеркаливал, это видео кодировал так же.
Кстати, там не 24фпс, кажется что все 16-18.
И все это не правильно: мы кодируем уже пережатый по десять раз mp4, надо брать и тестировать на исходниках в ProRess. Когда я так тестировал - получал, что для vp9 можно смело уменьшать битрейт на 30-50% по сравнению с h264, а если это анимация - то можно уменьшить еще сильнее. Жаль что в webm невозможно кодировать звук в aac, потому что aac-HEv2+SBR звучит в тысячу раз лучше чем opus на низких битрейтах.
Anonymous No.94271
>>94269
ав1 ясное дело лучше, это видно же прям.
Anonymous No.94276
>>94266
https://anonfile.com/0b4cR098n2/15710040610353_mp4
Вот с битрейтом 1947 на видео и 128 на аудио.
https://anonfile.com/n768R69cne/15712179916580_mp4
Вот в 60 фпс.
Пост отредактировал Anonymous
Anonymous No.94277
15728849603930.webm (901 KB, 640x640, 00:00:17)
>>94270
>кажется что все 16-18.
Ага, дублируется чаще, чем каждый шестой (пятый) кадр.

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

Если бы он был на винде, я бы посоветовал ему использовать вот такой батник с однопроходным кодированием (оно в три раза быстрее двухпроходного, хотя впрочем и разница ощутима) для плохих видео и эквивалентный с crf 30/20 для средних и хороших качества; crf 30 - гарантия того, что артефакты будут слабозаметны вне зависимости от размера или частоты кадров. Меня это вполне устраивает. Не попадёт в лимит, но и зачем мне эта 1/256 оттенка цвета в каком-нибудь углу - если я всё-равно в жизни на этот угол не посмотрю?
:st
if %1=="" exit
echo %1
echo "%~dpn1.webm"
ffmpeg -i %1 -dn -sn -threads 8 -map_metadata -1 -c:v libvpx-vp9 -crf 40 -b:v 0 -c:a libopus -b:a 64k "%~dpn1_vp9-40.webm"
shift
goto st

Вот это видео от такого батника. Кодируется быстрее 17 секунд.

Opus вообще тот ещё мусор, я проводил для себя двойной слепой тест и vorbis во всех случаях мне понравился больше. На 40-60 кбит особенно (ниже 40к ворбис не умеет), а выше уже в общем-то без разницы.


>>94271
Ага. Но он замыливает всё-таки. Выбери отдельный кадр и посмотрю на ковёр. На mp4 видно на нём колтуны, а на av1 их намного меньше.
Anonymous No.94280
>>94277
>замыливает
Так это же хорошо: на лицах нет пор и прыщей, на коврах колтунов. А на mp4 при таком же размере были бы квадратики. Имхо, замыливание не так плохо смотрится как квадратики, особенно в движении.
Anonymous No.94282
>>94280
Видео снегопада, мелкой травы/сена или брызг попробуй покодируй. В квадратах и шумах оно лучше выглядит, чем в мыле, мне кажется.
Там в h264 появляются "травинки и капли которых не было", но воспринимается это естественнее. И ещё h265 с [–tune grain] уж точно справляется лучше vp9 с зашумлённой картинкой. С av1 не сравнивал, у меня компьютер всё-таки не очень для таких задач и тестов.
Anonymous No.94284
>>94282
ну... если сравнивать vp9 и h265, то последний конечно лучше в мелко детализации, кто же спорит.
vp9/av1 - это идеальные кодеки для рисованной анимации.
но и нужно помнить, что vp9/av1 не задумались как кодеки для кино, футажей для монтажа и так далее. они исключительно для веба, где совершенно другие требования - лишь бы приемлимо смотрелось и как можно быстрее грузилось.
Anonymous No.94287
15728866258140.webm (1037 KB, 284x160, 00:05:05)
15728866258301.webm (1027 KB, 284x160, 00:05:05, av1)
15728866259392.png (333 KB, 1129x319)
>>94284
>vp9/av1 - это идеальные кодеки для рисованной анимации.
vp9 не очень. Он не гнушается сдвигать линии, если ты понимаешь о чём я. Вот какой-то анон тут конвертировал отрывок в эти два формата, и можно заметить, что в vp9-версии эмоции на лицах искажаются, потому что он двигает линии искажая выражения лица.
Вот примерно 2873 кадр. Совсем разные лица.

Отрывок с танцовшицей всё ещё кодируется в av1, лол.
Anonymous No.94314
15728892167430.webm (1676 KB, 720x1280, 00:00:12)
15728892169731.webm (1711 KB, 720x1280, 00:00:12, av1)
Отконвертировалось. Так долго, тому что я сразу 20 разных конвертаций проводил с разными настройками.
Настройки av1: [-c:v libaom-av1 -strict -2 -b:v 0 -crf 40 -b:a 128k -c:a libopus] Стоило бы тоже -g 9999 указать - я переделаю и напишу, если появится разница.
Настройки vp9: [-speed 0 -c:v libvpx-vp9 -g 9999 -crf 40 -b:v 0 -pass 1 -an -f null] + [-speed 0 -c:v libvpx-vp9 -g 9999 -crf 40 -b:v 0 -b:a 128k -c:a libopus -pass 2
Пост отредактировал Anonymous
Anonymous No.94318
>>94314
У меня твои вторые вебмки не загружаются.
Пост отредактировал Anonymous
Anonymous No.94319
15728897522470.jpg (94 KB, 604x512)
>>94314
У нее такая неестественная улыбка, она скрывает боль.
Anonymous No.94324
>>94318
Во втором av1. Обнови браузер/кодек/mpv/ffmpeg
Anonymous No.94328
15728912796320.webm (780 KB, 1260x910, 00:00:16)
15728912797211.png (72 KB, 526x391)
Вот сравнения webp и av1 (из поста >>94309). Помню я сказал, что webp устарел - а кто-то мне возразил. Jpg на 47 кб конечно совсем страшный (вторая картинка), да, но av1 всё ещё имеет раза в три меньше артефактов по сравнению с исходником, чем webp.

>>94318
Но на самом деле не загружаются они у тебя. Превью то есть, верно? Борда скушала значит.
Anonymous No.94330
А на сосаче для av1 даже превью не делаются.
Anonymous No.94363
15728965902500.webm (19904 KB, 1280x720, 00:03:30)
Вот это жара, вот это скорость. 15 секунд за полтора часа.
frame= 479 fps=0.1 q=0.0 size= 970kB time=00:00:15.52 bitrate= 511.7kbits/s speed=0.00253x
Вебмрил родился за час 2 прохода, crf 46, -g 9999, cpu used 0, тайлы офф
Anonymous No.94365
av1 до сих пор не умеет использовать все ядра процессора? Уж больно долго ждать этого кодирования.
Мне кажется, что слишком большой битрейт. В 20 мегабайт надо умещать явно больше 3 минут. Надо чтобы было 15 минут на 20 мегабайт.
Anonymous No.94366
>>94363
>Вебмрил родился за час
А теперь давай то же самое в av1.
Anonymous No.94367
>>94365
Тут в 20 мегабайт кто-то 20 минутную серию умещал, кажется, во вполне неплохом качестве.
Anonymous No.94368
>>94365
Если что vp9 тоже не умеет использовать все ядра, хотя он значительно старше av1.
Anonymous No.94369
>>94365
Он странно нагружает процессор, то нагрузка залетает в полку, то минуту барахтается на 15%.
>Надо чтобы было 15 минут на 20 мегабайт.
Еще и в fullhd. В прошлый раз, 8 секунд fullhd клипа, жалось часов 12. Из высококачественного прорес исходника.
Anonymous No.94373
15728986248050.webm (20321 KB, 704x396, 00:32:28, av1)
>>94287
Мама, я в телевизоре. Сдалось же кому сохранить те вебм.
>>94365
Умеет, но только тайлами, если ничего не поменялось за пол года. С
-tiles 2x2 -cpu-used 8 -threads 6 -row-mt 1
вполне себе шустро кодилось Ну как шустро, rtime=48969.408s
Anonymous No.94375
15728999900120.webm (20370 KB, 704x396, 00:34:18, av1)
>>94373
> rtime=48969.408s
Нет, погодите, чет дичь выходит, явно меньше было, да и в двух бенчах показывает rtime=13926.060s. Мб я на паузу ставил или типа того? Эти числа явно реалистичнее выглядят.
Anonymous No.94377
>>94368
Но кодирует не так долго. Вообще смотря какое железо. Есть ведь аппаратная поддержка vp9 кодирования у новых видюх.
Anonymous No.94387
15729014930890.jpg (259 KB, 1532x834)
>Еще обратил внимание что вп9 то ли цвет/палитру пидорасит, то ли дискретизирует так жесско
Погляди на сайте из поста:>>94208. Видишь, что левый мужик краснее?
Вот тут ты прав был, по какой-то причине vp8/vp9 коверкают цвета.

Но я сейчас взял jpg-файл из пеинта, и поконвертировал, и искажение в сторону тёмных тонов есть только в h264/h265. А если взять png-файл из пеинта, то искажение исчезает. С чем это может быть связано? С отсутствием pix_fmt?
Anonymous No.94394
>>94387
>С чем это может быть связано?
https://habr.com/ru/post/136318/
Anonymous No.94402
А еще большой минус, что vp9 не имеет и не будет иметь поддержки на устройствах apple, а их в мире довольно много, особенно в мобильном трафике. Для нас это конечно не актуально, но это объясняет причину почему этот формат так вяло внедрялся.
Anonymous No.94421
>>94238
При пережатии в lossy-формат в любом случае будут потери качества. Чтобы их было меньше, есть смысл использовать тот же битрейт.

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

>>94251
А с чего ты взял, что ему нужно укладываться в определённый размер? Если лимита хватает с запасом, то это вообще контрпродуктивно: лучше указать желаемый уровень квантования чтобы кодек сам определил нужный для него битрейт, что и делается crf'ом.
Anonymous No.94423
>>94394
И что делать то? Я нашёл как явно из 601 в 709 перегнать через vf, но это же абсурд? Почему оно просто не может оставлять пиксели теми же цветами, в которых они и были - чтобы об этом думал не я, а разработчики ffmpeg-ов? Ну вот картинка у меня в jpg, зачем её трогать?
Anonymous No.94755
>>94190
>Шестилетнее оборудование - это уже довольно старое.
Кто сказал? Сейчас можно спокойно пользоваться 10+ годичным ПК. Особенно со свободным программным обеспечением.
Anonymous No.94772
>>94421
>А с чего ты взял, что ему нужно укладываться в определённый размер? Если лимита хватает с запасом, то это вообще контрпродуктивно: лучше указать желаемый уровень квантования чтобы кодек сам определил нужный для него битрейт, что и делается crf'ом.
Я хочу просто конвертировать мп4 в вемб без заметных потерь качества за разумное времянесколько секунд на секунду видео, размер не очень важен.

Анон с танцульками
Anonymous No.94863
>>94234
Любитель танцулек, блядь.
Anonymous No.95135
>>94863
Танцульки -- круто, шмыдло, насосач!
Anonymous No.100993
>>94772
В танцульках качество вторичное, там libvpx достаточно.
Anonymous No.101094
>>100993
>там libvpx достаточно.
А теперь объясняй, что это значит, не все тут продвинутые пользователи пк.
Anonymous No.101201
>>101094
Libvpx — это референсный энкодер форматов VP8 и VP9, по совместительству также самый распространённый, в т.ч. его использует ffmpeg.
Anonymous No.101218
15787751370570.jpg (52 KB, 500x500)
>>101201
>референсный энкодер
Anonymous No.101219
>>100993
От этого >>101201 поста понятнее не стало.
Давай сначала, есть танцулька в мп4, есть ффмпег, который из мп4 делает вемб.
Дальше, для чего мне надо знать про существование libvpx?
Anonymous No.101226
>>101218
Энкодер от авторов формата, имеющий статус эталонного. Обычно референсные энкодеры представляют из себя кое как работающую примитивную реализацию без оптимизаций, раскрывающую потенциал формата чуть более чем никак, но в случае с libvpx это не так: жмёт он неплохо, хоть и медленно. Впрочем, до оптимизации уровня x264 (наверно, лучшего энкодера формата H.264) ему далеко, вывозит только преимущество формата VP9, и то не всегда.

>>101219
Так ты разобраться хочешь или просто как-то что-то слепить, наплевав на детали? Если второе, то возьми у анимублядей
ffmpeg -i animu.mkv -b:v 0 -crf 30 out.webm
и хуячь, подставляя вместо animu.mkv файл со своими танцульками.
Anonymous No.101356
>>101226
>Энкодер от авторов формата, имеющий статус эталонного. Обычно референсные энкодеры представляют из себя кое как работающую примитивную реализацию без оптимизаций, раскрывающую потенциал формата чуть более чем никак, но в случае с libvpx это не так: жмёт он неплохо, хоть и медленно. Впрочем, до оптимизации уровня x264 (наверно, лучшего энкодера формата H.264) ему далеко, вывозит только преимущество формата VP9, и то не всегда.
Это всё очень интересно, но не понятно что с этим делать на практике.
Применять/неприменять, какие еще энкодеры есть, чем libvpx лучше/хуже?

>Так ты разобраться хочешь или просто как-то что-то слепить, наплевав на детали? Если второе, то возьми у анимублядей
>
ffmpeg -i animu.mkv -b:v 0 -crf 30 out.webm
>и хуячь, подставляя вместо animu.mkv файл со своими танцульками.
А можно тред перед ответом полностью читать? Просто как-то что-то слепить, наплевав на детали уже получилось >>94234
ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v 2M output.webm
Меня из результатов этой команды не устроил только размер, как я понял, это из-за слишком большого битрейта.
В итоге получается что-то типо:
ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v [i]как в оригинале[/i] output.webm
Anonymous No.101441
>>101356
> какие еще энкодеры есть, чем libvpx лучше/хуже?
Для форматов VP8 и VP9 считай, что альтернатив нет. Есть SVT-VP9, но его наличием объясняется разве что хуёвое сжатие VP9 на ютубе, а так его мало кто тестировал из-за большой ресурсоёмкости.

> Просто как-то что-то слепить, наплевав на детали уже получилось >>94234
А ты экспериментируй так и сяк. Из своего опыта могу сказать, что с -b:v 0 -crf <качество> результат (соотношение качество/битрейт) будет лучше чем с ограничением по битрейту. Ещё лушче будет если жать двумя проходами (после первого получится файл с пустой видеодорожкой и рядом лежащий ffmpeg2pass-0.log):
ffmpeg -i animu.mkv -b:v 0 -crf 30 -pass 1 out.webm
ffmpeg -i animu.mkv -b:v 0 -crf 30 -pass 2 out.webm

Да, при указании выходного формата webm «-c:v libvpx-vp9» используется по умолчанию.

Но нужность всего этого для сжатия каких-то снятых на телефон танцулек вызывает сомнения. Факт в том, что при пережатии уже содержащего артефакты видео ты в любом случае сделаешь только хуже, без вариантов. Можно разве что пробовать отмывать эти артефакты фильтрами и только после этого жать.
Anonymous No.101544
>>101441
>Можно разве что пробовать отмывать эти артефакты фильтрами и только после этого жать.
Цели улучшать качество не стоит.
>ffmpeg -i animu.mkv -b:v 0 -crf 30 -pass 1 out.webm
А что значит число "30" после "-crf"?
Anonymous No.101546
15790347856140.webm (20379 KB, 186x128, 01:27:05, av1)
Для ценителей
Anonymous No.101552
>>101546
>01:27:05
Не представляю, сколько это кодировалось. Хотя может не очень много из за низкого качества.
Anonymous No.101556
>>101552
16 часов.
Anonymous No.101558
>>101556
А теперь давай то же самое, но в fullhd. Через пол года не забудь отписаться с отчетом
Anonymous No.101560
>>101544
Грубо говоря, это параметр квантования. Это не он, но смысл близкий. Насколько существенная разница между исходным и итоговым кадром допустима.
Соответственно -crf 0 это кодирование без потерь, а -crf 63 это кодирование с большими отклонениями. 30 это среднее качество. Обычно 40 хватит для любого видео записанного на мобилку, 30 это достаточное качество для снятого на неплохую камеру куска, а отличие 20 от оригинала можно найти только на специально подобранных видео, рассматривая кадры на паузе - какой-нибудь контрасный компьютерный рендер или что-то такое.
Да, эта допустимое локальное отклонение - то есть если ты возьмёшь небольшую область из 320х240 и небольшую область из 234523х52352 видео, то отклонения на этих областях буду одинаковы, хотя второе видео всё ещё будет содержать в тысячи раз больше информации и во столько же раз более высокий битрейт. То есть crf 30 даст тебе примерно одинаковую заметность артефактов на видео с любой частотой кадров и любым разрешением, если его смотреть в оригинальном разрешении.

В общем-то возьми видео в хорошем качестве, вырежи кусок через -ss 00:31:12.009 -to 00:33:07.136, и отконвертируй его с разными cfr от 0 до 63 - сам всё увидишь.

>>101546
И как у тебя клавиатура нажалась конвертировать такое девственно чистым av1.
Anonymous No.101565
>>101558
Скинь слона в фуллхд, я подумаю.
>>101560
Пусть приобщается к высокому.
Anonymous No.101682
15791228401270.webm (20108 KB, 1920x1080, 00:01:07, av1)
>>101556
На таком разрешении работали тайлы или ты цельно кодил? Хотя даже так чет оче долго. У тебя там селерон?
Anonymous No.101686
>>101560
> девственно чистым
> энкодам боку но пико почти год
Где там мои сливы ремастера, ебана
Anonymous No.101687
даблпост
Пост отредактировал Anonymous
Anonymous No.101688
>>101682
А почему вторая дорожка с превью в VP9, а не в AV1?
Anonymous No.101691
15791256530310.webm (9909 KB, 1280x720, 00:03:30, av1)
>>101688
Тому що изначально я забыл прописать включение экспериментальных кодеков и не мог понять чому не работает, а когда через несколько дней осознал что делал не так, было лень менять.
Anonymous No.101704
15791479238560.png (69 KB, 295x245)
>>101682
> вебм
Эксперимент по сохранению артефактов соуса? В AV1 так обычно не бывает из-за CDEF: линии остаются гладкими даже на совсем низких битрейтах.
Anonymous No.101790
15792108430190.webm (20469 KB, 1920x1080, 00:01:07, av1)
>>101704
Ну почти. Нужен был этот оп хоть в каком качестве, а нормального бдрипа найти не смог.
Anonymous No.101793
>>101790
Во, тут уже заметно лучше, только в браузере всё монохромно-розовое из-за отсутствия поддержки десятибитного цвета, в т.ч. тапок на 16 секунде почти чистый. Другой соус или отмыто фильтрами адаптивного блюра?
Anonymous No.101802
15792401630290.png (161 KB, 1011x570)
>>101793
А у меня в браузере воспроизводится как надо. Видимо, десятибитный цвет в браузеры тоже завезли.
Anonymous No.101804
>>101793
>монохромно-розовое
>из-за отсутствия поддержки десятибитного цвета
Как эти вещи связаны?
Anonymous No.101806
15792483204360.png (130 KB, 930x650)
>>101804
Чтобы это выяснить, нужно расковыривать форматы фреймбуфера, которыми оперируют декодер и браузер. Факт в том, что все 10-битные видео выглядят вот так, независимо от кодека.
Anonymous No.101807
>>101806
У меня же факт в том, что любой браузер поддерживающий 10бит воспроизводит адекватными цветами, а не поддерживающий не воспроизводит.
Anonymous No.101808
Чтобы научить программу кодировать видео более-менее в лимит, нужна нейросеть или это можно математично посчитать? Что-то я битрейт подставлял, деля время на размер, а не получалось.
Anonymous No.101810
>>101808
А надо делить размер на время <размер в кб>*8/<время в сек>=<средний битрейт в кб/с>
Anonymous No.101813
>>101793
Другой сурс, взял человеческий бд.
> спойлер
Пожалуй, дальше надо кодить в 8-бит, у меня палитра нормальная, но малость фризит. Одни проблемы от этих инноваций. Когда там уже технологическую сингулярность завезут?
>>101808
На одной из соседних мелкоборд уже сделали такое: программа кодит часть видео и по размеру этой части подстраивает параметры. Ну, или как >>101810 написал. Не забудь выделить битрейт на аудио.
Anonymous No.101814
15792554147750.png (257 KB, 1000x800)
>>101813
>программа кодит часть видео
>размеру этой части подстраивает параметры
Anonymous No.101815
>>101814
> мемные стрелочки
Ну посчитай мне CRF, умник. 020.M3 на дворе, а народ не против выделить побольше битрейта на статичную картинку.
Anonymous No.101819
>>101810
И как в твоём посте различить килобайты и килобиты? Зачем ты путаешь анона?
Anonymous No.101840
>>101819
По умножению на восьмёрку.
Anonymous No.104049
15823271770810.webm (13305 KB, 1920x1072, 00:01:06, av1)
В формате AV1 есть офигительная фича: генератор шумов на стороне декодера. Задумка в том, что шумы преобразуются в короткое описание их характера и удаляются из сигнала, сигнал в отмытом до гладкости жопы младенца виде жмётся, а потом на стадии декодирования шумы восстанавливаются. Наверняка многие замечали конские скачки битрейта или резкие падения качества у H.264 и VP9 на сценах вроде вебмрелэйтеда — со снегом, дисторшном, артефактами киноленты и матрицы камеры, — так вот, с AV1 такого безобразия можно избежать.

Проблема в том, что просто взять и включить эту фичу существующий инструментарий не позволяет. Для её использования на данный момент нужно:
— сделать два видеофайла в формате yuv4mpeg, один с шумами и другой отмытый (т.к. этот формат нежатый, файлы будут конских объёмов):
ffmpeg -i source.mkv -f yuv4mpegpipe source.y4m
ffmpeg -i source.mkv -vf hqdn3d=5 -f yuv4mpegpipe denoised.y4m

— скормить их утилите noise_model из поставляемых с libaom примеров, зачем-то указав при этом fps и разрешение:
./examples/noise_model --fps=24000/1001 --width=1920 --height=1080 \
--input=source.y4m --input-denoised=denoised.y4m --output-grain-table=noise.tbl

— пожать отмытый поток aomenc'ом с указанием полученного файла:
aomenc --end-usage=q --cq-level=50 --film-grain-table=noise.tbm denoised.y4m -o out.webm

Чтобы не занимать десятки (а то и сотни) гигабайт места нежатыми потоками, их можно подавать noise_model'и прямо с вывода ffmpeg'а через дескрипторы. Для запуска noise_model таким макаром есть скрипт:
av1-film-grain-table
#!/usr/bin/env zsh
usage() {
cat <<END
Usage: $ZSH_NAME [options] input_video output.tbl
Generate film grain table model
Options:
-s start
-t length
-n denoice level (see hqdn3d ffmpeg filter)
END
exit 1
}
zparseopts -D -A opts s: t: n:
src="$1"
dst="$2"
[[ -n $opts[-s] ]] && start=(-ss $opts[-s])
[[ -n $opts[-t] ]] && end=(-t $opts[-t])
[[ -z $src ]] || [[ -z $dst ]] && usage

y4m() {
# output y4m stream to stdout
# denoise if any argument present
ffmpeg -loglevel warning $start -i $src \
$end -vf format=yuv420p${1+,hqdn3d=${opts[-n]-4}} -f yuv4mpegpipe -
}

~/src/aom/build/examples/noise_model \
$(
ffprobe -loglevel warning -show_streams \
-select_streams v:0 -of json $src |
jq -r '.streams[0] |
"--fps=\(.r_frame_rate)
--width=\(.width)
--height=\(.height)"'
) \
--input=<(y4m) \
--input-denoised=<(y4m -) \
--output-grain-table=$dst
Пост отредактировал Anonymous
Anonymous No.104050
>>104049
Настанет время, декодер будет сам картинки рисовать, на основе информации о том, что вот тут должны быть деревья, а вот тут облака.
Anonymous No.104051
15823292715720.jpg (222 KB, 1402x934)
>>104050
Уже были попытки: https://people.xiph.org/~jm/daala/paint_demo/. Но до состояния юзабельности они доведены не были и в AV1 их не взяли.
Anonymous No.104060
>>104051
Нужно чтобы во время кодирования нейросеть сама вырабатывала ортогональные "блоки обобщения", по которым потом восстанавливалось видео. Если попытаться делать блоки вручную (вроде одинаковых линий с градиентов в этой статье) - ничего не выйдет.
Anonymous No.104102
>>104050
А затем будем передавать нейромыслеобразы напрямую друг другу в мозги?
Наука дала им ПЗС-матрицы и lossless-кодеки, а они...

[Назад] [Обновить тред] [Вверх] [Каталог] [ Автообновление ]
138 / 36 / 39

[Ответить в тред] Ответить в тред

15000

Ответ в тред No.94184
Настройки
Избранное
Топ тредов