The OpenNET Project / Index page

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



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

Оглавление

Результаты тестирования AV1 в Facebook. Новый формат JPEG XS, opennews (??), 11-Апр-18, (0) [смотреть все]

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


47. "Результаты тестирования AV1 в Facebook. Новый формат JPEG XS"  +1 +/
Сообщение от пох (?), 12-Апр-18, 08:38 
> тaщемтa у них на сервах должен храниться оригинал вместе с пожатым видео.

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

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

(*) - вообще-то нынче весь матеръял либо mp4, либо еще чем lossy compressed
так что в любом случае это пересжатие.

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

59. "Результаты тестирования AV1 в Facebook. Новый формат JPEG XS"  +1 +/
Сообщение от JL2001 (ok), 12-Апр-18, 09:42 
>> тaщемтa у них на сервах должен храниться оригинал вместе с пожатым видео.
> хранят, наверняка, пожатое. Но при их скорости поступления _новых_ котиков и хомпорно,
> у них нет никаких проблем с источников свежего еще не (сильно
> *)жатого материала для тестирования.
> (*) - вообще-то нынче весь матеръял либо mp4, либо еще чем lossy
> compressed
> так что в любом случае это пересжатие.

вот именно - им уже грузят жатое и чаще всего семейства x264 что пережимать кодеком другого семейства требует допбитрейта для закодивания в видео багов видеоряда семейства x264

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

103. "Результаты тестирования AV1 в Facebook. Новый формат JPEG XS"  +/
Сообщение от пох (?), 13-Апр-18, 00:32 
> в видео багов видеоряда семейства x264

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

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

116. "Результаты тестирования AV1 в Facebook. Новый формат JPEG XS"  +/
Сообщение от Аноним (-), 13-Апр-18, 14:17 
> они у всех современных кодеков более-менее одинаковы, поскольку математика для одиночного
> кадра и нарезания его на квадратики, увы, у всех одна и та же, практически.

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

> Различается только технология/глубина поиска motion vectors,

Не только. В сабже сделали предсказание данных chromа из luma, например. Это позволило передавать меньше битов u/v каналов при прочих равных. При том это работает и для keyframes, где про motion vectors речь не идет. В h.264 так нельзя и, соответственно, key frames да и остальные - больше битов. В 265 что-то наподобие тоже делали. В сабже постарались сделать лучшее что смогут придумать. А думали в том числе и гранды типа Монти.

Сабж усилил концепцию golden frames. Можно референсить аж до 15 буферизованых декодером кадров, чтоли. Куда круче B-frames с 2 референсами вперед и назад. Выбирая из 15 кадров можно подобрать "базу" удачнее для блока. Танцовка от удачного исходника позволяет тратить меньше битов на описание "дельты". Но да, искать придется дольше.

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

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

> времени и вдохновения читать первоисточник как-то не ощущается.

Поэтому в лучших традициях опеннета ты в топике не разбираешься, но мнение имеешь :(. А Монти между тем описал некоторые трюки. И удачи тебе из x264 в принципе выжать сравнимую картинку на таком же битрейте. С хоть там каким временем поиска. Нет, это очень крутая реализация кодека, но она не может сделать магии и превзойти возможности битстрима и правила его декодирования.

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

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру