The OpenNET Project / Index page

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

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


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

Оглавление

Google, Cisco, Mozilla и Microsoft объединили усилия в созда..., opennews (??), 01-Сен-15, (0) [смотреть все]

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


2. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +8 +/–
Сообщение от Аноним (-), 01-Сен-15, 20:30 
Во, совсем другое дело. Давно бы так.

p.s. а как они микрософт то уломали? MS засцал от перспективы поддерживать 3 кодека в браузере? :)

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

6. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +35 +/–
Сообщение от Orduemail (ok), 01-Сен-15, 20:41 
У майкрософта опять какой-нибудь хитрый план, вот посмотришь. В результате все свободные видеокодеки загнутся, останутся только те, с которых отчисления майкрософту идут. Удивительно лишь то, что почему-то история никого не учит, и с майкрософтом продолжают сотрудничать, каждый раз наступая на одни и те же грабли.
Ответить | Правка | Наверх | Cообщить модератору

17. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  –7 +/–
Сообщение от Тот_Самый_Анонимус (?), 01-Сен-15, 21:42 
Не стоит искать хитрый умысел там, где всё объясняется банальной глупостью.
Ответить | Правка | Наверх | Cообщить модератору

19. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +12 +/–
Сообщение от EHLO (?), 01-Сен-15, 21:54 
> Не стоит искать хитрый умысел там, где всё объясняется банальной глупостью.

Особенной хитрости не нужно чтобы тормозить разработку и тащить все потенциально полезное к себе в проприетарный аналог.
С OpenGL в свое время был аналогичный случай: Microsoft так же входил в группу разработчиков и одновременно пилил свой Direct3D.

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

24. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +1 +/–
Сообщение от Аноним (-), 01-Сен-15, 22:53 
>> Не стоит искать хитрый умысел там, где всё объясняется банальной глупостью.
> Особенной хитрости не нужно чтобы тормозить разработку

А вот это может и не получиться. Кодек на 10% спецификации и на 90% - реализация. И хоть там трава не расти, но независимых разработчиков тормознуть в плане качественной реализации не получится. А качественная реализация простой спецификаци может уделать с треском абы какую реализацию более сложного и эффективного стандарта.

Опенсорсный xvid легко делает H.264 от адобы по битрейт/качество. Хоть xvid и реализует простой профайл MP4, а H.264 - куда более полный, фичастый и потому потенциально более эффективный суперсет фич MP4.

> С OpenGL в свое время был аналогичный случай: Microsoft так же входил
> в группу разработчиков и одновременно пилил свой Direct3D.

OpenGL заглох в развитии как-то без участия MS. Да и DX - тоже. Собственно и DX и GL в последнее время лишь немного косметически дополняли, и не более того.

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

29. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +3 +/–
Сообщение от EHLO (?), 01-Сен-15, 23:02 
> OpenGL заглох в развитии как-то без участия MS. Да и DX -
> тоже. Собственно и DX и GL в последнее время лишь немного
> косметически дополняли, и не более того.

Дело было в конце 90-х и начале 00-х, а не в последнее время.

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

55. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Аноним (-), 02-Сен-15, 03:07 
> Дело было в конце 90-х и начале 00-х, а не в последнее время.

А реально развитие встряло в последнее время. Пока АМДшники со своим Mantle не показали что можно все это взять да и переделать. Под то как устроеныс современные GPU. А не тот доисторический fixed function hardware и даже не нечто с делением по типам шейдеров.

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

125. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Аноним (-), 02-Сен-15, 23:40 
Каким образом видео-API связан с устройством современных GPU?
Ответить | Правка | Наверх | Cообщить модератору

129. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Cameron (?), 03-Сен-15, 12:00 
Когда в API всё задумано под работу с теми GPU которые были многолет тому назад, то чтобы работать с современными GPU идёт большой оверхед на связь API с исполнителем этих команд, что скорости не прибавляет.
Ответить | Правка | Наверх | Cообщить модератору

140. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Аноним (-), 03-Сен-15, 19:32 
> Каким образом видео-API связан с устройством современных GPU?

