Попытки обвинить (http://arstechnica.com/web/news/2011/01/googles-dropping-h26.../) Google в отсутствии инициативы по продвижению формата WebM и кодека VP8 в качестве официального стандарта оказались безосновательными. Стало известно (http://www.h-online.com/open/news/item/Google-submits-docume...), что незадолго до анонса решения по удалению поддержки кодека H.264 из браузера Chrome, компания Google отправила в комиссию IETF (http://www.ietf.org/) (Internet Engineering Task Force) предварительный вариант RFC (http://tools.ietf.org/html/draft-bankoski-vp8-bitstream-00), описывающего форматы данных и принципы декодирования, свойственные VP8.URL: http://www.h-online.com/open/news/item/Google-submits-docume...
Новость: http://www.opennet.me/opennews/art.shtml?num=29348
H.264 конец!
> H.264 конец!Так и надо всяким MPEG LA. Хаха, довыпендривались с своими изменениями правил игры и рубкой бабла за воздух, так что сейчас им придется несладко :)
На пороге сидит MPEG LA, а перед нею разбитое корыто H.264.
Классику они не читали, торгаши невежественные. =)
а что, много нынче bd рипов, прожатых VP8? ладно, это новье, а VP7? 6? а вот H264 чуть ли не каждый 2-й
А причём здесь это? Рипы они по определению незаконны. А здесь идёт речь о законном использовании видео в интернет, тег video вместо гоуноFlesh.
Че правда что ли? Может еще скажете, что на 9 из 10 ПК установлен MS Windows, и каждый второй браузер IE?
> bd риповЯ тебе больше скажу. h264 - официальный стандарт BD-видео, так что если убрать слово "рипов" - то каждый первый! А MPEG2 - DVD-Video.
> h264 - официальный стандарт BD-видеоНу и пускай. Blu-ray всё равно не нужен (http://fuckbluray.com/).
> Ну и пускай. Blu-ray всё равно не нужен (http://fuckbluray.com/).Ну, может быть некоторым нравится получать трояны в приводах за свои же бабки, смотреть непроматываемую рекламу, наслаждаться ограничениями DRM, использовать только расово верные операционки и плееры, выбранными за них другими, ну и все такое, в общем, в духе свободы, равенства и братства, ага :))
> h264 - официальный стандарт BD-видео, так что если убрать слово "рипов" - то каждый первый! А MPEG2 - DVD-Video.Ну и какой резон покупать привод способный записывать на каждую болванку какие-то жалкие 25 Гб если за меньшие деньги можно купить внешний ЖД на 1.5Тб? Официальные стандарты CD-дисков идут лесом, вместе с BD!
> Ну и какой резон покупать привод способный записывать на каждую болванку какие-то
> жалкие 25 Гб если за меньшие деньги можно купить внешний ЖД
> на 1.5Тб? Официальные стандарты CD-дисков идут лесом, вместе с BD!Может быть некоторым нравится диджействовать тормозными ненадежными блинчиками имени копирасов, с троянами в приводах и массой геморроя, вплоть до невозможности без дикого траха сделать резервную копию или перегнать в другой формат для просмотра на другом девайсе/системе/плеере/...
> а что, много нынче bd рипов, прожатых VP8?А вы с вашим варезом орите погромче. И тогда вас поимеет если и не MPEG LA, так копирасы, после чего вы будете рассказывать про форматы совсем не стандартизаторам, имхо.
Таки скажите, каждый кто рипнул, заплатил денежку тому кому надо? Скорее всего он еще и за софт которым рипает не платил, не говоря о том, что рипать не законно. так что это все чес... и стандарт дефакто всегда можно поменять, были бы ресурсы...
> а что, много нынче bd рипов, прожатых VP8? ладно, это новье, а VP7? 6? а вот H264 чуть ли не каждый 2-йа каждый второй (другой) -- это Avi/Xvid
...это не смотря на то что на OpenNet-и-LOR мы уже выяслили что VP8 сжимает по крайней мере луше чем Xvid :-)
(другими словами -- думаю -- рипперы так и будут жать релизы теми форматами которые используются в ихнем сообществе рипперов. возможно они просто прагматично обосновывают своё поведение DVD-Плаерами-Для-Телевизоров. а возможно просто делают так как всегда привыкли)
Технически их кодек превосходит WebM все еще. "Борцам за свободу" конечно на техническую составляющую наплевать.
> "Борцам за свободу" конечно на техническую составляющую наплевать.Неправда. Если человек рассматривает не только техническую составляющую, но и этическую, то это не означает, что на техническую ему наплевать. А вот технофилам, вроде вас, на свободу действительно наплевать.
> технофилам, вроде вас, на свободу действительно наплевать.Уж не знаю какой он там технофил, скорее просто оторванный от жизни раздолбай. Технофилам должно быть понятно что роялит совокупное сочетание параметров. И геморрой с лицензиями а хотя-бы и в некоторых странах - потенциальная проблема. Видео ж по хорошему делается для ВСЕХ, а не только местечковых.
>> "Борцам за свободу" конечно на техническую составляющую наплевать.
> Неправда. Если человек рассматривает не только техническую составляющую, но и этическую,
> то это не означает, что на техническую ему наплевать. А вот
> технофилам, вроде вас, на свободу действительно наплевать.Школьник, расскажи-ка, куда ты эту свободу применишь? И насколько тебе не наплевать на ограничение свободы ширяться героином?
> расскажи-ка, куда ты эту свободу применишь?Какую именно?
> насколько тебе не наплевать на ограничение свободы ширяться героином?
Причём тут героин? Свободу ширяться героином пусть отстаивают наркоманы, а мне, как пользователю программ, куда более важны права пользователей программ.
>> расскажи-ка, куда ты эту свободу применишь?
> Какую именно?Ту, о которой ты говорил выше по треду, естественно.
>> насколько тебе не наплевать на ограничение свободы ширяться героином?
> Причём тут героин? Свободу ширяться героином пусть отстаивают наркоманы, а мне, как
> пользователю программ, куда более важны права пользователей программ.Еще один логический шаг, и ты поймешь. Может быть.
> Ту, о которой ты говорил выше по треду, естественно.Я говорил о свободе пользователей программ. А уж решать, как ею пользоваться, должны сами пользователи. Одно я знаю точно -- нет никаких объективных причин её отнимать.
> Еще один логический шаг, и ты поймешь. Может быть.
Да я изначально понял на что вы намекаете :)
>> Ту, о которой ты говорил выше по треду, естественно.
> Я говорил о свободе пользователей программ. А уж решать, как ею пользоваться,
> должны сами пользователи. Одно я знаю точно -- нет никаких объективных
> причин её отнимать.Ну че так абстрактно-то, некие пользователи, в неизвестном количестве и с неизвестными свойствами?...
Конкретную свободу-то назови. Которую будешь использовать лично ты.
В данном случае, я буду использовать свободу "не платить отчисления MPEG LA" :)
> В данном случае, я буду использовать свободу "не платить отчисления MPEG LA"
> :)А разве ты её, как конечный пользователь, платишь? Тот же Adobe Flash скачивается совершенно бесплатно - это уже проблема Adobe, отчисления платить.
> А разве ты её, как конечный пользователь, платишь?Пока нет, но это только потому что MPEG LA так хочет. Есть ли гарантии, что завтра она не захочет по другому? :)
> Тот же Adobe Flash скачивается совершенно бесплатно - это уже проблема Adobe, отчисления платить.
Ещё бы ничего если это была бы проблема только Adobe. А как же другие разработчики, разве о них думать не надо?
>> А разве ты её, как конечный пользователь, платишь?
> Пока нет, но это только потому что MPEG LA так хочет. Есть
> ли гарантии, что завтра она не захочет по другому? :)Есть ли гарантии, что завтра бабушка не окажется дедушкой?
>> Тот же Adobe Flash скачивается совершенно бесплатно - это уже проблема Adobe, отчисления платить.
> Ещё бы ничего если это была бы проблема только Adobe. А как
> же другие разработчики, разве о них думать не надо?Конечному пользователю-то? Зачем?..
> Конечному пользователю-то? Зачем?..Из-за уважения к ним, солидарности. Почему мне должно быть приятно, если с разработчика программы, которой я пользуюсь будут брать деньги за воздух?
В случае если программа платная, такие поборы могут увеличить стоимость программы, что никому не выгодно, кроме копирастов.
>> Конечному пользователю-то? Зачем?..
> Из-за уважения к ним, солидарности. Почему мне должно быть приятно, если с
> разработчика программы, которой я пользуюсь будут брать деньги за воздух?Это уже личные тараканы в голове - к обсуждаемой свободе конечного пользователя отношения нет.
> В случае если программа платная, такие поборы могут увеличить стоимость программы, что
> никому не выгодно, кроме копирастов.В таком случае могло бы да. Но рассматривался-то не такой случай.
>Конкретную свободу-то назови. Которую будешь использовать лично ты.Можно будет не думать, а нужно ли заплатить за использование h264 вот в этом случае или нет? Можно будет не думая об этом просто воспользоваться утверждённым стандартом, за использование которого гарантировано никто тебя преследовать не будет.
Захотел смонтировать семейный фильм? Каким кодеком воспользоваться? Читать лицензионные требования h264 и думать? Или просто взять VP8 и использовать его не думая ни о чём и ничем не рискуя?
>>Конкретную свободу-то назови. Которую будешь использовать лично ты.
> Можно будет не думать, а нужно ли заплатить за использование h264 вот
> в этом случае или нет? Можно будет не думая об этом
> просто воспользоваться утверждённым стандартом, за использование которого гарантировано
> никто тебя преследовать не будет.
> Захотел смонтировать семейный фильм? Каким кодеком воспользоваться? Читать лицензионные
> требования h264 и думать? Или просто взять VP8 и использовать его
> не думая ни о чём и ничем не рискуя?"Свобода не думать" ? Цирк какой-то. Свобода - она относится к чему-то материальному, действиям. А не мыслям, которые и невозможно ограничить.
> Технически их кодек превосходит WebM все еще. "Борцам за свободу" конечно на
> техническую составляющую наплевать.Так и есть. Одинаковое видео с сжатием lossless у h264 и WebM у h264 занимает 3 мегабайта, а у WebM - 4,5.
Для loseless достаточно немного других кодеков.
>> Технически их кодек превосходит WebM все еще. "Борцам за свободу" конечно на
>> техническую составляющую наплевать.
> Так и есть. Одинаковое видео с сжатием lossless у h264 и WebM
> у h264 занимает 3 мегабайта, а у WebM - 4,5.это ты тут опять вспомнил случай как какойто "умник" -- перекодировал из НЕ_lossless MPEG-какого-то формата ==в==> WebM-формат -- и в результате получил 4.5 мегобайта
???(видио -- про баги wine)
при этом свой ГЛУПЫЙ эксперимент этот "умник" обосновал тем что то самое изначально-НЕ_lossless видио было в очень хорошем качестве
> "Борцам за свободу" конечно на техническую составляющую наплевать.Техническая составляющая - это ведь и сервак с видео в американском датацентре может быть, например...
>> "Борцам за свободу" конечно на техническую составляющую наплевать.
> Техническая составляющая - это ведь и сервак с видео в американском датацентре
> может быть, например...И тут, кроме технической и этической, появляется еще и юридическая составляющая...
> И тут, кроме технической и этической, появляется еще и юридическая составляющая...Ну вот с гугловским кодеком можно будет не заморачиваться. А с H.264 - там у этих фруктов из MPEG LA условия на каждый пук. Если юзаете так - плати, этак - тоже плати, сяк - тоже плати. Понятно что в России у них руки коротки, но веб есть не только в Росси...
Поменяли качество на свободу. Только и всего.
> Поменяли качество на свободу. Только и всего.В данном случае, качество со временем допилится, а несвободное станет свободным когда уже совсем никому не нужным станет.
> Поменяли качество на свободу. Только и всего.А свобода - типа не качество?
>А свобода - типа не качество?Свобода не относится к техническим деталям программного продукта.
> Свобода не относится к техническим деталям программного продукта.Она относится к юридическим деталям. И, кстати, юридические детали на раз могут похоронить любые технические. В частности, толку то с крутого формата, если им нельзя пользоваться нормально на почти половине планеты. Вы как, предлагаете стартапам позабивать на крупнейшие перспективнейшие рынки?
>> H.264 конец!
>Так и надо всяким MPEG LA. Хаха, довыпендривались с своими изменениями правил игры и
>рубкой бабла за воздух, так что сейчас им придется несладко :)Они по ходу повторяют путь MS! Сейчас они уже вот-вот просрут веб и mobile, а там уже и до остального рукой подать (форматы видео - это, все-таки не ОС и не офисный пакет, и инерционность пользователей здесь им не сильно поможет).
> Они по ходу повторяют путь MS! Сейчас они уже вот-вот просрут веб
> и mobile, а там уже и до остального рукой податьНу да, именно :). Гугл и там и там является достаточно приличной силой.
Можественные вставки "Begin code block" радуют чрезвычайно
Все правильно сделали. Так держать, Гугл! :)
Что правильно? Телевизионный ты наш, будешь смотреть телевизор с WebM, об остальном за тебя позаботиться Google. :)) Захочешь видеочатик — а нииизя, WebM непригоден к кодированию со сжатием видеопотока в реальном времени. :))
WebM -> VP8
> Что правильно?Все. Начиная от покупки и заканчивая желанием стандартизировать.
> Телевизионный ты наш, будешь смотреть телевизор с WebM, об остальном
> за тебя позаботиться Google. :))Как-то слишком толсто.
> Захочешь видеочатик
Во первых, мне эти ваши видеочатики никуда не упали. Пусть у тех кому это надо голова и болит.
> — а нииизя,
Вот прямо законы физики запрещают, ага. А ничего что...
1) Небольшой поток на мощном CPU наверное уже сейчас можно протолкать. Хоть и жрать проц будет, что нехорошо.
2) Уже делаются чипы которые позволят и кодировать и декодировать VP8. Гугл явно всерьез настроен всыпать MPEG LA и все такое :)
3) Оптимизацию кодека и написание новых реализаций никто не отменял. Например никогда не слышал про xVP8? А то там гугл в принципе принял на работу минимум одного перца работавшего над ffmpeg. В общем гугл настроен серьезно :)> WebM непригоден к кодированию со сжатием видеопотока в реальном времени. :))
Subject to change, ИМХО.
Почему? Если стандартизуют - появление микроконтроллеров с акселерацией VP8 - вопрос времени.
> появление микроконтроллеров с акселерацией VP8 - вопрос времени.А декодировать H.264 аппаратно можно на любом встроенном гомне вроде GF8200
>> появление микроконтроллеров с акселерацией VP8 - вопрос времени.
> А декодировать H.264 аппаратно можно на любом встроенном гомне вроде GF8200вот только несуществует НИОДНОЙ полностью-FREEOPENSOURCE операционной системы (включая драйвера и видиопроигрыватель) на которой бы это аппаратная поддержка H.264 смоглабы зарабатать на вашей любимой GF8200
# p.s.: дальше я уже представляю что следущие комментаторы будут меня убеждать в том что открытые-исходники не нужны ...что один разок можно установить блоб ....ну и что вообще "один раз не считается..." :-D
Что держать то? Это rfc на декодирование. А на кодирование rfc нет. На сколько я знаю, никак не описано как этот VP8 передавать через rtp.Также у VP8 есть проблема -- он очень медленно кодируется. Следовательно для видеоконференций, видеозвонков, видеочятиков он не пригоден совершенно. В отличае от h264.
Т.о. VP8 пригоден лишь для одного -- просмотра видеороликов.
H264 же пригоден почти для всего (есть специфические области, где и он не пригоден, и где приходится пользоваться mjpeg'ом).
>Т.о. VP8 пригоден лишь для одного -- просмотра видеороликов.Именно это и интересует гугл, а также w3c.
> Именно это и интересует гугл, а также w3c.Это не так.
Во-первых в html5 драфте ещё летом появился тэг device, что позволяет из js получить доступ к видеокамере и микрофону. Т.о. когда-нибудь можно будет сделать видеоконференцию в чистом браузере без плагинов. Если бы w3c эта нише (видеоконференции) не интересовала бы, наврятли это появилось бы в драфте. Также в появлении этого тэга замешан и гугл.
Во-вторых у гугла в своём Google Talk'e используется h264 для видеозвонков. И я не думаю что они там его заменят на vp8.
Т.о. вся это беготня вокруг выпиливания h264 -- всего лишь политические игры, в которых гугл, пользуясь невежеством подавляющего большенства, манипулирует мнением и использует это самое мнение этого самого большенства в качестве одного из козырей в партии.
По сути сейчас идет навязывание (или видимость навязывания) существенно худшего технического решения.
при употреблении сравнительной степени "существенно худшего технического решения" циферьки на тесты приводят
без цыферек - пустой трёп
"Во-вторых у гугла в своём Google Talk'e используется h264 для видеозвонков" и это как-то предваряет его дальнейшее использование? Совершенно не очевидно
Насколько я помню, кодирует он где-то в 4-10 раз медленней. Это без учета того, что h264 можно кодировать в специализированными чипами прямо сейчас (в частности есть вебкамеры которые сами кодируют в h264 кодек).Как в ffmpeg'e допилят vp8 енкодер, я проведу тесты ещё раз (к сожалению у них там какие-то внутренние разборки начались, как это скажется на сроках -- не понятно).
> Насколько я помню, кодирует он где-то в 4-10 раз медленней. Это без
> учета того, что h264 можно кодировать в специализированными чипами прямо сейчасГугл уже подтолкнул создание чипов которые кодируют/декодируют VP8 ;)
да да да.
подскажите где можно купить видеокарту с акселерацией vp8 ?
> да да да.
> подскажите где можно купить видеокарту с акселерацией vp8 ?а где можно купить видиокарту с работающщей акселерацией H.264 ? (при условии -- не ставить проприетарных программ/библиотек в операционную систему)
Встроенный Intel вроде умеет, нет?
> Т.о. вся это беготня вокруг выпиливания h264 -- всего лишь политические игры,
> в которых гугл, пользуясь невежеством подавляющего большенства, манипулирует мнением
> и использует это самое мнение этого самого большенства в качестве одного
> из козырей в партии.Вы раскрыли мне глаза, спасибо! Оказывается, VP8 медленно кодирует и непригоден для видеочатов... Это в корне всё меняет. Теперь очевидно, что необходимо принять условия лицензионных соглашений с MPEG LA.
Ухх! Как представлю, аж морозец по коже... Подумать только: кодек оказался непригоден для видеочатов! Какая уж тут свобода стандартов и реализаций... Спасибо вам.
> По сути сейчас идет навязывание (или видимость навязывания) существенно худшего технического
> решения.Да, действительно, вы правы. Тормозной видеочат - эта кабала пострашнее лицензионной.
>Также у VP8 есть проблема -- он очень медленно кодируется.Скоро пройдет, не переживай. Мощности растут, коды совершенствуются.
Это опять таки не совсем так.В частности ёмкость батареек не особо растёт.
Автономность устройств не повышается.Переход на vp8 отбросит индустрию где-то на 5-6 лет назад. Минимум.
> Это опять таки не совсем так.
> В частности ёмкость батареек не особо растёт.
> Автономность устройств не повышается.
> Переход на vp8 отбросит индустрию где-то на 5-6 лет назад. Минимум.ой не переживайте за индустрию её есть кому и чем отбрасывать, а уж проприетарность - первейший из факторов тормоза технологий
небылоб патентов на "алгоритмы" - и этой истерии не существовало бы
А их и нет. У нас. :-)Я как бы переживаю потому, что занимаюсь непосредственно написанием софта для этих самых видеозвонков, видеоконференций и прочего.
странно
но что бы поддержать индустрию не хотите написать кодек не отбрасывающий её на 5 лет назад ? и бабла бы срубили
Разработка видеокодеков находится вне моей компетенции. Я их использую, изучаю, могу например преобразовать видеопоток в соренсоне в поток h263+ без перекодирования (без сторонних утилит), но кодеки я не разрабатываю, и даже не реализации их не пишу.Если интересны альтернативы, и вообще что перспективного в мире есть, то можете посмотреть на например наработки компании Spirit (http://spirit.ru). Это российская компания, соответственно российские разработка.
У них очень интересный видеокодек. Он использует несколько слоёв кодирования. В результате, в случае видеоконференции, когда у нас на сервере стоит MCU (http://ru.wikipedia.org/wiki/Multipoint_Control_Unit), оный сервер может склеивать множество видеопотоков в один практически без перекодирования. Т.е. изменение разрешения кадра там очень дешевая операция. Соответственно в h263/h264/vp8 тут пришлось бы каждый из потоков декодировать в yuv420p, изменять размер каждого из кадров, затем копировать это всё дело в результирующий кадр (каждый в своё место), затем этот кадр кодировать. Что довольно затратно.
valexey, я вот честно не особо в теме видеокодирования, на твой взгляд, проблемы VP8 в дезайне или в реализации?
Мне кажется, и в том и в другом. Реализацию рано или поздно подтянут я думаю, будет проигрывать h264 не более чем в 2-3 раза. Мне очень интересно как реализовали в avcodec'e (ffmpeg). Как только, так сразу пощупаю.На счет дизайна.. Ну например там есть одна особенность (точнее она присутствует во всех кодеках On2, т.е. VP1...VP8): у них не используются B-frame'ы.
На всякий случай поясню что это такое:
В видеопотоке бывают три вида кадров:
I - это т.н. ключевой кадр. по сути -- обычная jpeg картинка. Соответственно видеопоток mjpeg'a полностью состоит именно из I-кадров. I-кадр не зависит от кого-либо ещё. I-frame является опорным кадром.
P - это кадр для формирования которого используется последний опорный кадр. Грубо говоря, P-frame это diff исходного изображения с изображением предыдущего опорного кадра. P-frame также является опорным кадром.
B - это кадр для формирования которого используются сразу два опорных кадра. Предыдущий и СЛЕДУЮЩИЙ. B-frame не является опорным.Соответственно они идут как-то так: IBBP, или так: IBPBPBP
(это называется GOP -- group of pictures. после этого последовательность повторяется, т.е. IBBPIBBP и т.д. , также следует учесть, что обычно GOP size (число кадров в GOP'е) существенно больше нежели в примере. в примере gop size = 4, на самом деле не редко и gop size = 40).B-frame в несколько раз меньше чем P-frame, которые опять таки в несколько раз меньше чем I-frame (это самое "несколько" -- порядка 10). На кодирование B-frame существенно менее ресурсоёмко нежели P-frame.
Т.о. для достижения того же качества картинки при том же битрейте VP8 придется использовать более сложные алгоритмы для формирования P-кадров (B-кадров то нет).
Тут на самом деле есть ещё один нюанс: если у нас конечный терминал (например мобильник, или нетбук) не справляется с декодированием нашего видеопотока (ведь ему не только декодировать, но ещё и рисовать надо, т.е. такое бывает), то в случае кодека с B-кадрами мы можем (по запросу терминала, т.е. он определит такую ситуацию и нас попросит) совершенно спокойно снизить fps без перекодирования потока, просто посредством выбрасывания B-кадров. Ведь они на другие кадры не влияют т.о. мы ещё и трафик сэкономим. Либо, если такового мезанизма оповещения нет, сам терминал может игнорировать B-кадры, не пытаясь их декодировать (для детекта B-кадра достаточно просмотреть заголовок пакета -- это очень быстро).
С VP8 (равно как и VP6, VP3 и т.п.) такой финт ушами не пройдет. Там все кадры опорные. Выкинув хотя бы один получим гарантированную порчу картинки до тех пор, пока не придет ключевой кадр (I-frame) а он может приходить довольно редко -- раз в три секунды например, а то и реже.
Собственно в самом первом H263 (1995 год) тоже не было B-кадров. Но потом таки появились. В H264 они есть от рождения (потому как развитие H263'тьего).
Мне остается только снять шляпу - ответ настолько развернутый, что и вопросов нет. :) Может, гуглу при таком раскладе надо было купить владельцев x264:) Или они в следующих версиях рассчитывают все улучшить. А MPEG LA действительно ведь уже пошли на уступки.
> нет. :) Может, гуглу при таком раскладе надо было купить владельцев x264:)x264 - всего лишь один конкретный кодек. Они вообще патенты лицензировать не могут. Купить MPEG LA? А оно всего лишь "крыша" над стадом корпораций, среди которых есть всякие там эппла и прочие незначительные фигни. Покупать все эти корпорации можно немного подзадолбаться будет. Ну да, это ж такая фигня - пойти и купить себе пару Эпплов в портфолио :)
> B-frame не является опорнымМаленькое уточнение. Очевидно, в целях упрощения общей картины, вы не упомянули, что промежуточные кадры также могут быть опорными (--b-pyramid)
Да. Именно поэтому.Причем эта возможность, если мне склероз не изменяет, есть даже в H263.
Плюс, на самом деле, есть ещё и другие типы фреймов. В общем там много всего. Я постарался не начать пересказывать спеку кодека :-) Просто изложил самые основы, как оно обычно устроено. Интересующиеся могут почитать спеку на например H263 -- официальная дока есть и на русском (официально).
> подтянут я думаю, будет проигрывать 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-кадре, а потом грамотно туда референситься.
P.S. кстати вспомнил:B-кадры вполне себе были еще в дрееееееевнем MPEG-1 (и MPEG-2). Что как-то не сильно помогало оным в достижении хороших соотношение битрейт-качество. Почему-то они легко проигрывали по соотношению битрейт-качество любому MP4 не использующему B-кадры вообще (а ранние реализации их и не использовали, что не помешало им начать процесс закапывания мпег1/2).
В общем b-кадры - дрееевняя фича. А вы ее как epic win технологий преподносите...
> Мне кажется, и в том и в другом. Реализацию рано или поздно
> подтянут я думаю, будет проигрывать h264 не более чем в 2-3
> раза. Мне очень интересно как реализовали в avcodec'e (ffmpeg). Как только,
> так сразу пощупаю.
> На счет дизайна.. Ну например там есть одна особенность (точнее она присутствует
> во всех кодеках On2, т.е. VP1...VP8): у них не используются B-frame'ы.
> На всякий случай поясню что это такое:
> В видеопотоке бывают три вида кадров:Насколько я ориентируюсь, то именно это и есть СУТЬ патента на h264, и именно поэтому все ограничения и возникают на использование этой технологиии в других кодеках!!!
Копирастов уже заставили отодвинуть по времени введение платы за кодек, и теперь надо додавить этих красавчиков тем, что несмотря на их хитрость никто не собирается платить за устройство УЖЕ известного на 100% АЛГОРИТМА в угоду только их кошелька. Любой патент и запрет на алгоритм - это преступление против ПРОГРЕССА. Не забыли ли уважаемые, что некоторые товарисчи пытались получать деньги с каждой лямпочки?
> А их и нет. У нас. :-)А у вас - это где? Интернет как бы глобальная сеть...
> Я как бы переживаю потому, что занимаюсь непосредственно написанием софта для этих
> самых видеозвонков, видеоконференций и прочего.Ага. И такой весь из себя незначительный рынок США - вы как, игнорируете, или радостно отсандаливаете роялти?
> В частности ёмкость батареек не особо растёт.Емкость батареек растет медленно, факт. А вот MIPS/Watt - весьма даже. Поэтому от одной и той же емкости батарейки можно смолотить все больше инструкций. Какиенить ARM в этом плане очень некисло упираются - 2 ядра более чем 1ГГц при весьма скромном потреблении уже совсем не фантастика.
> Автономность устройств не повышается.
А ничего что процессоры совершенствуются, в частности, соотношение MIPS/Watt у новых процессоров шибко лучше чем у старых. Технологические нормы - улучшаются. Ядра - совершенствуются.
> Переход на vp8 отбросит индустрию где-то на 5-6 лет назад. Минимум.
Да никто никуда никого не отбросит. А всякие там видеочатики... извините, ну вон 3G - есть. А где же массовое использование видеозвонков? Что, оказалось что оно никому особо не надо, и вообще нишевая бнопня? Надо же, вот незадача. А теперь сравниваем с популярностью ютуба. Что, всего 2 млрд роликов в день смотрят? А где же 2 млрд видеозвонков в день? Ну вот и интересы соответствующе распределяются. Т.е. сперва - веб, а потом, может быть, и до видеочатиков руки дойдут. Если будет существенный спрос и все такое. Спрос рождает предложение. Для веба спрос на универсальный, везде работающий без выплат и оговорок кодек - есть. Каждый второй вебмастер - потенциальный источник такого спроса.
> Переход на vp8 отбросит индустрию где-то на 5-6 лет назад. Минимум.Рискну предположить, что это наруку операторам мобильной связи, чтобы заменить GSM/3G на 4G для полноценных видеозвонков и перевода мобильной связи на Интернет-основу, где деньги считаются не за количество минут/мегабайт, а за предоставление услуг по фиксированной ставке.
>Также у VP8 есть проблема -- он очень медленно кодируется. Следовательно для видеоконференций, видеозвонков, видеочятиков он не пригоден совершенно.И нафига для видеозвонков и видеочатикой вообще видеокодеки высокого качества? Для этого сгодятся кодеки с низким качеством с небольшим битрейтом и высокой скоростью кодирования.
Приведите пожалуйста наименование кодеков, которые, как вам кажется, подошли бы для видеозвонков и видеоконференций.
> И нафига для видеозвонков и видеочатикой вообще видеокодеки высокого качества? Для этого
> сгодятся кодеки с низким качеством с небольшим битрейтом и высокой скоростью
> кодирования.Theora
Чудес всё таки не бывает.
Theora это ведь VP3. Она да, кодирует быстро (благо разработка 2000 года, тогда машинки были послабее), но полосу при этом требует достаточно широкую. Грубо говоря, ей нужно где-то в два-три раза больше полосы чем h264. И примерно столько же, сколько h263.Кстати, какие преимущества у VP3 перед H263+ ?
Также очень хотелось бы увидеть какой-нибудь rfc где описывался бы формат дополнительных заголовков rtp для теоры. Без этого видеозвонок, видеоконференцию и т.п. не сделать.
> Кстати, какие преимущества у VP3 перед H263+ ?Отсутствие MPEG LA и просто сообщество тех кто ее развивает? А то на 263 по-моему все забили. Как максимум развивая что-то типа xvid как более легкий кодек.
MPEG LA никак не припятствует использованию H263+. Т.е. никаких роялити и прочих препонов.
Можно сказать что это открытый кодек. Тем более что открытые имплементации имеются. В том же avcodec'e например.H263+ активно используется в телекоме, в частности для видеозвонков, видеоконференций и т.п. Собственно даже если взять просто флэш, то он умеет енкодить ровно одним кодеком -- sorenson, который является вариацией H263+ кодека (можно конвертировать туда-сюда без перекодирования).
У H263 есть 3 или 4, как бы это назвать.. , поколения? Последнее датировано 2005 годом. Имплементаций полно разных. Другое дело, что про H263 не трубят на каждом углу, его просто активно используют.
Да, ресурсожёркость h263 примерно в 4 раза меньше чем у H264 (с fast профилем последнего).
> MPEG LA никак не припятствует использованию H263+. Т.е. никаких роялити и прочих
> препонов.Я рад за MPEG LA и тех кому нужен H.263. А кстати, там это временные поблажки, или это на веки вечные?
> Можно сказать что это открытый кодек. Тем более что открытые имплементации имеются.
> В том же avcodec'e например.Можно. Говорите. Только почему-то он никому толком не нужен оказался. Наверное потому что видеоконференции - очень нишевая штука. Это уже который год пытаются пхнуть в хомячков а хомячки искренне недоумевают: "зачем нам это?" :)
> H263+ активно используется в телекоме, в частности для видеозвонков, видеоконференций и т.п.
Ну и пусть себе используется. Никому кроме телекома и полутора юзеров этих видеоконференций с этого ни жарко, ни холодно. Потому что для более актуальных применений типа видео в вебе H.263 ничего такого из себя не представляет. Обычный такой кодек, уровня типичного MP4 навроде xvid или чуть хуже. И его энкодеры уже толком никто не улучшает.
> енкодить ровно одним кодеком -- sorenson, который является вариацией H263+ кодека
> (можно конвертировать туда-сюда без перекодирования).Ну да, этот соренсон и есть видоизменение H.263. В документах абобы на формат FLV это и не скрывается даже :)
> H263 не трубят на каждом углу, его просто активно используют.
Его активно используют только для видеоконференций, имхо. Потому что на параметрах видео типичных для веба или там CD-sized "дивиксин" или там чего еще - оно вообще ничего интересного из себя не представляет. Оно откровенно затачивалось под конференции. С низким битрейтом и специфичными параметрами картинки. Ну вот им никто и не пользуется особо для "general purpose" видео. Я как-то пробовал несколько энкодеров H.263 для обычного видео - что-то не впечатлило.
> Да, ресурсожёркость h263 примерно в 4 раза меньше чем у H264 (с
> fast профилем последнего).Ну вот пусть любители видеоконференций и ссут кипятком от него, имхо. Нафиг оно остальным надо - мне не понятно. Не заметил никакого EPIC WIN на кодировании обычного видео в свое время. Обычные MP4 типа xvid как-то получше справлялись.
> Что держать то? Это rfc на декодирование. А на кодирование rfc нет.По нормальному должен быть RFC на формат потока. А как вы его там будете создавать и разбирать - это уже ваше дело, вообще.
> На сколько я знаю, никак не описано как этот VP8 передавать через rtp.А почему именно через RTP, кстати?
> Также у VP8 есть проблема -- он очень медленно кодируется. Следовательно для
> видеоконференций, видеозвонков, видеочятиков он не пригоден совершенно. В отличае от h264.Для железок чипов понаделают. Уже первые образцы есть.
> Т.о. VP8 пригоден лишь для одного -- просмотра видеороликов.
Как ни странно его для этого и будут юзать :). С чипами - и для иных нужд тоже.
> не пригоден, и где приходится пользоваться mjpeg'ом).
ну mjpeg'у - mjpeg'овское.
> А почему именно через RTP, кстати?А какие варианты? RTP ходит поверх UDP. И это хорошо, потому что нет ретрансмитов. Т.е. реалтаймовость выдержать можно.
В видеозвонках/видеоконференциях важнее отсутствие задержки (точнее задержка в пределах нормы -- до 250 мс примерно) нежели целостность потока. Т.е. лучше дропнуть кадр чем долго и упорно пытаться его перепослать. Если это был не ключевой кадр (а ключевые посылаются весьма редко), то не будет даже порчи картинки.
> Для железок чипов понаделают. Уже первые образцы есть.
Ну вот когда понаделают... Кроме того, у меня имеются некие подозрения на счет сложности алгоритма, которую не убрать оптимизациями кода или воплощением в железе.
> А какие варианты? RTP ходит поверх UDP. И это хорошо, потому что
> нет ретрансмитов. Т.е. реалтаймовость выдержать можно.В вебе все это неактуально. Там надо чтобы работало ВЕЗДЕ. А RTP имеет ряд проблем с файрволами, натами и прокси. Вот и юзают все видеосервисы простой HTTP, как на подбор. Он нигде не застревает, поэтому все могут смотреть видео а не канифолить мозг саппортам.
Более того - для онлайн видео никакая латентность никому не нужна. Поэтому тупо пребуферят заметный кусок до начала воспроизведения. А если все-таки опа случилась - перезапрашивают поток с нужной позиции, заново наполняя буфер.
> В видеозвонках/видеоконференциях важнее отсутствие задержки
Все так, только WEBM/VP8 как-то не позиционируется в эту нишу, поэтому - "who cares?"
> Т.е. лучше дропнуть кадр чем долго и упорно пытаться его перепослать.
Кэп, это вы? Азы VoIP и видеоконференций - это круто, но ... но гугл вроде и не позиционировал этот кодек как убийцу видеоконференций :).То что в вашей узкой нише "видеозвонки" счастья не наступило, как минимум пока - ну да, все так. И чего? Лично мне например все эти видеозвонки вообще никуда не впились (как максимум меня может заинтересовать реалтаймное кодирование с камер наблюдения, но это тоже отдельная ниша, пересекающаяся с веб лишь частично).
>> Для железок чипов понаделают. Уже первые образцы есть.
> Ну вот когда понаделают... Кроме того, у меня имеются некие подозрения на
> счет сложности алгоритма, которую не убрать оптимизациями кода или воплощением в
> железе.Я так понял что какие-то финики по заказу гугеля УЖЕ родили соответствующие чипы :). Ну в общем когда нельзя, но очень хочется - тогда можно. Вот гугл кажется всерьез решил надрать некоторым задницы. И учтя их массу и то что они еще не стали тормозами типа майкрософтов и айбиэмов - у них есть все шансы это сделать :)
Впервые в рабочей программе вижу работу с 4-мерными массивами. :)
Слушайте, народ вы тут все "бла-бла-бла" на тему, что VP8 медленнее, сжимает чуть-чуть меньше, вы посмотрите на СРОК РАЗРАБОТКИ! H.264 кодеры и декодеры уже сколько времени разрабатываются, а WebM появился относительно недавно и уже почти круче. Если он разрабатывался бы столько-же времени, он будет круче. А учитывая открытость, всевозможные баги и дополнения будут быстрее делаться.
P.S. Специально для тех, кто опять начнет бубнить про то, что открытость не есть хорошо и тыркать кучей неизвестных проектов. WebM это очень известная штука, чтоб её не разрабатывали. Она уже вовсю обкатывается(вспомним про реализацию от ffmpeg), да и потом сама Google будет на все-возможных конференциях делать конкурсы, типа: "Исправь баг, получи 500$!"
> WebM появился относительно недавноVP8 года три-четыре и появился не на пустом месте, а как развитие (в ошибочном направлении) предыдущих поколений
> WebM это очень известная штука
buzzword
Полностью согласен! Первые MPEG'и получили оглушительный успех! Затем было долгое затишье. Десятилетия не были простоем на месте, было придумано много новых аглоритмов, опередивших своё время как когда-то MPEG. Ещё до h264 я часто встречал разговоры на тему "а что это вы не пользуетесь новыми кодеками - они жмут лучше DivX и по-настоящему используют ресурсы современных компьютеров!". Теперь есть BD и это стало массово
> Полностью согласен! Первые MPEG'и получили оглушительный успех! Затем было долгое затишье.Начало девяностых годов вообще имело оглушительный успех у индустрии развлечений (если говорить о MPEG-1, MPEG-2 и MPEG-3).
> Десятилетия не были простоем на месте, было придумано много новых аглоритмов,
> опередивших своё время как когда-то MPEG.Ну вы ведь сами путаетесь что есть MPEG. Это не больше чем подчинённые медиагрупп которые контролировали весь западный рынок аудио и видео. Нельзя же так подлизывать первое что дадут.
> Теперь есть BD и это стало массово3D-очки и FullHD уже стали массовыми? Покажите мне в РФ хоть один нормальный канал вещающий в FullHD или показывающий 3D-фильмы. Так массово? Или максимум в MPEG-1/2/3 ? Ну и чем тогда WebM хуже?