The OpenNET Project / Index page

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



"Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..." +2 +/
Сообщение от Аноним (-), 03-Сен-15, 20:22 
> Кстати, всегда хотел узнать, чем отличаются P и B кадры в H.264.
> Вроде как B там может иметь от одной до 16 ссылок.

Насколько я помню, главным отличием P и B в мпегах всегда было то что P-кадр ссылается только в 1 сторону, т.е. на предшествовашие ему кадры. А B-кадр может ссылаться в 2 стороны, т.е. еще и на кадры впереди. Что позволяет скостить размер данных, но усложняет декодирование и увеличивает латенси (кодеку приходится декодировать будущие кадры "заранее"). И есть еще один специфичный эффект, который я заметил - о нем ниже.

Есть правда бонус: если декодеру не хватает времени, B-кадр можно и не декодировать совсем, вместо этого сразу и оперируя будущими кадрами. Декодер получает фору по времени а зритель видит лишь небольшое снижение плавности картинки, но ничего не рассыпается. В ряде I&P only так делать сложнее и как я понимаю там отыгрывают в основном забиванием на постпроцессинг. Совсем вырубить I или P кадр как я понимаю нельзя без риска сильного развала последовательности (на выпавший кусок будут ссылаться другие кадры и получится полный трэш).

> Зачем там тогда вообще P слайсы?

По моему опыту, B-frames в мпегах - палка о двух концах. Они обычно компактнее P-frames. Но имеют свойство убивать качество картинки неочевидным образом. Когда понемногу накапливаются ошибки относительно I-frame, даже на статичной сцене. Особенно если междy I-frames большой интервал (а т.к. I-frames огромные, их ставят только при крайней нужде, если I-frames совсем не ставить - поток будет нельзя перематывать и он не будет рекавериться из ошибок). При использовании большого количества B-frames - может случиться дурная осцилляция качества картинки, видимая невооруженным глазом. Когда вы на глаз видите каждый I-frame. Если знать что искать - половина мувиков потом очень бесит.

Очень заметно на статичных и почти статичных сценах, где картинка меняется медленно или не меняется вообще. На слайсах осциллировать будет не вся площадь картинки, что по идее делает мерзость менее заметной. Но все-таки. Формальные метрики, как я понимаю, не видят особых проблем в этом поведении. А вот на глаз артефакт с резким сбросом набравшихся отличий от оригинала - выглядит "не очень". И когда я экспериментировал - последоваельности с большим числом B-frames очень быстро превращались в какую-то труху. Которая вроде и похожа на оригинал, но загажена накопившимися ошибками и мерзенько осциллирует на I-фреймах. Могу предположить что в H.264 этот эффект никуда не делся и никто не хочет на него налетать лишний раз. Вот и не рвутся b-frames везде пихать. Я себя вообще не отношу к фанатам этой техники - ни разу не видел чтобы P-only последовательности страдали таким артефактом. Там деградирует качество и прочая, но как-то более равномерно и потому не так заметно на движущейся картинке. Да, это к вопросу о метриках и учете заскоков в динамике. Вот этот артефакт назойлив именно при просмотре мувика. В стопкадре никаких подвохов не видно.

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

Оглавление
Google, Cisco, Mozilla и Microsoft объединили усилия в созда..., opennews, 01-Сен-15, 20:28  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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