Ну вот таким. У OpenGL много оверхеда и он все делает своеобразно. Там нельзя просто взять и сделать что-то. Извольте забиндить ресурс, и только тогда сможете с ним что-то делать. Direct State Access, позволяющий не делать binding - появился там без году неделю. И все-равно GL весьма далеко от того что хотели бы создатели игровых движков на самом деле. Они хотели бы простой, низкоуровневый, предсказуемый доступ. С минмальным оверхедом. А не меганевъ...ное и тормозливое апи с кучей внутренних операций и навязыванием всякого безобразия, так что потом это все приходится костылить и воркэраундить, а работает все-равно так себе.

А Vulkan - слизан с Mantle, и все это создано по заявкам более-менее современных игроделов с их актуальными движками. Он сделан с нуля и под современное железо. Железо которое fixed function или с делением на типы шейдеров - принципиально в пролете. Это яркая черта между допотопным старьем и современными архитектурами.

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

42. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +1 +/–
Сообщение от Добрый Дохтур (?), 02-Сен-15, 00:30 

> Опенсорсный xvid легко делает H.264 от адобы по битрейт/качество. Хоть xvid и
> реализует простой профайл MP4, а H.264 - куда более полный, фичастый
> и потому потенциально более эффективный суперсет фич MP4.

как можно сравнивать кодеки (mpeg-4 part 2 vs mpeg-4 part 10) и контейнер для видео(mp4)?

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

56. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  –1 +/–
Сообщение от Аноним (-), 02-Сен-15, 03:09 
> как можно сравнивать кодеки (mpeg-4 part 2 vs mpeg-4 part 10) и
> контейнер для видео(mp4)?

Как видишь, ты понял что я имел в виду, док ;). Пардон, я не такой фанат мпега чтобы наизусть помнить их обозначения. Я вообще MPEG недолюбливаю за то что они поклали на патенты и втюхивают как стандарты проблемный крап.


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

110. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +3 +/–
Сообщение от Анонимный кодировщик (?), 02-Сен-15, 16:31 
> Пардон, я не такой фанат мпега чтобы наизусть помнить их обозначения. Я вообще MPEG недолюбливаю за то что они поклали на патенты и втюхивают как стандарты проблемный крап.

Ты невежда, и еще и кичишься этим. Если бы знал названия, не писал бы ахинею типа:
> Опенсорсный xvid легко делает H.264 от адобы по битрейт/качество. Хоть xvid и реализует простой профайл MP4, а H.264 - куда более полный, фичастый и потому потенциально более эффективный суперсет фич MP4.

Спецификация "MPEG4 part 2" имеет разные реализации от DivX, Xvid, Mainconcept (adobe), тысячи их. В таких кодеках Level и Profile формируют набор применяемых алгоритмов при кодировании, которые всенепременно повлияют на процесс декодирования и поэтому, вероятно проиграются не на каждом устройстве. Чем выше уровень, тем мощнее устройство декодирования. Чем выше профиль тем новее ревизия спецификации. Устройства, заявляющие поддержку того или иного кодека, должны уточнить уровень и профиль в документации. Справедливости ради "MPEG4 part 2" ~ "H263". Вот только у них разные матрицы квантования (не влияет на декодирование), другое именование уровней и профилей (простите, annex-ов, оно так называется в связь-ориентированном мире). H263 больше ориентирован на канальную передачу видеопотока, но факт остается фактом спецификация H263 совместима с MPEG4 part 2, хотя они разрабатывались разными людьми, причем прошлая ревизия "MPEG4 part 2" = "H262".
"H264",  в свою очередь, = "MPEG4 Part 10" в него включены все необходимые уровни/профили для стриминга, трюки, типа FMO и многое другое. И все эти уровни/профили несовместимы со спецификацией "MPEG4 part 2". Совсем. Там нет никакого "суперсета фич". Есть схожие удачные алгоритмы типа Qpel итд, общая логика DCT и квантования. Но вот переменный размер макроблоков, B-pyramid, сжатие CABAC/CAVLC и пр. все меняет. Нет там совместимости по уровням и профилям, другая спецификация, другой кодек.
И чтобы не было путаницы MP4 - это такой контейнер, куда можно сложить несколько потоков и синхронизировать их по шкале времени. Полное название "MPEG4 part 7", проигрывал открытому mkv с момента создания по поддержке разномастных потоков и прочим плюшкам, но выигрывал в производительности на любом оборудовании.

