форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Google отправила в IETF проект RFC для кодека VP8"	+/–
Сообщение от opennews (??) on 22-Янв-11, 10:41
Попытки обвинить (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
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Google отправила в IETF проект RFC для кодека VP8"	+10 +/–
Сообщение от анонимус (??) on 22-Янв-11, 10:41
H.264 конец!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Google отправила в IETF проект RFC для кодека VP8"	+2 +/–
	Сообщение от User294 (ok) on 22-Янв-11, 12:35
	> H.264 конец! Так и надо всяким MPEG LA. Хаха, довыпендривались с своими изменениями правил игры и рубкой бабла за воздух, так что сейчас им придется несладко :)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	14. "Google отправила в IETF проект RFC для кодека VP8"	+4 +/–
	Сообщение от filosofem (ok) on 22-Янв-11, 13:25
	На пороге сидит MPEG LA, а перед нею разбитое корыто H.264. Классику они не читали, торгаши невежественные. =)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	15. "Google отправила в IETF проект RFC для кодека VP8"	–7 +/–
	Сообщение от linux_must_die (ok) on 22-Янв-11, 13:37
	а что, много нынче bd рипов, прожатых VP8? ладно, это новье, а VP7? 6? а вот H264 чуть ли не каждый 2-й
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	16. "Google отправила в IETF проект RFC для кодека VP8"	+3 +/–
	Сообщение от windows_3.14zdec on 22-Янв-11, 13:48
	А причём здесь это? Рипы они по определению незаконны. А здесь идёт речь о законном использовании видео в интернет, тег video вместо гоуноFlesh.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Google отправила в IETF проект RFC для кодека VP8"	+1 +/–
	Сообщение от filosofem (ok) on 22-Янв-11, 13:49
	Че правда что ли? Может еще скажете, что на 9 из 10 ПК установлен MS Windows, и каждый второй браузер IE?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	23. "Google отправила в IETF проект RFC для кодека VP8"	–1 +/–
	Сообщение от Zenitur on 22-Янв-11, 14:32
	> bd рипов Я тебе больше скажу. h264 - официальный стандарт BD-видео, так что если убрать слово "рипов" - то каждый первый! А MPEG2 - DVD-Video.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	26. "Google отправила в IETF проект RFC для кодека VP8"	+12 +/–
	Сообщение от dimqua (ok) on 22-Янв-11, 14:44
	> h264 - официальный стандарт BD-видео Ну и пускай. Blu-ray всё равно не нужен (http://fuckbluray.com/).
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	46. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 22-Янв-11, 21:03
	> Ну и пускай. Blu-ray всё равно не нужен (http://fuckbluray.com/). Ну, может быть некоторым нравится получать трояны в приводах за свои же бабки, смотреть непроматываемую рекламу, наслаждаться ограничениями DRM, использовать только расово верные операционки и плееры, выбранными за них другими, ну и все такое, в общем, в духе свободы, равенства и братства, ага :))
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	64. "Google отправила в IETF проект RFC для кодека VP8"	+1 +/–
	Сообщение от botman (ok) on 23-Янв-11, 11:22
	> h264 - официальный стандарт BD-видео, так что если убрать слово "рипов" - то каждый первый! А MPEG2 - DVD-Video. Ну и какой резон покупать привод способный записывать на каждую болванку какие-то жалкие 25 Гб если за меньшие деньги можно купить внешний ЖД на 1.5Тб? Официальные стандарты CD-дисков идут лесом, вместе с BD!
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	66. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 23-Янв-11, 12:41
	> Ну и какой резон покупать привод способный записывать на каждую болванку какие-то > жалкие 25 Гб если за меньшие деньги можно купить внешний ЖД > на 1.5Тб? Официальные стандарты CD-дисков идут лесом, вместе с BD! Может быть некоторым нравится диджействовать тормозными ненадежными блинчиками имени копирасов, с троянами в приводах и массой геморроя, вплоть до невозможности без дикого траха сделать резервную копию или перегнать в другой формат для просмотра на другом девайсе/системе/плеере/...
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	37. "Google отправила в IETF проект RFC для кодека VP8"	+1 +/–
	Сообщение от User294 (ok) on 22-Янв-11, 17:02
	> а что, много нынче bd рипов, прожатых VP8? А вы с вашим варезом орите погромче. И тогда вас поимеет если и не MPEG LA, так копирасы, после чего вы будете рассказывать про форматы совсем не стандартизаторам, имхо.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	72. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от Зилибоба (ok) on 23-Янв-11, 17:21
	Таки скажите, каждый кто рипнул, заплатил денежку тому кому надо? Скорее всего он еще и за софт которым рипает не платил, не говоря о том, что рипать не законно. так что это все чес... и стандарт дефакто всегда можно поменять, были бы ресурсы...
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	76. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от Аноним123321 (ok) on 23-Янв-11, 22:23
	> а что, много нынче bd рипов, прожатых VP8? ладно, это новье, а VP7? 6? а вот H264 чуть ли не каждый 2-й а каждый второй (другой) -- это Avi/Xvid ...это не смотря на то что на OpenNet-и-LOR мы уже выяслили что VP8 сжимает по крайней мере луше чем Xvid :-) (другими словами -- думаю -- рипперы так и будут жать релизы теми форматами которые используются в ихнем сообществе рипперов. возможно они просто прагматично обосновывают своё поведение DVD-Плаерами-Для-Телевизоров. а возможно просто делают так как всегда привыкли)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	19. "Google отправила в IETF проект RFC для кодека VP8"	–9 +/–
	Сообщение от Толстый_ on 22-Янв-11, 13:56
	Технически их кодек превосходит WebM все еще. "Борцам за свободу" конечно на техническую составляющую наплевать.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	21. "Google отправила в IETF проект RFC для кодека VP8"	+14 +/–
	Сообщение от dimqua (ok) on 22-Янв-11, 14:13
	> "Борцам за свободу" конечно на техническую составляющую наплевать. Неправда. Если человек рассматривает не только техническую составляющую, но и этическую, то это не означает, что на техническую ему наплевать. А вот технофилам, вроде вас, на свободу действительно наплевать.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	38. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 22-Янв-11, 17:06
	> технофилам, вроде вас, на свободу действительно наплевать. Уж не знаю какой он там технофил, скорее просто оторванный от жизни раздолбай. Технофилам должно быть понятно что роялит совокупное сочетание параметров. И геморрой с лицензиями а хотя-бы и в некоторых странах - потенциальная проблема. Видео ж по хорошему делается для ВСЕХ, а не только местечковых.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	84. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от nuclight (ok) on 25-Янв-11, 00:09
	>> "Борцам за свободу" конечно на техническую составляющую наплевать. > Неправда. Если человек рассматривает не только техническую составляющую, но и этическую, > то это не означает, что на техническую ему наплевать. А вот > технофилам, вроде вас, на свободу действительно наплевать. Школьник, расскажи-ка, куда ты эту свободу применишь? И насколько тебе не наплевать на ограничение свободы ширяться героином?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	85. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от dimqua (ok) on 25-Янв-11, 00:40
	> расскажи-ка, куда ты эту свободу применишь? Какую именно? > насколько тебе не наплевать на ограничение свободы ширяться героином? Причём тут героин? Свободу ширяться героином пусть отстаивают наркоманы, а мне, как пользователю программ, куда более важны права пользователей программ.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	86. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от nuclight (ok) on 25-Янв-11, 00:43
	>> расскажи-ка, куда ты эту свободу применишь? > Какую именно? Ту, о которой ты говорил выше по треду, естественно. >> насколько тебе не наплевать на ограничение свободы ширяться героином? > Причём тут героин? Свободу ширяться героином пусть отстаивают наркоманы, а мне, как > пользователю программ, куда более важны права пользователей программ. Еще один логический шаг, и ты поймешь. Может быть.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	87. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от dimqua (ok) on 25-Янв-11, 00:59
	> Ту, о которой ты говорил выше по треду, естественно. Я говорил о свободе пользователей программ. А уж решать, как ею пользоваться, должны сами пользователи. Одно я знаю точно -- нет никаких объективных причин её отнимать. > Еще один логический шаг, и ты поймешь. Может быть. Да я изначально понял на что вы намекаете :)
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	88. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от nuclight (ok) on 25-Янв-11, 01:07
	>> Ту, о которой ты говорил выше по треду, естественно. > Я говорил о свободе пользователей программ. А уж решать, как ею пользоваться, > должны сами пользователи. Одно я знаю точно -- нет никаких объективных > причин её отнимать. Ну че так абстрактно-то, некие пользователи, в неизвестном количестве и с неизвестными свойствами?... Конкретную свободу-то назови. Которую будешь использовать лично ты.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	89. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от dimqua (ok) on 25-Янв-11, 01:10
	В данном случае, я буду использовать свободу "не платить отчисления MPEG LA" :)
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	90. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от nuclight (ok) on 25-Янв-11, 01:28
	> В данном случае, я буду использовать свободу "не платить отчисления MPEG LA" > :) А разве ты её, как конечный пользователь, платишь? Тот же Adobe Flash скачивается совершенно бесплатно - это уже проблема Adobe, отчисления платить.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	91. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от dimqua (ok) on 25-Янв-11, 08:27
	> А разве ты её, как конечный пользователь, платишь? Пока нет, но это только потому что MPEG LA так хочет. Есть ли гарантии, что завтра она не захочет по другому? :) > Тот же Adobe Flash скачивается совершенно бесплатно - это уже проблема Adobe, отчисления платить. Ещё бы ничего если это была бы проблема только Adobe. А как же другие разработчики, разве о них думать не надо?
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	92. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от nuclight (ok) on 25-Янв-11, 12:42
	>> А разве ты её, как конечный пользователь, платишь? > Пока нет, но это только потому что MPEG LA так хочет. Есть > ли гарантии, что завтра она не захочет по другому? :) Есть ли гарантии, что завтра бабушка не окажется дедушкой? >> Тот же Adobe Flash скачивается совершенно бесплатно - это уже проблема Adobe, отчисления платить. > Ещё бы ничего если это была бы проблема только Adobe. А как > же другие разработчики, разве о них думать не надо? Конечному пользователю-то? Зачем?..
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	93. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от dimqua (ok) on 25-Янв-11, 13:56
	> Конечному пользователю-то? Зачем?.. Из-за уважения к ним, солидарности. Почему мне должно быть приятно, если с разработчика программы, которой я пользуюсь будут брать деньги за воздух? В случае если программа платная, такие поборы могут увеличить стоимость программы, что никому не выгодно, кроме копирастов.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	94. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от nuclight (ok) on 25-Янв-11, 23:10
	>> Конечному пользователю-то? Зачем?.. > Из-за уважения к ним, солидарности. Почему мне должно быть приятно, если с > разработчика программы, которой я пользуюсь будут брать деньги за воздух? Это уже личные тараканы в голове - к обсуждаемой свободе конечного пользователя отношения нет. > В случае если программа платная, такие поборы могут увеличить стоимость программы, что > никому не выгодно, кроме копирастов. В таком случае могло бы да. Но рассматривался-то не такой случай.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	95. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от www2 (??) on 31-Янв-11, 13:54
	>Конкретную свободу-то назови. Которую будешь использовать лично ты. Можно будет не думать, а нужно ли заплатить за использование h264 вот в этом случае или нет? Можно будет не думая об этом просто воспользоваться утверждённым стандартом, за использование которого гарантировано никто тебя преследовать не будет. Захотел смонтировать семейный фильм? Каким кодеком воспользоваться? Читать лицензионные требования h264 и думать? Или просто взять VP8 и использовать его не думая ни о чём и ничем не рискуя?
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	96. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от nuclight (ok) on 06-Фев-11, 20:31
	>>Конкретную свободу-то назови. Которую будешь использовать лично ты. > Можно будет не думать, а нужно ли заплатить за использование h264 вот > в этом случае или нет? Можно будет не думая об этом > просто воспользоваться утверждённым стандартом, за использование которого гарантировано > никто тебя преследовать не будет. > Захотел смонтировать семейный фильм? Каким кодеком воспользоваться? Читать лицензионные > требования h264 и думать? Или просто взять VP8 и использовать его > не думая ни о чём и ничем не рискуя? "Свобода не думать" ? Цирк какой-то. Свобода - она относится к чему-то материальному, действиям. А не мыслям, которые и невозможно ограничить.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	24. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от Zenitur on 22-Янв-11, 14:33
	> Технически их кодек превосходит WebM все еще. "Борцам за свободу" конечно на > техническую составляющую наплевать. Так и есть. Одинаковое видео с сжатием lossless у h264 и WebM у h264 занимает 3 мегабайта, а у WebM - 4,5.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	36. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от онано on 22-Янв-11, 16:56
	Для loseless достаточно немного других кодеков.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	77. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от Аноним123321 (ok) on 23-Янв-11, 22:38
	>> Технически их кодек превосходит WebM все еще. "Борцам за свободу" конечно на >> техническую составляющую наплевать. > Так и есть. Одинаковое видео с сжатием lossless у h264 и WebM > у h264 занимает 3 мегабайта, а у WebM - 4,5. это ты тут опять вспомнил случай как какойто "умник" -- перекодировал из НЕ_lossless MPEG-какого-то формата ==в==> WebM-формат -- и в результате получил 4.5 мегобайта ??? (видио -- про баги wine) при этом свой ГЛУПЫЙ эксперимент этот "умник" обосновал тем что то самое изначально-НЕ_lossless видио было в очень хорошем качестве
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	25. "Google отправила в IETF проект RFC для кодека VP8"	+1 +/–
	Сообщение от User294 (ok) on 22-Янв-11, 14:40
	> "Борцам за свободу" конечно на техническую составляющую наплевать. Техническая составляющая - это ведь и сервак с видео в американском датацентре может быть, например...
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	49. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от Ytch on 22-Янв-11, 22:42
	>> "Борцам за свободу" конечно на техническую составляющую наплевать. > Техническая составляющая - это ведь и сервак с видео в американском датацентре > может быть, например... И тут, кроме технической и этической, появляется еще и юридическая составляющая...
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	59. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 23-Янв-11, 09:12
	> И тут, кроме технической и этической, появляется еще и юридическая составляющая... Ну вот с гугловским кодеком можно будет не заморачиваться. А с H.264 - там у этих фруктов из MPEG LA условия на каждый пук. Если юзаете так - плати, этак - тоже плати, сяк - тоже плати. Понятно что в России у них руки коротки, но веб есть не только в Росси...
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	41. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от iZEN (ok) on 22-Янв-11, 18:12
	Поменяли качество на свободу. Только и всего.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	48. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от Ytch on 22-Янв-11, 22:39
	> Поменяли качество на свободу. Только и всего. В данном случае, качество со временем допилится, а несвободное станет свободным когда уже совсем никому не нужным станет.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	57. "Google отправила в IETF проект RFC для кодека VP8"	+4 +/–
	Сообщение от User294 (ok) on 23-Янв-11, 08:55
	> Поменяли качество на свободу. Только и всего. А свобода - типа не качество?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	69. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от iZEN (ok) on 23-Янв-11, 13:35
	>А свобода - типа не качество? Свобода не относится к техническим деталям программного продукта.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	82. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 24-Янв-11, 22:15
	> Свобода не относится к техническим деталям программного продукта. Она относится к юридическим деталям. И, кстати, юридические детали на раз могут похоронить любые технические. В частности, толку то с крутого формата, если им нельзя пользоваться нормально на почти половине планеты. Вы как, предлагаете стартапам позабивать на крупнейшие перспективнейшие рынки?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	47. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от Ytch on 22-Янв-11, 22:30
	>> H.264 конец! >Так и надо всяким MPEG LA. Хаха, довыпендривались с своими изменениями правил игры и >рубкой бабла за воздух, так что сейчас им придется несладко :) Они по ходу повторяют путь MS! Сейчас они уже вот-вот просрут веб и mobile, а там уже и до остального рукой подать (форматы видео - это, все-таки не ОС и не офисный пакет, и инерционность пользователей здесь им не сильно поможет).
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	60. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 23-Янв-11, 09:32
	> Они по ходу повторяют путь MS! Сейчас они уже вот-вот просрут веб > и mobile, а там уже и до остального рукой подать Ну да, именно :). Гугл и там и там является достаточно приличной силой.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

