The OpenNET Project / Index page

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

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


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

Оглавление

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

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


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ообщить модератору

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

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




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

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