The OpenNET Project / Index page

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



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

Исходное сообщение
"Google отправила в IETF проект RFC для кодека VP8"
Отправлено User294, 23-Янв-11 10:00 
> подтянут я думаю, будет проигрывать h264 не более чем в 2-3 раза.

Это прикол такой? :) VP8 *УЖЕ* на нежатом материале на уровне baseline H.264 выступает. По крайней мере по тестам вполне приличной видеолабы на compression.ru

> На счет дизайна.. Ну например там есть одна особенность (точнее она присутствует
> во всех кодеках On2, т.е. VP1...VP8): у них не используются B-frame'ы.

А сможете обосновать почему это плохо? B-frames имхо довольно неоднозначная фича стандарта мпег. Да, они позволяют скостить битрейт. Но они прилично засирают картинку. У меня как-то не сложилось ощущения что B-кадрами можно скостить битрейт и не потерять в качестве.  

> На всякий случай поясню что это такое:
> В видеопотоке бывают три вида кадров:

[основы MPEG заскипаны]

> B-frame в несколько раз меньше чем P-frame,

...только вот они и картинку засирают сильно. Халявы нахаляву не бывает. Это мну так, для души экспериментировал с потоками с различным составом I, P и B кадров (да, я настолько маньяк что лезу крутить и такие параметры энкодеров). Можно даже нарваться на эффект когда на I-кадрах картинка скачком становится идеальной а потом засирается до какой-то гадости. И так до следующего I кадра. С B-кадрами такое вылезает во весь рост, а когда начинаешь присматриваться к видеопотокам и замечать циклические прыжки качества картинки - сие начинает порядком бесить. Периодически с глаз слетает пелена. А потом постепенно опять появляется. И так постоянно.

> Т.о. для достижения того же качества картинки при том же битрейте VP8
> придется использовать более сложные алгоритмы для формирования P-кадров (B-кадров то нет).

У b-кадров своих проблем хватает. Во первых, идея двустороннего референса кадров врядли проще идеи одностороннего референса. Как вы оценивали сложность? Во вторых, оно имеет свойство сильно портить картинку (по сравнению с P-кадрами). Большой вопрос что лучше воспринимается при равном битрейте: поток с B-кадрами или без. Это надо мерять во всех позах. Вы это делали? Я пробовал, и как-то не получил представления о том что B-кадры обеспечивают однозначный EPIC WIN. Меня интересовало максимальное качество при минимальном битрейте, ессно, и когда я так развлекался - я был страшно далек от кодековых войн, поэтому никакой предвзятости, имхо :))

> спокойно снизить fps без перекодирования потока, просто посредством выбрасывания B-кадров.

Да, вот это - плюс, не отнять. Правда на практике реализуется оно весьма так себе. В смысле, реальные плееры не слишком хорошо ведут себя в такой ситуации.

> Ведь они на другие кадры не влияют т.о. мы ещё и трафик сэкономим.

Размечтались то. В реальном мире большая часть видео смотрится по ... обычному такому HTTP. Вы можете на ушах стоять, но кадры оттуда вы не выбросите :). А всякие там хитровыгнутые протоколы реалтайм передачи видео, которые позволят осмысленно выбросить B-кадры - это круто. До тех пор пока вся эта круть не застрянет на первом встречном NAT, firewall или proxy. Коих нынче много. Добро пожаловать в реальный мир, хренли.

> Либо, если такового мезанизма оповещения нет, сам терминал может
> игнорировать B-кадры, не пытаясь их декодировать (для детекта B-кадра достаточно
> просмотреть  заголовок пакета -- это очень быстро).

Да, тут вы правы.

> гарантированную порчу картинки до тех пор, пока не придет ключевой кадр
> (I-frame) а он может приходить довольно редко -- раз в три
> секунды например, а то и реже.

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

> Собственно в самом первом H263 (1995 год) тоже не было B-кадров. Но
> потом таки появились. В H264 они есть от рождения (потому как
> развитие H263'тьего).

Кстати если уж про эффективность кодирования рассуждать, у VP8 есть такая штука как golden frames. Аналогов которых у H.264 нет. Собственно примерно то же что и I-кадры, только не показываются юзеру, поэтому тужа можно пхать что угодно а потом референситься на это. ИМХО, энкодер может грамотно поюзать фичу, набрав "словарь", не ограниченный тем что было на I-кадре, а потом грамотно туда референситься.

 

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



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

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