2. "Google отправила в IETF проект RFC для кодека VP8"	+/–
Сообщение от анон on 22-Янв-11, 11:17
Можественные вставки "Begin code block" радуют чрезвычайно
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Google отправила в IETF проект RFC для кодека VP8"	+1 +/–
Сообщение от User294 (ok) on 22-Янв-11, 12:24
Все правильно сделали. Так держать, Гугл! :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	42. "Google отправила в IETF проект RFC для кодека VP8"	–6 +/–
	Сообщение от iZEN (ok) on 22-Янв-11, 18:16
	Что правильно? Телевизионный ты наш, будешь смотреть телевизор с WebM, об остальном за тебя позаботиться Google. :)) Захочешь видеочатик — а нииизя, WebM непригоден к кодированию со сжатием видеопотока в реальном времени. :))
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	56. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от iZEN (ok) on 23-Янв-11, 08:24
	WebM -> VP8
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	58. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 23-Янв-11, 09:03
	> Что правильно? Все. Начиная от покупки и заканчивая желанием стандартизировать. > Телевизионный ты наш, будешь смотреть телевизор с WebM, об остальном > за тебя позаботиться Google. :)) Как-то слишком толсто. > Захочешь видеочатик Во первых, мне эти ваши видеочатики никуда не упали. Пусть у тех кому это надо голова и болит. > — а нииизя, Вот прямо законы физики запрещают, ага. А ничего что... 1) Небольшой поток на мощном CPU наверное уже сейчас можно протолкать. Хоть и жрать проц будет, что нехорошо. 2) Уже делаются чипы которые позволят и кодировать и декодировать VP8. Гугл явно всерьез настроен всыпать MPEG LA и все такое :) 3) Оптимизацию кодека и написание новых реализаций никто не отменял. Например никогда не слышал про xVP8? А то там гугл в принципе принял на работу минимум одного перца работавшего над ffmpeg. В общем гугл настроен серьезно :) > WebM непригоден к кодированию со сжатием видеопотока в реальном времени. :)) Subject to change, ИМХО.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	70. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от К.О. on 23-Янв-11, 15:38
	Почему? Если стандартизуют - появление микроконтроллеров с акселерацией VP8 - вопрос времени.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	75. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от аномим on 23-Янв-11, 21:44
	> появление микроконтроллеров с акселерацией VP8 - вопрос времени. А декодировать H.264 аппаратно можно на любом встроенном гомне вроде GF8200
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	78. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от Аноним123321 (ok) on 23-Янв-11, 22:46
	>> появление микроконтроллеров с акселерацией VP8 - вопрос времени. > А декодировать H.264 аппаратно можно на любом встроенном гомне вроде GF8200 вот только несуществует НИОДНОЙ полностью-FREEOPENSOURCE операционной системы (включая драйвера и видиопроигрыватель) на которой бы это аппаратная поддержка H.264 смоглабы зарабатать на вашей любимой GF8200 # p.s.: дальше я уже представляю что следущие комментаторы будут меня убеждать в том что открытые-исходники не нужны ...что один разок можно установить блоб ....ну и что вообще "один раз не считается..." :-D
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

