The OpenNET Project / Index page

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



Индекс форумов
Составление сообщения

Исходное сообщение
"Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."
Отправлено Аноним, 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 последовательности страдали таким артефактом. Там деградирует качество и прочая, но как-то более равномерно и потому не так заметно на движущейся картинке. Да, это к вопросу о метриках и учете заскоков в динамике. Вот этот артефакт назойлив именно при просмотре мувика. В стопкадре никаких подвохов не видно.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



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

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