|
|
3.4, Аноним (4), 13:44, 11/03/2020 [^] [^^] [^^^] [ответить]
| –5 +/– |
А ты видел на десктопах хоть один _процессор_ с хардварными (де)кодерами видео?
| |
|
4.7, A.Stahl (ok), 13:52, 11/03/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
В AMDшных APUшках, кажется, что-то есть. Но я от темы далёк. Так, что-то слышал краем уха. VCE / VCN называется или как-то так.
| |
|
5.36, Аноним (36), 04:52, 12/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
UVD скорее, который блок HW decoder в AMD GPU. А VCE/VCN - _энкодеры_.
| |
|
4.35, Аноним (36), 04:52, 12/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А ты видел на десктопах хоть один _процессор_ с хардварными (де)кодерами видео?
Чего-то с более-менее новыми интеловскими интеграшками вроде так умеет, во всяком случае VP9 в VA-API они накодили.
| |
|
|
2.6, Аноним (6), 13:50, 11/03/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
Да они практически все с аппаратной поддержкой: 3dnow, разные SSE, AVX, AVX512, NEON, Altivec.
| |
|
3.9, Аноним (9), 14:02, 11/03/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
3dnow уже давно нет в природе. Да и не применялся он толком на практике.
| |
|
2.22, Ivan_83 (ok), 19:24, 11/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Для AV1 - только какие то ARM пока что.
H.265, H.264, VP9 в тех же райзенах есть. Кажется в интелах тоже, ноутбучных, где граффика есть.
В 1030 vp9 вроде нет, только 264 и 265.
| |
|
1.3, anonismus (?), 13:41, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> В тестах Facebook AV1 обогнал по уровню сжатия main profile H.264 (x264) на 50.3%, high profile H.264 на 46.2%, а VP9 (libvpx-vp9) на 34.0%.
А по продолжительности энкодинга он сейчас как, все еще в 100 раз дольше?
| |
|
|
|
4.37, Аноним (36), 04:54, 12/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Все просто: чем быстрее кодирование, тем хуже сжатие. В git версии официального av1 тоже вон realtime кодирование запилили, но оно разумеется и рядом не стояло по битрейт-качество с медленными скоростями. Зато, блин, быстро (заточено на трансляцию в HW IP и софт-кодирование при видеоконференсинге).
| |
|
3.31, Аноним (31), 03:53, 12/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Для скорости в ущерб эффективности сжатия. Только почему-то об этом все умалчивают, и правки новостей с указанием этой мелочи не принимают.
| |
|
|
1.12, Dnina (ok), 15:47, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Уже не вспомню кодеки, но в хроме и лисе в линукс минт открывал один и тот же стрим, смотрел информацию для сисадминов, кажется av1 и vp9, точно не помню названия, и в каком браузере какой. Так вот, в мозилле сильно квадратился и размывался стрим. В чём может быть проблема?
| |
|
2.13, iPony129412 (?), 16:07, 11/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Проблема в Firefox.
Возможно каких опций экспериментальных понапихал. На чистом профиле бы проверил.
| |
|
3.15, Dnina (ok), 17:11, 11/03/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
В том то и дело, что я фф почти не пользуюсь, так что он относительно чистый. А в хроме напихано всякого, например h264ify, без которого ютуб сильно грузил проц.
| |
|
4.39, Аноним (36), 04:57, 12/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
> без которого ютуб сильно грузил проц.
Это чего за проц такой? А то даже древний армовский планшет VP9 спокойно в софте жрет.
| |
|
5.62, Dnina (ok), 22:15, 12/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
i5 7500, видяха gtx1060, linux mint 19.1. То ли по очереди одно ядро в 100 долбилось, то ли что-то похожее.
| |
|
6.65, Аноним (65), 18:03, 04/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ну так установлена мусорная система не поддерживающее аппаратное ускорение из коробки. А h264ify ставит древний кодек который требует меньше ресурсов для программного декодирования
| |
|
|
4.64, Аноним (64), 08:52, 13/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Та же фигня - чистый хром жрет проц на 100% при просмотре ютуба.
| |
|
|
|
1.14, Аноним (14), 16:11, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
>и обеспечение качественной работы в многопоточном режиме
многопоточное декодирование, карл.
| |
1.23, Аноним84701 (ok), 20:44, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
> Код проекта написан на языке Си (C99) с ассемблерными вставками (NASM/GAS)
Судя по
> Assembly 59.1% C 39.9% Other 1.0%
таки наоборот – на Assembly (NASM/GAS) с сишными вставками (С99)
| |
|
2.25, burjui (ok), 21:45, 11/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Я думал, это только в новостях про rav1e пишут такие нелепые комментарии. Вы на полном серьёзе измеряете вклад языка в структуру проекта количеством строк? Из проекта можно выкинуть ассемблер, заменив его на С, и он будет работать. А если из него выкинуть С, на ассемблере его никогда не допишут.
| |
|
3.27, Аноним84701 (ok), 22:03, 11/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Я думал, это только в новостях про rav1e пишут такие нелепые комментарии.
> Вы на полном серьёзе измеряете вклад языка в структуру проекта количеством строк?
Привыкайте, на опеннете это делается именно так.
Интересно, что обсуждение rav1e вы вспомнили, но в точно такой же подветке и теме (только там C заменен на Rust) не комментировали. В отличие от:
https://www.opennet.me/openforum/vsluhforumID3/119745.html#45
Тем более, фомрулировка "написано на" - вполне подразумевает основной ЯП проекта. Да и при чтении "c xxx вставками" ожидается немного другое соотношение: 90:10 или хотя бы 70:30 но никак не 40:60.
И так как на асме написано 60% всего кода (по метрике гитхаба) - по моему вполне логично назвать этот язык основным языком проекта.
> Из проекта можно выкинуть ассемблер, заменив его на С, и он будет работать. А если из него выкинуть С, на ассемблере его никогда не допишут.
Из проекта можно выкинуть С, заменив его на ассемблер, и он будет работать. А если из него выкинуть ассемблер, на С его никогда не допишут.
Странно, ничем не хуже вашего "аргумента" получилось, только почему-то с "доказательством" обратного *чешет репу*
| |
|
4.33, Аноним (31), 03:59, 12/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
На C уже написан весь функционал декодера, ассемблерные вставки можно выкинуть ничего не дописывая, от этого будет потеряна только скорость работы.
Аналогично и с rav1e: ассемблерные вставки частично дублируют реализованый на rust'е функционал. А строк в них больше из-за низкого уровня языка и нескольких реализаций одних и тех же фич для разных процессоров.
| |
4.44, edo (ok), 06:53, 12/03/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
> так как на асме написано 60% всего кода (по метрике гитхаба)
Вы исходите из того, что 60% строчек кода написано на одном языке, а 40% на другом. На самом деле, ситуация не совсем такая.
Очень условно, 40% строк написано на C, 15% на ассемблере amd64 с поддержкой avx512, 15% на ассемблере arm9, 15% на ассемблере x86 с SSE3, и т.п.
Но даже это не важно, код на Си всё равно тут основной, даже если бы по числу строк он не был бы на первом месте.
> Из проекта можно выкинуть С, заменив его на ассемблер, и он будет работать. А если из него выкинуть ассемблер, на С его никогда не допишут
Сразу видно, что вы никогда не писали кроссплатформенную программу на C с оптимизирующими ассемблерными вставками. Сначала реализуется *весь* функционал на C, отлаживается и тестируется код.
Потом для критичных мест добавляют альтернативные ассемблерные реализации. Отдельно для каждой платформы, например, может оказаться, что для платформы A на ассемблере переписано 17 узких мест, для платформы B 15, для платформы C всего 3, а для остальных платформ ассемблерного кода не написали вовсе, так и используется только Си.
| |
|
3.54, Ordu (ok), 13:09, 12/03/2020 [^] [^^] [^^^] [ответить] | +/– | Радует, что некоторые понимают нелепость этого Но, я отмечу, тебе тоже есть куд... большой текст свёрнут, показать | |
|
|
1.24, livello (?), 21:00, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
AVIF\HEIC. Когда завезут поддержку в дистрибутивы? Без хардварных кодеков енкодер AV1 интересен только на тридриппере или 3950x. А вот с изображениями польза огромная!
| |
|
2.41, Аноним (36), 04:59, 12/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Без хардварных кодеков енкодер AV1 интересен только на тридриппере
Упрлс? Даже на лаптопе 720p декодируется!
| |
|
3.42, Аноним (42), 05:55, 12/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Сейчас бы смотреть 720р на 1440р экране с 70-80% нагрузки на ЦП.
| |
|
|
1.28, Виталий (??), 00:09, 12/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Так и не понял оценочный прирост производительности относительно прошлого релиза.
| |
|
2.30, Аноним (32), 03:52, 12/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Качество равно высокий битрейт. Просто хорошее качество равно очень высокий битрейт, а высокий битрейт сам по себе не гарантирует качество никак. При равном битрейте программный x265 даёт картинку раза в 3 лучше программного x264, даже с выкрученными на качество твикалками. У меня есть стойкое подозрение, что повсеместно используются аппаратные энкодеры, и вот они в случае с avc гонят совершенно мусорную картинку. Аппаратные энкодеры hevc на много порядков более совершенны, и говорят, что av1 может быть ещё лучше (мол, операции не реализуемые эффективно в железе там не нужны будут).
| |
|
3.48, Аноним (29), 09:26, 12/03/2020 [^] [^^] [^^^] [ответить] | +/– | Обычно такие подзрения можно развеять вот этой программой Очень хороший проект,... большой текст свёрнут, показать | |
|
4.50, Аноним (32), 11:01, 12/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
>увидел в медиаинфо параметры энкодера
Не, там другая история была, картинка просто резко похерела и это заметили многие. В том числе на видео которые ты только вчера смотрел нормально. Ну они решили взять пример с гугла и затыквить все файлы.
| |
|
5.57, Аноним (29), 14:34, 12/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ну так вы еще американский Funimation не видели. Вот где жесть. Они там какие попало субтитры хардсабят и у них натурально видео на блоки разваливается. Эти криворучки еще и на видео меняют частоту кадров как попало, чтобы всё плыло...
| |
|
|
|
|
3.46, Аноним (29), 09:05, 12/03/2020 [^] [^^] [^^^] [ответить] | +/– | Это анимешники же у них в этой связи немножко свой мир И это правильно, хотя... большой текст свёрнут, показать | |
|
4.47, Аноним (29), 09:06, 12/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
> HEVC ни разу не на равне в HEVC
HEVC ни разу не на равне c AVC
бытрофикс
| |
4.51, Аноним (31), 11:37, 12/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Это анимешники же... у них в этой связи немножко свой мир.
Однако результатом их деятельности, энкодером x264, сейчас пользуются все.
> AV1 с 39 штук на всём трекере - это считай что не используют.
Это означает, что его начали использовать — ровно то, что было написано.
> результаты не очень.
Где это они "не очень"? Я вижу там 1080p рипы с битрейтом видеодорожки порядка 600кбит/с и без видимых артефактов, с идеально гладкими линиями. Всем предыдущим кодекам до такого как до луны.
> Я жду изменений в скорости времени кодирования.
Ну жди, лет через пять, возможно, что-нибудь и получится. Но для некоторых кодек юзабелен и сегодня: для кодирования выходящих раз в неделю серий текущей скорости libaom-av1 достаточно даже при максимальном качестве.
| |
|
5.52, Аноним (32), 11:48, 12/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Есть аниме на котором без адовых замыливания и бандинга не получится. По-моему фурикури (оригинальный) из таких, хотя там sd. 1000kbps это битрейт для 480p, как ни крути.
| |
|
6.53, Аноним (31), 13:05, 12/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Может получиться, если применить появившийся в AV1 шумогенератор. Правда, энкодеры пока не научились делать это автоматически.
| |
|
5.59, Аноним (29), 14:44, 12/03/2020 [^] [^^] [^^^] [ответить] | +/– | Это всё сильно зависит от источника и от енкодера От формата в меньшей степени ... большой текст свёрнут, показать | |
|
6.61, Говнокодер (?), 17:35, 12/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Обилие мелких деталей, снег, пыль, то что должно быть в видео, но похоже на зернистый шум всё это приводит нынешние енкодеры AV1 в ужас
Эммммм, "в ужас" обилие мелких деталей приводит все энкодеры, без исключения - у них работа такая. av1 этим ничем от остальных не отличается, никак (если что - я вот прямо сейчас av1 гоняю).
| |
|
7.63, Аноним (31), 01:44, 13/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
> av1 этим ничем от остальных не отличается, никак (если что - я вот прямо сейчас av1 гоняю).
Отличается. Попробуйте отделить шум каким-нибудь сильным шумодавом и кодировать отдельно с помощью утилиты noise_model из каталога examples в libaom.
| |
|
|
|
|
|
|
|