4. "Google отправила в IETF проект RFC для кодека VP8"	+/–
Сообщение от valexey on 22-Янв-11, 12:32
Что держать то? Это rfc на декодирование. А на кодирование rfc нет. На сколько я знаю, никак не описано как этот VP8 передавать через rtp. Также у VP8 есть проблема -- он очень медленно кодируется. Следовательно для видеоконференций, видеозвонков, видеочятиков он не пригоден совершенно. В отличае от h264. Т.о. VP8 пригоден лишь для одного -- просмотра видеороликов. H264 же пригоден почти для всего (есть специфические области, где и он не пригоден, и где приходится пользоваться mjpeg'ом).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Google отправила в IETF проект RFC для кодека VP8"	+2 +/–
	Сообщение от Аноним (??) on 22-Янв-11, 12:48
	>Т.о. VP8 пригоден лишь для одного -- просмотра видеороликов. Именно это и интересует гугл, а также w3c.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	7. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от valexey on 22-Янв-11, 12:58
	> Именно это и интересует гугл, а также w3c. Это не так. Во-первых в html5 драфте ещё летом появился тэг device, что позволяет из js получить доступ к видеокамере и микрофону. Т.о. когда-нибудь можно будет сделать видеоконференцию в чистом браузере без плагинов. Если бы w3c эта нише (видеоконференции) не интересовала бы, наврятли это появилось бы в драфте. Также в появлении этого тэга замешан и гугл. Во-вторых у гугла в своём Google Talk'e используется h264 для видеозвонков. И я не думаю что они там его заменят на vp8. Т.о. вся это беготня вокруг выпиливания h264 -- всего лишь политические игры, в которых гугл, пользуясь невежеством подавляющего большенства, манипулирует мнением и использует это самое мнение этого самого большенства в качестве одного из козырей в партии. По сути сейчас идет навязывание (или видимость навязывания) существенно худшего технического решения.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	10. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от none_first (ok) on 22-Янв-11, 13:10
	при употреблении сравнительной степени "существенно худшего технического решения" циферьки на тесты приводят без цыферек - пустой трёп "Во-вторых у гугла в своём Google Talk'e используется h264 для видеозвонков" и это как-то предваряет его дальнейшее использование? Совершенно не очевидно
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	12. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от valexey on 22-Янв-11, 13:17
	Насколько я помню, кодирует он где-то в 4-10 раз медленней. Это без учета того, что h264 можно кодировать в специализированными чипами прямо сейчас (в частности есть вебкамеры которые сами кодируют в h264 кодек). Как в ffmpeg'e допилят vp8 енкодер, я проведу тесты ещё раз (к сожалению у них там какие-то внутренние разборки начались, как это скажется на сроках -- не понятно).
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	40. "Google отправила в IETF проект RFC для кодека VP8"	+1 +/–
	Сообщение от User294 (ok) on 22-Янв-11, 17:39
	> Насколько я помню, кодирует он где-то в 4-10 раз медленней. Это без > учета того, что h264 можно кодировать в специализированными чипами прямо сейчас Гугл уже подтолкнул создание чипов которые кодируют/декодируют VP8 ;)
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	71. "Google отправила в IETF проект RFC для кодека VP8"	–1 +/–
	Сообщение от _umka_ (??) on 23-Янв-11, 15:54
	да да да. подскажите где можно купить видеокарту с акселерацией vp8 ?
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	79. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от Аноним123321 (ok) on 23-Янв-11, 23:16
	> да да да. > подскажите где можно купить видеокарту с акселерацией vp8 ? а где можно купить видиокарту с работающщей акселерацией H.264 ? (при условии -- не ставить проприетарных программ/библиотек в операционную систему)
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	80. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от dimqua (ok) on 24-Янв-11, 08:06
	Встроенный Intel вроде умеет, нет?
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	81. "Google отправила в IETF проект RFC для кодека VP8"	+1 +/–
	Сообщение от коксюзер on 24-Янв-11, 10:59
	> Т.о. вся это беготня вокруг выпиливания h264 -- всего лишь политические игры, > в которых гугл, пользуясь невежеством подавляющего большенства, манипулирует мнением > и использует это самое мнение этого самого большенства в качестве одного > из козырей в партии. Вы раскрыли мне глаза, спасибо! Оказывается, VP8 медленно кодирует и непригоден для видеочатов... Это в корне всё меняет. Теперь очевидно, что необходимо принять условия лицензионных соглашений с MPEG LA. Ухх! Как представлю, аж морозец по коже... Подумать только: кодек оказался непригоден для видеочатов! Какая уж тут свобода стандартов и реализаций... Спасибо вам. > По сути сейчас идет навязывание (или видимость навязывания) существенно худшего технического > решения. Да, действительно, вы правы. Тормозной видеочат - эта кабала пострашнее лицензионной.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	8. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от Кракен (ok) on 22-Янв-11, 13:03
	>Также у VP8 есть проблема -- он очень медленно кодируется. Скоро пройдет, не переживай. Мощности растут, коды совершенствуются.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	9. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от valexey on 22-Янв-11, 13:06
	Это опять таки не совсем так. В частности ёмкость батареек не особо растёт. Автономность устройств не повышается. Переход на vp8 отбросит индустрию где-то на 5-6 лет назад. Минимум.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "Google отправила в IETF проект RFC для кодека VP8"	+7 +/–
	Сообщение от none_first (ok) on 22-Янв-11, 13:13
	> Это опять таки не совсем так. > В частности ёмкость батареек не особо растёт. > Автономность устройств не повышается. > Переход на vp8 отбросит индустрию где-то на 5-6 лет назад. Минимум. ой не переживайте за индустрию её есть кому и чем отбрасывать, а уж проприетарность - первейший из факторов тормоза технологий небылоб патентов на "алгоритмы" - и этой истерии не существовало бы
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	13. "Google отправила в IETF проект RFC для кодека VP8"	–1 +/–
	Сообщение от valexey on 22-Янв-11, 13:19
	А их и нет. У нас. :-) Я как бы переживаю потому, что занимаюсь непосредственно написанием софта для этих самых видеозвонков, видеоконференций и прочего.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	34. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от Аноним (??) on 22-Янв-11, 16:05
	странно но что бы поддержать индустрию не хотите написать кодек не отбрасывающий её на 5 лет назад ? и бабла бы срубили
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	35. "Google отправила в IETF проект RFC для кодека VP8"	+2 +/–
	Сообщение от valexey on 22-Янв-11, 16:35
	Разработка видеокодеков находится вне моей компетенции. Я их использую, изучаю, могу например преобразовать видеопоток в соренсоне в поток h263+ без перекодирования (без сторонних утилит), но кодеки я не разрабатываю, и даже не реализации их не пишу. Если интересны альтернативы, и вообще что перспективного в мире есть, то можете посмотреть на например наработки компании Spirit (http://spirit.ru). Это российская компания, соответственно российские разработка. У них очень интересный видеокодек. Он использует несколько слоёв кодирования. В результате, в случае видеоконференции, когда у нас на сервере стоит MCU (http://ru.wikipedia.org/wiki/Multipoint_Control_Unit), оный сервер может склеивать множество видеопотоков в один практически без перекодирования. Т.е. изменение разрешения кадра там очень дешевая операция. Соответственно в h263/h264/vp8 тут пришлось бы каждый из потоков декодировать в yuv420p, изменять размер каждого из кадров, затем копировать это всё дело в результирующий кадр (каждый в своё место), затем этот кадр кодировать. Что довольно затратно.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	44. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от crypt (??) on 22-Янв-11, 18:41
	valexey, я вот честно не особо в теме видеокодирования, на твой взгляд, проблемы VP8 в дезайне или в реализации?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	51. "Google отправила в IETF проект RFC для кодека VP8"	+4 +/–
	Сообщение от valexey on 23-Янв-11, 00:21
	Мне кажется, и в том и в другом. Реализацию рано или поздно подтянут я думаю, будет проигрывать 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'тьего).
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	52. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от crypt (??) on 23-Янв-11, 00:45
	Мне остается только снять шляпу - ответ настолько развернутый, что и вопросов нет. :) Может, гуглу при таком раскладе надо было купить владельцев x264:) Или они в следующих версиях рассчитывают все улучшить. А MPEG LA действительно ведь уже пошли на уступки.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	68. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 23-Янв-11, 12:56
	> нет. :) Может, гуглу при таком раскладе надо было купить владельцев x264:) x264 - всего лишь один конкретный кодек. Они вообще патенты лицензировать не могут. Купить MPEG LA? А оно всего лишь "крыша" над стадом корпораций, среди которых есть всякие там эппла и прочие незначительные фигни. Покупать все эти корпорации можно немного подзадолбаться будет. Ну да, это ж такая фигня - пойти и купить себе пару Эпплов в портфолио :)
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	54. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от нони on 23-Янв-11, 04:57
	> B-frame не является опорным Маленькое уточнение. Очевидно, в целях упрощения общей картины, вы не упомянули, что промежуточные кадры также могут быть опорными (--b-pyramid)
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	55. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от valexey on 23-Янв-11, 05:03
	Да. Именно поэтому. Причем эта возможность, если мне склероз не изменяет, есть даже в H263. Плюс, на самом деле, есть ещё и другие типы фреймов. В общем там много всего. Я постарался не начать пересказывать спеку кодека :-) Просто изложил самые основы, как оно обычно устроено. Интересующиеся могут почитать спеку на например H263 -- официальная дока есть и на русском (официально).
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	61. "Google отправила в IETF проект RFC для кодека VP8"	–1 +/–
	Сообщение от User294 (ok) on 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-кадре, а потом грамотно туда референситься.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	83. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 24-Янв-11, 22:31
	P.S. кстати вспомнил: B-кадры вполне себе были еще в дрееееееевнем MPEG-1 (и MPEG-2). Что как-то не сильно помогало оным в достижении хороших соотношение битрейт-качество. Почему-то они легко проигрывали по соотношению битрейт-качество любому MP4 не использующему B-кадры вообще (а ранние реализации их и не использовали, что не помешало им начать процесс закапывания мпег1/2). В общем b-кадры - дрееевняя фича. А вы ее как epic win технологий преподносите...
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	73. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от LuckAs (ok) on 23-Янв-11, 17:25
	> Мне кажется, и в том и в другом. Реализацию рано или поздно > подтянут я думаю, будет проигрывать h264 не более чем в 2-3 > раза. Мне очень интересно как реализовали в avcodec'e (ffmpeg). Как только, > так сразу пощупаю. > На счет дизайна.. Ну например там есть одна особенность (точнее она присутствует > во всех кодеках On2, т.е. VP1...VP8): у них не используются B-frame'ы. > На всякий случай поясню что это такое: > В видеопотоке бывают три вида кадров: Насколько я ориентируюсь, то именно это и есть СУТЬ патента на h264, и именно поэтому все ограничения и возникают на использование этой технологиии в других кодеках!!! Копирастов уже заставили отодвинуть по времени введение платы за кодек, и теперь надо додавить этих красавчиков тем, что несмотря на их хитрость никто не собирается платить за устройство УЖЕ известного на 100% АЛГОРИТМА в угоду только их кошелька. Любой патент и запрет на алгоритм - это преступление против ПРОГРЕССА. Не забыли ли уважаемые, что некоторые товарисчи пытались получать деньги с каждой лямпочки?
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	39. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 22-Янв-11, 17:33
	> А их и нет. У нас. :-) А у вас - это где? Интернет как бы глобальная сеть... > Я как бы переживаю потому, что занимаюсь непосредственно написанием софта для этих > самых видеозвонков, видеоконференций и прочего. Ага. И такой весь из себя незначительный рынок США - вы как, игнорируете, или радостно отсандаливаете роялти?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	67. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 23-Янв-11, 12:49
	> В частности ёмкость батареек не особо растёт. Емкость батареек растет медленно, факт. А вот MIPS/Watt - весьма даже. Поэтому от одной и той же емкости батарейки можно смолотить все больше инструкций. Какиенить ARM в этом плане очень некисло упираются - 2 ядра более чем 1ГГц при весьма скромном потреблении уже совсем не фантастика. > Автономность устройств не повышается. А ничего что процессоры совершенствуются, в частности, соотношение MIPS/Watt у новых процессоров шибко лучше чем у старых. Технологические нормы - улучшаются. Ядра - совершенствуются. > Переход на vp8 отбросит индустрию где-то на 5-6 лет назад. Минимум. Да никто никуда никого не отбросит. А всякие там видеочатики... извините, ну вон 3G - есть. А где же массовое использование видеозвонков? Что, оказалось что оно никому особо не надо, и вообще нишевая бнопня? Надо же, вот незадача. А теперь сравниваем с популярностью ютуба. Что, всего 2 млрд роликов в день смотрят? А где же 2 млрд видеозвонков в день? Ну вот и интересы соответствующе распределяются. Т.е. сперва - веб, а потом, может быть, и до видеочатиков руки дойдут. Если будет существенный спрос и все такое. Спрос рождает предложение. Для веба спрос на универсальный, везде работающий без выплат и оговорок кодек - есть. Каждый второй вебмастер - потенциальный источник такого спроса.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	74. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от iZEN (ok) on 23-Янв-11, 21:04
	> Переход на vp8 отбросит индустрию где-то на 5-6 лет назад. Минимум. Рискну предположить, что это наруку операторам мобильной связи, чтобы заменить GSM/3G на 4G для полноценных видеозвонков и перевода мобильной связи на Интернет-основу, где деньги считаются не за количество минут/мегабайт, а за предоставление услуг по фиксированной ставке.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	18. "Google отправила в IETF проект RFC для кодека VP8"	+2 +/–
	Сообщение от СуперАноним on 22-Янв-11, 13:54
	>Также у VP8 есть проблема -- он очень медленно кодируется. Следовательно для видеоконференций, видеозвонков, видеочятиков он не пригоден совершенно. И нафига для видеозвонков и видеочатикой вообще видеокодеки высокого качества? Для этого сгодятся кодеки с низким качеством с небольшим битрейтом и высокой скоростью кодирования.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	27. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от valexey on 22-Янв-11, 14:51
	Приведите пожалуйста наименование кодеков, которые, как вам кажется, подошли бы для видеозвонков и видеоконференций.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	28. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от анон on 22-Янв-11, 14:55
	> И нафига для видеозвонков и видеочатикой вообще видеокодеки высокого качества? Для этого > сгодятся кодеки с низким качеством с небольшим битрейтом и высокой скоростью > кодирования. Theora
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	29. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от valexey on 22-Янв-11, 15:13
	Чудес всё таки не бывает. Theora это ведь VP3. Она да, кодирует быстро (благо разработка 2000 года, тогда машинки были послабее), но полосу при этом требует достаточно широкую. Грубо говоря, ей нужно где-то в два-три раза больше полосы чем h264. И примерно столько же, сколько h263. Кстати, какие преимущества у VP3 перед H263+ ? Также очень хотелось бы увидеть какой-нибудь rfc где описывался бы формат дополнительных заголовков rtp для теоры. Без этого видеозвонок, видеоконференцию и т.п. не сделать.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	31. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 22-Янв-11, 15:33
	> Кстати, какие преимущества у VP3 перед H263+ ? Отсутствие MPEG LA и просто сообщество тех кто ее развивает? А то на 263 по-моему все забили. Как максимум развивая что-то типа xvid как более легкий кодек.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	32. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от valexey on 22-Янв-11, 15:46
	MPEG LA никак не припятствует использованию H263+. Т.е. никаких роялити и прочих препонов. Можно сказать что это открытый кодек. Тем более что открытые имплементации имеются. В том же avcodec'e например. H263+ активно используется в телекоме, в частности для видеозвонков, видеоконференций и т.п. Собственно даже если взять просто флэш, то он умеет енкодить ровно одним кодеком -- sorenson, который является вариацией H263+ кодека (можно конвертировать туда-сюда без перекодирования). У H263 есть 3 или 4, как бы это назвать.. , поколения? Последнее датировано 2005 годом. Имплементаций полно разных. Другое дело, что про H263 не трубят на каждом углу, его просто активно используют. Да, ресурсожёркость h263 примерно в 4 раза меньше чем у H264 (с fast профилем последнего).
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	62. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 23-Янв-11, 10:12
	> 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 как-то получше справлялись.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	30. "Google отправила в IETF проект RFC для кодека VP8"	+1 +/–
	Сообщение от User294 (ok) on 22-Янв-11, 15:31
	> Что держать то? Это rfc на декодирование. А на кодирование rfc нет. По нормальному должен быть RFC на формат потока. А как вы его там будете создавать и разбирать - это уже ваше дело, вообще. > На сколько я знаю, никак не описано как этот VP8 передавать через rtp. А почему именно через RTP, кстати? > Также у VP8 есть проблема -- он очень медленно кодируется. Следовательно для > видеоконференций, видеозвонков, видеочятиков он не пригоден совершенно. В отличае от h264. Для железок чипов понаделают. Уже первые образцы есть. > Т.о. VP8 пригоден лишь для одного -- просмотра видеороликов. Как ни странно его для этого и будут юзать :). С чипами - и для иных нужд тоже. > не пригоден, и где приходится пользоваться mjpeg'ом). ну mjpeg'у - mjpeg'овское.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	33. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от valexey on 22-Янв-11, 15:53
	> А почему именно через RTP, кстати? А какие варианты? RTP ходит поверх UDP. И это хорошо, потому что нет ретрансмитов. Т.е. реалтаймовость выдержать можно. В видеозвонках/видеоконференциях важнее отсутствие задержки (точнее задержка в пределах нормы -- до 250 мс примерно) нежели целостность потока. Т.е. лучше дропнуть кадр чем долго и упорно пытаться его перепослать. Если это был не ключевой кадр (а ключевые посылаются весьма редко), то не будет даже порчи картинки. > Для железок чипов понаделают. Уже первые образцы есть. Ну вот когда понаделают... Кроме того, у меня имеются некие подозрения на счет сложности алгоритма, которую не убрать оптимизациями кода или воплощением в железе.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	63. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от User294 (ok) on 23-Янв-11, 10:20
	> А какие варианты? RTP ходит поверх UDP. И это хорошо, потому что > нет ретрансмитов. Т.е. реалтаймовость выдержать можно. В вебе все это неактуально. Там надо чтобы работало ВЕЗДЕ. А RTP имеет ряд проблем с файрволами, натами и прокси. Вот и юзают все видеосервисы простой HTTP, как на подбор. Он нигде не застревает, поэтому все могут смотреть видео а не канифолить мозг саппортам. Более того - для онлайн видео никакая латентность никому не нужна. Поэтому тупо пребуферят заметный кусок до начала воспроизведения. А если все-таки опа случилась - перезапрашивают поток с нужной позиции, заново наполняя буфер.   > В видеозвонках/видеоконференциях важнее отсутствие задержки Все так, только WEBM/VP8 как-то не позиционируется в эту нишу, поэтому - "who cares?" > Т.е. лучше дропнуть кадр чем долго и упорно пытаться его перепослать. Кэп, это вы? Азы VoIP и видеоконференций - это круто, но ... но гугл вроде и не позиционировал этот кодек как убийцу видеоконференций :).То что в вашей узкой нише "видеозвонки" счастья не наступило, как минимум пока - ну да, все так. И чего? Лично мне например все эти видеозвонки вообще никуда не впились (как максимум меня может заинтересовать реалтаймное кодирование с камер наблюдения, но это тоже отдельная ниша, пересекающаяся с веб лишь частично). >> Для железок чипов понаделают. Уже первые образцы есть. > Ну вот когда понаделают... Кроме того, у меня имеются некие подозрения на > счет сложности алгоритма, которую не убрать оптимизациями кода или воплощением в > железе. Я так понял что какие-то финики по заказу гугеля УЖЕ родили соответствующие чипы :). Ну в общем когда нельзя, но очень хочется - тогда можно. Вот гугл кажется всерьез решил надрать некоторым задницы. И учтя их массу и то что они еще не стали тормозами типа майкрософтов и айбиэмов - у них есть все шансы это сделать :)
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