И кстати, Добрый Дохтур такой же как ты.
> как можно сравнивать кодеки (mpeg-4 part 2 vs mpeg-4 part 10) и контейнер для видео(mp4)?

Очень просто. Метриками PSNR, SSIM или статистически путем опроса живых людей (малоэффективен на длинных видеопослеловательностях). Опустим, что некоторые дуралеи не видит разницу между кодеком и контейнером.

tl;dr
Xvid может быть лучше x264, а может и наоборот. Сильно зависит от того, что внутри видео, и какие уровни и профили используются. А если используем "unrestricted" то еще и от прямоты рук того, кто жамкает кнопки.

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

113. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +2 +/–
Сообщение от Аноним (-), 02-Сен-15, 18:17 
> Ты невежда, и еще и кичишься этим. Если бы знал названия, не писал бы ахинею типа:

Невежа в курсе идей работы этих алгоритмов. И знает чем отличаются I, P и B кадры. И все такое прочее. Просто мпегами я в последнее время мало интересуюсь т.к. меня достало что эта группа "экспертов" и "стандартизаторов" занимается тем что проталкивает набивание карманов всяких MPEG LA, при том что въе по части качественной реализации совсем другие люди. Такой группе экспертов и стандартизаторам - место на свалке истории.

Ну а с практической точки зрения я на данный момент научился неплохо кодировать VP9'ым. С весьма радующим меня соотношением битрейт-качество. Не вляпываясь в патентный рэкет, даже если сервак окажется в США (где они мощные, дешевые и бандвиза хоть залейся). И это играется более чем 50% браузеров на планете. Здесь и сейчас.

> Спецификация "MPEG4 part 2" имеет разные реализации от DivX, Xvid, Mainconcept (adobe),

Я в курсе. Спасибо, Кэп. Я лишь хотел сказать что хорошая реализация более простого мпега - легко втыкает плохой реализации более сложного и фичастого мпега. Разумеется, у хорошей реализации H.264 все карты на руках уделать более простую реализацию.

> тысячи их. В таких кодеках Level и Profile формируют набор применяемых
> алгоритмов при кодировании,

Ну и в H.264 этот набор алгоритмов более сильный (и более ресурсоемкий). Потенциально эти техники дают более хорошее соотношение битрейт/качество (ценой большего расхода ресурсов). Вот только потенциал - ничто без реализации.

Для начала - гугль например выкатывает хороший референсный энкодер. Под весьма либеральной лицензией. А что выкатывают горе-стандартизаторы? Вы их референсный кодер H.264 когда-нибудь видели? Это слезы, его xvid наверное сделает. Зато - под какой-то дурной и жлобской лицензией "посмотреть можно, но руками не трогать". Качественные реализации, типа xvid и x264 - вообще не заслуга горе-стандартизаторов. Вот я и думаю - нафига они такие нужны? К тому же я с мпег4 активно возился в эпоху когда их был легион. Скажем MS MPEG4V3 вам что-нибудь говорит? Или там div3? Там каждый дро... как хотел, перепевая ранние спеки. И я в силу большого объема информации - стал забывать и отбрасывать все эти названия и обозначения. Пусть эти горе-стандартизаторы сами в своих Mpeg 9000, part 100500 копаются. Поразвели кучу наименований, а реализаторы еще усилили бардак. Теперь кодеки на 50% состоят из воркэраундов и костылей всей этой буиты.

> поэтому, вероятно проиграются не на каждом устройстве. Чем выше уровень, тем
> мощнее устройство декодирования. Чем выше профиль тем новее ревизия спецификации.