22. "Google отправила в IETF проект RFC для кодека VP8"	+/–
Сообщение от pavlinux (ok) on 22-Янв-11, 14:22
Впервые в рабочей программе вижу работу с 4-мерными массивами. :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "Google отправила в IETF проект RFC для кодека VP8"	+3 +/–
Сообщение от BratSinot on 22-Янв-11, 18:38
Слушайте, народ вы тут все "бла-бла-бла" на тему, что VP8 медленнее, сжимает чуть-чуть меньше, вы посмотрите на СРОК РАЗРАБОТКИ! H.264 кодеры и декодеры уже сколько времени разрабатываются, а WebM появился относительно недавно и уже почти круче. Если он разрабатывался бы столько-же времени, он будет круче. А учитывая открытость, всевозможные баги и дополнения будут быстрее делаться. P.S. Специально для тех, кто опять начнет бубнить про то, что открытость не есть хорошо и тыркать кучей неизвестных проектов. WebM это очень известная штука, чтоб её не разрабатывали. Она уже вовсю обкатывается(вспомним про реализацию от ffmpeg), да и потом сама Google будет на все-возможных конференциях делать конкурсы, типа: "Исправь баг, получи 500$!"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	50. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от анони on 22-Янв-11, 22:43
	> WebM появился относительно недавно VP8 года три-четыре и появился не на пустом месте, а как развитие (в ошибочном направлении) предыдущих поколений > WebM это очень известная штука buzzword
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	53. "Google отправила в IETF проект RFC для кодека VP8"	+/–
	Сообщение от Zenitur on 23-Янв-11, 01:33
	Полностью согласен! Первые MPEG'и получили оглушительный успех! Затем было долгое затишье. Десятилетия не были простоем на месте, было придумано много новых аглоритмов, опередивших своё время как когда-то MPEG. Ещё до h264 я часто встречал разговоры на тему "а что это вы не пользуетесь новыми кодеками - они жмут лучше DivX и по-настоящему используют ресурсы современных компьютеров!". Теперь есть BD и это стало массово
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	65. "Google отправила в IETF проект RFC для кодека VP8"	+1 +/–
	Сообщение от botman (ok) on 23-Янв-11, 12:30
	> Полностью согласен! Первые MPEG'и получили оглушительный успех! Затем было долгое затишье. Начало девяностых годов вообще имело оглушительный успех у индустрии развлечений (если говорить о MPEG-1, MPEG-2 и MPEG-3). > Десятилетия не были простоем на месте, было придумано много новых аглоритмов, > опередивших своё время как когда-то MPEG. Ну вы ведь сами путаетесь что есть MPEG. Это не больше чем подчинённые медиагрупп которые контролировали весь западный рынок аудио и видео. Нельзя же так подлизывать первое что дадут. > Теперь есть BD и это стало массово 3D-очки и FullHD уже стали массовыми? Покажите мне в РФ хоть один нормальный канал вещающий в FullHD или показывающий 3D-фильмы. Так массово? Или максимум в MPEG-1/2/3 ? Ну и чем тогда WebM хуже?
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

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

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