Спасибо, я в курсе. Я просто не помню формальных обозначений. Просто потому что последние несколько лет я MPEGами не интересовался. Тем более что все эти mpeg 9000 part 100500 не очень много говорят о том какие фичи задействованы в конкретном потоке. Формальный бэджик одно, а реальное устройство потока, задействованные фичи, достигнутое соотношение битрейт/качество и прочая - таки иное.

> Устройства, заявляющие поддержку того или иного кодека, должны уточнить
> уровень и профиль в документации.

В результате оказывается что если кодировать самыми крутыми вариантами H.264, повключав всякие там CABAC (обложенный патентами как собака блохами, btw) и что там еще - половина девайсов потом такой файл еще и не сможет проиграть. И как вы понимаете, большинство юзерей в душе не е...т какой там у них профайл их девайс поддерживает.

> Справедливости ради "MPEG4 part 2" ~ "H263".

...которым в его чистом, стандартном виде вроде как почти никто и не пользовался сроду.

> уровней и профилей (простите, annex-ов, оно так называется в связь-ориентированном мире).

А я это называю "развели кластерфак". Ну то-есть совсем без этого обойтись конечно сложно, но в MP4 это все стало как-то слишком уж злобно и развелось over 9000 разных квазисовместимых полузабагованных недореализаций. Серьезные кодеки, типа ffmpeg, конечно, прокостылили это безобразие, ввинтив нетривиальные эвристики для понимания чей поток и как это костылировать и воркэраундить баги вон того энкодера. Но в результате смотреть в код таких макаронных монстров просто жутко - там костыль на костыле.

> H263 больше ориентирован на канальную передачу видеопотока,

ЧСХ, он как-то дружно оказался никому не упавшим в его чистом виде.

> Там нет никакого "суперсета фич". Есть схожие удачные алгоритмы типа Qpel
> итд, общая логика DCT и квантования.

Поэтому оно и является по смыслу суперсетом фич. Разумеется, оно несовместимое. А я разве в каком-то месте утверждал обратное?

> И чтобы не было путаницы MP4 - это такой контейнер,

А я то думал - семейство стандартов. Только мне было лень печатать "MPEG4". Те кто в курсе того что вы написали - сами допрут из контекста. А остальным это все-равно индифферентно. Я согласен что так делать не совсем хорошо, но в конце концов, и вы и док прекрасно поняли что я имел в виду.

> "MPEG4 part 7", проигрывал открытому mkv с момента создания по поддержке
> разномастных потоков и прочим плюшкам, но выигрывал в производительности на любом
> оборудовании.

А в вебе в результате закрепился упрощенный субсет матрешки aka webm.

> И кстати, Добрый Дохтур такой же как ты.

Он умный перец и в алгоритмах соображает. Подозреваю что ему тоже лень вспоминать все эти part 100500. Пусть эти стандартизаторы сами в своих талмудах копаются, особенно при таком их подходе к делу, когда разработка кодека превращается в попытку устроить всем подставу в пользу MPEG LA и сотоварищей.

> Очень просто. Метриками PSNR, SSIM

Они довольно синтетические. И как я понимаю - не учитывают динамические параметры. Тем не менее, давно известно что глаз плохо различает детали на быстро движущихся объектах. А эти метрики этот аспект не учитывают от слова "вообще", насколько я понимаю из их описаний. Тем не менее, этот фактор вполне может роялить в восприятии видеоряда живым двуногим. Ему то важна визуальная заметность артефактов сжатия, а не формальная цифирь SSIM или PSNR. При том стопкадры это круто, но для видео важнее всего восприятие в движении, с номинальной скоростью прежде всего. А хороший стопкадр - конечно, приятно. Но выбирая между так себе стопкадрами иногда vs анноящие артефакты видимые при штатном просмотре - ну вы поняли!

> или статистически путем опроса живых людей (малоэффективен
> на длинных видеопослеловательностях).

Я тут недавно провел натурный эксперимент, компреснув "зайца" 480P в 500Кбит VP9. Там выявился еще и фактор "фанатизм". Любители энного кодека норовят закрыть глаза на плохо закодированную часть и выпятить недостатки конкурента в его проблемных местах. Хе-хе :)

> Опустим, что некоторые дуралеи не видит разницу
> между кодеком и контейнером.

Я - вижу. И вполне в состоянии отличить "матрешку" снаружи от "VP9" внутри. Так что такие распальцы явно не в мой адрс.

> Xvid может быть лучше x264, а может и наоборот.

Вот конкретно так я экспериментировал довольно много. И имею заметить что xvid хороший кодек. Но x264 побить в большинстве сцен не может категорически. Поэтому в средем по больнице, если ресурсы на декодирование не жмут, можно уповать на то что x264 будет эффективнее по битрейт/качество. Конечно еще и от того кто кодирует зависит. Человек который набил руку и знает поведение кодека и его закидоны - может закодировать заурядным кодеком лучше, чем баклан, который лыка не вяжет, супернавороченынм кодеком. Но правда жизни такова что уделать много мануального внимания кодированию люди будут только в сильно некоторых случаях.

> если используем "unrestricted" то еще и от прямоты рук того, кто
> жамкает кнопки.

Особо пряморукие могут вообще пытаться очень мощно костылить слабые места кодека. Вплоть до подыгрывания при двухпроходном кодировании с ручным указанием, например, какой битрейт можно на том или ином куске. Так можно прилично подтянуть визуальное восприятие мувика, спрятав наиболее проблемные места. Но это весьма и весьма нишевое развлечение. И лично я считаю что кодек не должен сильно лажать в таких вещах и без тыкания носом. И, кстати, на мувике с зайцем у x264 и x265 случается традиционная для них лажа на титрах.

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

124. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от irinat (ok), 02-Сен-15, 22:40 
> И знает чем отличаются I, P и B кадры.

Кстати, всегда хотел узнать, чем отличаются P и B кадры в H.264. Вроде как B там может иметь от одной до 16 ссылок. Зачем там тогда вообще P слайсы?

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

126. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +2 +/–
Сообщение от mkarevemail (?), 03-Сен-15, 06:52 
i слайсы не ссылаются по времени ни на кого
p слайсы ссылаются только на предыдущие опорные кадры
b слайсы ссылаются как на предыдущие, так и на будущие опорные кадры
при кодировании b кадров необходим так называемый реордеринг - переупорядочивание кадров, который заключается в том, что порядок кодирования не соответствует порядку отображения кадров на экране
число опорных кадров не зависит от типа слайса, оно определено для всей кодируемой последовательности
Ответить | Правка | Наверх | Cообщить модератору

141. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +2 +/–
Сообщение от Аноним (-), 03-Сен-15, 20:22 
> Кстати, всегда хотел узнать, чем отличаются P и B кадры в H.264.
> Вроде как B там может иметь от одной до 16 ссылок.

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

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

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

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

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

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

164. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Аноним (-), 11-Сен-15, 16:17 
> Есть правда бонус: если декодеру не хватает времени, B-кадр можно и не
> декодировать совсем, вместо этого сразу и оперируя будущими кадрами. Декодер получает
> фору по времени а зритель видит лишь небольшое снижение плавности картинки,
> но ничего не рассыпается. В ряде I&P only так делать сложнее
> и как я понимаю там отыгрывают в основном забиванием на постпроцессинг.
> Совсем вырубить I или P кадр как я понимаю нельзя без
> риска сильного развала последовательности (на выпавший кусок будут ссылаться другие кадры
> и получится полный трэш).

Нет, между P и B в этом плане отличий нет. Последующие кадры (и P, и B) могут ссылаться на любые предыдущие (в случае P и B) и последующие (в случае B) кадры. Т.е. потеря B-кадра может повлечь развал картинки, если на этот кадр ссылаются другие кадры. Ситуацию, когда B-кадры ссылаются на другие B-кадры, называют B-pyramid.

Вместе с тем, encoder может закодировать поток так, что потеря кадра мало либо вообще никак не отразится на итоговой картинке. Всё зависит от того, как много кадров ссылается на потерянный кадр, и можно ли их тоже выкинуть без серьезных последствий. Это касается как потерь B-кадров, так и P и даже I (в h264 допускается ссылаться за пределы последнего I-кадра). Кодирование потока таким образом называют Temporal SVC, потому что битрейт потока можно менять без перекодирования за счет выбрасывания кадров верхних "слоёв", снижая fps.

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

Это было в эпоху до h264 (в тех же клонах h263, типа DivX и XviD). В h264 и в encoder'е, и в decoder'е поддерживается синхронное представление о декодированной картинке, включая постобработку (deblocking). Т.е. encoder всегда знает, насколько декодированная картинка отличается от оригинала и всегда может поддерживать степень искажений на одном уровне (если это позволяют другие ограничения, такие как максимальный битрейт, например). Это одна из причин, из-за которых encoder стал сложнее (он в обязательном поряден должен включать полноценный decoder).

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

53. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +6 +/–
Сообщение от mvgolubev (?), 02-Сен-15, 01:22 
> С OpenGL в свое время был аналогичный случай: Microsoft так же входил
> в группу разработчиков и одновременно пилил свой Direct3D.

С OS/2 в свое время был аналогичный случай: Microsoft так же входил в группу разработчиков и одновременно пилил свой Windows.

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

63. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +3 +/–
Сообщение от EHLO (?), 02-Сен-15, 09:07 
>> С OpenGL в свое время был аналогичный случай: Microsoft так же входил
>> в группу разработчиков и одновременно пилил свой Direct3D.
> С OS/2 в свое время был аналогичный случай: Microsoft так же входил
> в группу разработчиков и одновременно пилил свой Windows.

В принципе да, такой же развод.
С той лишь разницей, что OS/2 проприетарь, так что мне лично фиолетово в какую позу проприетарщик проприетарщика нагнул.

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

120. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +1 +/–
Сообщение от Аноним (-), 02-Сен-15, 18:51 
> Не стоит искать хитрый умысел там, где всё объясняется банальной глупостью.

Halloween Documents намекают нам что банальной глупостью в мелкосаксе дело все-таки не ограничивается.

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

136. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Аноним (-), 03-Сен-15, 15:46 
глупость одних вполне может использоваться в интересах других
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

20. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +4 +/–
Сообщение от нонайм (?), 01-Сен-15, 21:59 
windows as a service требует нового подхода.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

38. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  –1 +/–
Сообщение от Michael Shigorinemail (ok), 01-Сен-15, 23:37 
> windows as a service требует нового подхода.

disservice as a service?

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

118. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +1 +/–
Сообщение от Аноним (-), 02-Сен-15, 18:43 
PAAS. Pwnage As A Service.
Ответить | Правка | Наверх | Cообщить модератору

22. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +5 +/–
Сообщение от Аноним (-), 01-Сен-15, 22:47 
> У майкрософта опять какой-нибудь хитрый план, вот посмотришь.

Я подозреваю что план относительно простой и сводится к усиленному размахиванию тем фактом что они теперь тоже поддерживают новый стандарт. Куча пиара на ровном месте. Ну а что, с WebGL они прогнулись. Даже в Khronos немного вошли. Но только по части webgl. Обычный OpenGL(-ES) и прочие вулканы их вроде как не интересуют - у них же свой DX12, блаблабла. Чем они знатно подставляют своих програмеров - виндовые програмеры становятся неконкурентоспособны. Особенно на мобильных рынках, в вебе и прочая.

> В результате все свободные видеокодеки загнутся,

Что-то не помню чтобы после выхода OPUS'а остальные загнулись. А там хоть и не микософт напрямую, но все-таки скупленный ими Skype. И кажись уже после покупки. В смысле в opus от скайпа какие-то куски патентов безвозмездно отдали. Вроде пока никому ничего никто за это не предъявил, хотя появилось все это не вчера и мозилла и хром внедрили.

> лишь то, что почему-то история никого не учит, и с майкрософтом
> продолжают сотрудничать, каждый раз наступая на одни и те же грабли.

Ну они вон WelGL реализовали недавно. А какой-нибудь интель так и вовсе с MS по жизни дружил. Тем не менее, дружба дружбой но интель как-то так не стесняясь возится с линухом, имея на него большие планы.

Вообще, с развитием веба и мобильных девайсов - MS наверное уже догадался что идея вендорлока на винду с треском провалилась и работает против MS. Но вот где они еще могут нагадить - вопросец, да. Я им доверять не собираюсь - слишком уж долго они подковерные подлости всем делали.

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

33. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  –2 +/–
Сообщение от GrammarNarziss (?), 01-Сен-15, 23:13 
"Микрософт", позорище.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

35. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +3 +/–
Сообщение от EHLO (?), 01-Сен-15, 23:15 
> "Микрософт", позорище.

"Микрософт" ― позорище.

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

57. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  –1 +/–
Сообщение от Аноним (-), 02-Сен-15, 03:10 
> "Микрософт" ― позорище.

Майкрософт, позорища.

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

86. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  –2 +/–
Сообщение от Аноним (-), 02-Сен-15, 12:37 
>Майкрософт, позорища.

Некрософт, позорище.

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

112. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Аноним (-), 02-Сен-15, 18:06 
> "Микрософт", позорище.

"Майкрософт" - официальное русскоязычное название компании.

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

49. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  –4 +/–
Сообщение от Аноним (-), 02-Сен-15, 01:01 
Кругом заговоры? Так то мс тоже нужен этот кодек, а уж как кодеку нужен мс и не переоценить. Т е, даже если мс будет делать что-то не так, остальные будут вынуждены это принять.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

137. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Аноним (-), 03-Сен-15, 15:51 
ага, BeOS про заговоры расскажи
Ответить | Правка | Наверх | Cообщить модератору

69. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  –1 +/–
Сообщение от llirikemail (ok), 02-Сен-15, 10:05 
по поводу "наступают на одни и те же грабли"- вот у меня такой-же вопрос относительно американского доллара. почему в него все вкладываются?
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

88. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Аноним (-), 02-Сен-15, 12:40 
Это другое. Не вкладываться в доллар равносильно решению задачи в системе координат без системы координат.
Ответить | Правка | Наверх | Cообщить модератору

156. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +1 +/–
Сообщение от XoRe (ok), 04-Сен-15, 17:50 
> по поводу "наступают на одни и те же грабли"- вот у меня
> такой-же вопрос относительно американского доллара. почему в него все вкладываются?

Вкладываться - я так понял, вы имеете в виду покупать, а не инвестировать в него?
Ну его курс растет, а значит завтра за 1 доллар можно будет купить больше рублей, чем сегодня.
Чеб не покупать?
Будет так же расти золото, будут покупать золото.
На бирже, в принципе пофиг, что покупать, если его курс растет.
Вы бы лучше спросили, почему государство продает нефть за доллары, а не за рубли.

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

161. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  –1 +/–
Сообщение от Аноним (-), 07-Сен-15, 13:21 
покупаю доллар мы инвестируем в него, не так ли?
Ответить | Правка | Наверх | Cообщить модератору

163. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от XoRe (ok), 08-Сен-15, 19:17 
> покупаю доллар мы инвестируем в него, не так ли?

Инвестиции (англ. Investments) — размещение капитала с целью получения прибыли.
Покупая булочку в магазине, вы инвестируете в булочку?
Или в магазин?
Или в булочную?
Или в кондитерскую промышленность?)
Нет, т.к. вы не получите прибыль в будущем, вы просто получаете булочку сейчас.

Вообще, так как понятие "инвестиции" сейчас используется очень широко, то да, даже покупку валюты сейчас называют инвестицией.
Точнее, это спекулятивные инвестиции (покупка активов исключительно ради возможного изменения цены).
Но это не инвестиция в доллар, как в валюту вообще.
Это инвестиция в те доллары, которые вы схороните под кровать, или в банк.

Поэтому, покупая доллар, вы не инвестируете в него.
Вы его укрепляете.

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

9. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +2 +/–
Сообщение от soarin (ok), 01-Сен-15, 21:01 
Ну так поддержку flac и mkv в венде же добавили из коробки.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

10. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  –1 +/–
Сообщение от анонко (?), 01-Сен-15, 21:10 
> Ну так поддержку flac и mkv в венде же добавили из коробки.

Только в десятую)

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

142. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +1 +/–
Сообщение от Аноним (-), 03-Сен-15, 20:32 
> Только в десятую)

Кстати да, ад таки замерзает: M$ тихой сапой и без громкой помпы в своем Edge пилит поддержку VP9, Vorbis, webm и OPUS. Они как-то так после сабжевого анонса тихонько поменяли статус этих фич в своем загончике описывающим статус IE.

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

151. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от тоже Анонимemail (ok), 03-Сен-15, 22:28 
Просто однажды эта контора сделала программу, которую весь мир считал настоящим браузером, и теперь у них идея-фикс повторить тот успех. Пока безрезультатно.
Ответить | Правка | Наверх | Cообщить модератору

89. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Аноним (-), 02-Сен-15, 12:43 
Ага, а ещё теперь из коробки трояны и кейлоггеры. Оно и правильно - хомяки всё равно свои вендокомпы используют в основном для них.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

102. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Аноним (-), 02-Сен-15, 14:57 
Это они для себя делали, в ветку для пользователей случайно попало, как бы они иначе смотрели нелицензионный контент слитый с милионов хомячков?
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

14. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +2 +/–
Сообщение от Аноним (-), 01-Сен-15, 21:13 
от необходимости платить патентным троллям из HEVC Advance роялти за каждую копию винды
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

31. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +1 +/–
Сообщение от Crazy Alex (ok), 01-Сен-15, 23:06 
А у майкрософта - skype/linq. И кодек им нужен не меньше, чем циске.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

94. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от пох (?), 02-Сен-15, 13:02 
> Во, совсем другое дело. Давно бы так.

Так оно - давно уже так, только тот кодек назывался vp9 - и был по всем параметрам неудачным. Поэтому даже всей дурью гугля пропихнуть его не удалось - поддерживается всеми и никем не используется. Включая и самого гугля. При этом в любом случае нужен новый - под 4k и выше то что есть - неоптимально или недоработано.

> p.s. а как они микрософт то уломали? MS засцал от перспективы поддерживать
> 3 кодека в браузере? :)

MS любит платные кодеки и форматы только в одном случае - когда платят ему. Это корпорация бабла, а не абсолютного зла. Когда ему, наоборот, нужно платить за чужие патенты (того хуже - за них должны платить производители виндофонов, что плохо влияет на продажи) - он сразу начинает любить бесплатное.

При этом своих патентов в этой области у него нет, зато они есть у гугля и циски.

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

143. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Crazy Alex (ok), 03-Сен-15, 20:39 
Патенты у него какие-то есть, во всяком случае, в мпегле он состоит и что-то там получает с роялтей, хотя отдаёт другим держателям больше. Как-то так.
Ответить | Правка | Наверх | Cообщить модератору

145. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +/–
Сообщение от Аноним (-), 03-Сен-15, 20:50 
> пропихнуть его не удалось

Вообще-то удалось. Мозилла его запилила давно. Так что в сумме с хромом уже сейчас более 50% браузеров его играют. И даже MS таки пошел его запиливать. Как и WebGL. Видимо они поняли что с мобилками, планшетами и прочими смарт-ТВ они безнадежно в пролете и признали очевидное: теперь они не короли и диктаторы рынка, а всего лишь "одни из". И придется с остальными участниками рынка дружить. Иначе кина не будет. А учитывая что на HEVC вылезло уже три группы патентных троллей - так можно и вовсе без видео остаться.

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

150. "Google, Cisco, Mozilla и Microsoft объединили усилия в созда..."  +2 +/–
Сообщение от sage (??), 03-Сен-15, 21:50 
>Поэтому даже всей дурью гугля пропихнуть его не удалось - поддерживается всеми и никем не используется. Включая и самого гугля.

wut? На youtube уже, наверное, года два как используется в качестве основного для HTML5.

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

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

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




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

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