Компания
416,63
рейтинг
23 ноября 2011 в 16:29

Разное → История развития форматов видеосжатия

Далёкий 1988й год был полон удивительных событий. В этом году увидел свет 4й альбом группы Metallica «...And justice for all», а СССР запустил в свой первый и единственный полёт многоразовый космический корабль «Буран». В этом же году началась история видеосжатия – появился самый первый стандарт видео-кодека.
Самые известные стандарты видеосжатия появились благодаря двум конторам: VCEG и MPEG. Нельзя назвать их конкурентами: некоторые стандарты были выпущены комитетами поодиночке, некоторые стали плодом их запретной любви коллективной работы в составе объединённых групп. По иронии судьбы именно эти «совместные» форматы и получили наибольшее распространение.

1988 год – H.261


352x288 - предел мечтаний в 1988 годуИтак, 1988 год. H.261 стал первым полноценным форматом видеосжатия, получившим широкое распространение. Это был «классический» стандарт, работающий в цветовом пространстве YCbCr, базирующийся на дискретном косинусном преобразовании блоков и сжатии Хаффмана. Поднимите руку те, кто слышал о нём? А ведь именно в этом стандарте впервые появились такие понятия, как макро-блок, целопиксельный вектор движения и де-блокинг (или пост-процессинг). А еще именно тогда, 23 года назад, появилась концепция опорных кадров. H.261 предусматривал кадры 2х типов: I(ntra) – полностью независмый кадр, и P(redicted) – кадр, зависимый от предыдущего. Максимальное разрешение CIF (пример приведён слева), поддерживаемое H.261, сейчас не впечатлит даже любителей смотреть видео на телефоне. И тем не менее, для своего времени это был очень прогрессивный, весьма «продвинутый» стандарт. Все последующие стандарты видеосжатия базируются на идеях, берущих свое начало в H.261, и де-факто являются результатом его эволюционного развития.


1993 год – MPEG1


В 1993 появился MPEG1. Революционным нововведением в формате MPEG1 стали B(ipredicted) кадры. Т.е. кадры могли теперь предсказываться не только от предшествующего опорного кадра, но и последующего. Появились полупиксельные вектора движения, что позволило поднять точность предсказания и тем самым повысить качество. Было введено понятие «слайс» (Slice) – часть кадра (группа макроблоков), которая кодируется независимо от других слайсов. Стало возможным сжимать разные части кадра с разными параметрами, но, самое главное, в MPEG1 появилась поддержка очень больших разрешений, вплоть до 4К на 4К.
По непонятной причине, комитет MPEG выкинул из стандарта этап де-блокинга. Комитет даже не убедило существенное повышение качества, достигнутое при использовании де-блокинга в стандарте H.261. Скорее всего, решение было основано на данных о типичной производительности микропроцессоров того времени. В отличие от H.261, стандарт MPEG1 состоял из нескольких частей, описывающих всё необходимое для полноценного цифрового видео: аудио сжатие, видео сжатие, хранение и синхронизация аудио-видео данных, средства тестирования совместимости и референсный декодер для отладки.

В начале девяностых годов в компании Intel, да и вообще в компьютерной индустрии, вряд ли существовало полное понимание того, какое влияние в будущем окажет видеокодирование на архитектуру процессоров. Это много позже сжатие и разжатие цифрового видео стало коньком компании. А пока, в марте 1993, начал свою долгую жизнь один из самых известных процессоров компании Intel – Pentium. В нем не было ничего особенного для ускорения видео-обработки, разве что одинокая инструкция bsr (bit scan reverse). Эта инструкция осталась еще со времён 386го процессора и могла быть использована для ускорения декодирования Хаффмана. Производительности Pentium’а хватало, чтобы тихонько декодировать H261 формат. Но без звука :). Надеюсь, некоторые читатели еще помнят, как икал winamp, если пошевелить мышкой.

1996 год – MPEG2


1996 год. Опубликован стандарт MPEG2. Совсем скоро разойдутся по планете миллионными тиражами DVD диски, которые сделают MPEG2 первым широко распространенным форматом на многие годы. MPEG2 практически не принёс ничего нового в процесс сжатия, за исключением черезстрочного видео, поддержки нескольких форматов аудио-сжатия и дополнительных цветовых разрешений. MPEG2 не был оптимизирован для использования на маленьких (меньше 1мбит) потоках. Зато на бОльших потоках MPEG2 уверенно превосходил MPEG1, а сам стандарт разросся до 11 частей.

Pentium MMX logoВ начале 1997 года Intel начала продавать процессоры, которые уже были способны декодировать видео с приемлемой скорость. Нет, про HDTV разрешения ещё никто не мечтал, но маленькое QCIF видео процессор уже способен был проигрывать без тормозов. «Виновница» этого – технология MMX. Врядли выход стандарта MPEG2 и технологии MMX с такой маленькой разницей во времени было чистым совпадением. С большой вероятность это был, как сейчас принято говорить, продукт синэргии.

Технология MMX состояла из набора дополнительных 57 инструкций и 8 новых 8ми-байтных регистров. Существенное ускорение (до 3х-4х раз) достигалось за счёт одновременной обработки инструкцией нескольких данных. В этом плане цифровое видео стало идеальным полем для внедрения новой технологии. На MMX возлагали большие надежды, и даже поместили на официальное лого процессора.
Чуть позже в этом же году вышел процессор Pentium II, который за счёт своей суперскалярности, большого кэша, шустрой шины и нового типа памяти сделал доступным просмотр DVD на персональном компьютере.

1998 год – MPEG4


MPEG4, появившийся в 1998 году, достаточно быстро завоевал себе славу «пиратского» формата. Кодек DivX, использующий MPEG4 формат, произвёл настоящий фурор. DivX позволял с приемлемой потерей качества сжимать MPEG2 DVD диск в файл размером с CD диск. Я помню, как многие мои друзья кинулись пережимать DVD фильмы (откуда они их брали???) и делать свою личную коллекцию DivX фильмов.
Успех формата MPEG4 состоял из нескольких слагаемых: вектора движения стали четверть-пиксельными, что позволило поднять точность предсказания, макроблок мог содержать уже до 4 векторов движения, что было полезно на границе движущихся объектов, и (фанфары!) вернулся незаслуженно уволенный пять лет назад де-блокинг.
Разработчики стандарта добавили в MPEG4 ещё одну интересную вещь: intra-предсказание. Теперь макроблоки в I-кадрах могли «предсказываться» от соседних макроблоков, что существенно снижало размер intra макроблоков в кадрах со сложной, но повторяющейся структурой.
К сожалению, сам стандарт сжатия, а вернее его чрезмерные способности, не нашли горячего отклика в лице производителей кодеков. Многие прогрессивные фишки MPEG4, такие как 3D видео текстуры, несколько видеоплоскостей в кадре и прочее, остались невостребованными.

Pentium III ускоряющий интернетС другой стороны, многократно возросшая сложность декодирования опять отбросила пользователей в область маленьких разрешений. Однако, не прошло и года, как в продаже появился Pentium III, «ускоряющий Интернет». К слову, Pentium III отлично справлялся с задачами ускорения всего, не только интернета. В то время были популярными эксперименты запуска игры Quake 3 Arena на новом процессоре, который после патча системы обеспечивал значительное приращение FPS. С точки зрения видеокодирования, процессор принёс возможности программного опережающего чтения (prefetch) данных в кэш и расширял набор MMX несколькими крайне полезными инструкциями. И хотя ускорение декодирования видео было всего 20-30% по сравнению с Pentium II, этого было достаточно для комфортного просмотра MPEG4 фильмов.

Один из самых приятных процессоров для оптимизацииПриверженцы продукции Intel встречали 2000й год с особыми нетерпением. Именно на этот год был назначен выпуск нового процессора Intel Pentium 4. Это была великая интрига и великая загадка – компания готовилась полностью сменить архитектуру процессора. Архитектура NetBurst шла на смену казавшейся устаревшей архитектуры P6. И хотя общая производительность процессора слегка разочаровала фанатов, с точки зрения обработки цифрового видео процессор был на высоте. Новые инструкции и новые 16ти-байтные регистры SSE2, хитрые режимы аппаратного предсказания, большие буффера чтения/записи, новая организация кэша, а чуть позже – технология HyperThreading. Всё это вдохнуло новую жизнь в процесс оптимизации видеокодеков. Прирост производительности колебался от 10 до 35%. Процессор Pentium 4 был раздольем для экспериментов. Например, 2 инструкции, переставленные местами, могли равновероятно принести как 5% увеличения скорости работы кодека, так и 5% замедления. Процессора вполне хватало на декодирование и видео, и аудио, и еще оставалось немножко производительности на спец-эффекты. Вкладка эффектов DivX росла и ширилась, и счастливые обладатели топовых версий Pentium 4 расставляли все галочки, в надежде получить картинку «как в кинотеатре». А раз уж речь зашла о кинотеатре, то энтузиасты начали всерьез посматривать в сторону HD разрешений.

Новейшая история, год 2003 – H.264


Год 2003 можно смело назвать эпохальным годом в истории развития форматов видеосжатия: появилась альфа и омега сегодняшнего цифрового видео — стандарт H.264. Новый стандарт был полностью целочисленным, т.е. все этапы декодирования видео выполнялись в целых числах, благодаря чему была достигнута побитовая идентичность видео при декодировании декодерами разных производителей.
От предков H.264й отличался продвинутым intra-предсказанием макроблоков, различным разбиением макроблоков при компенсации движения (от 4x4 до 16x16), 6ти точечным фильтром компенсации движения, продвинутым арифметическим сжатием энтропии, наличием долго-хранящихся опорных кадров, гибким управлением опорными кадрами, 16 векторами на макроблок, всеми доступными цветовыми разрешениями, 8мью и более битами на компонент цвета и множеством других волшебных фишек. Стандарт не только оставил далеко позади всех конкурентов, но и установил новые требования к производительности процессора. Теперь, чтобы проигрывать видео в формате HD, одного процессора (даже с технологией HyperThreading) уже недостаточно.

Период 2003-2005 годов был тяжёлым для пользователей, которым не хватало производительности, но золотым временем для оптимизаторов ПО. Их услуги были на расхват! Производительность ЦПУ явно была в дефиците, и с этим надо было что-то делать. В мае 2005 решение пришло – впервые со времён процессора Pentium III многоядерность вернулась в пользовательские машины. Процессор Pentium 4 с кодовым названием Smithfield гордо нёс свои 2 ядра в массы. На самом деле, компания Intel слукавила – это были 2 «почти» обычных процессора Pentium 4, расположенные на одной подложке. Процессоры могли общаться друг с другом исключительно через шину FSB, не могли «подглядывать» соседу в кэш. Тем не менее, производительности Smithfield’а было достаточно, чтобы на лицах пользователей снова засветилась улыбка. Покупайте попкорн, занимайте места в «зрительном» зале. Только благодаря многоядерности в многолетней битве между процессорами и форматами цифрового видео наметился перелом: процессоры стали способны декодировать цифровое видео в любом формате, в любом разрешении с комфортной для зрителя скоростью. Но это был лишь выигранный бой, но не сражение.
Как мы знаем, цифровое видео можно (и нужно) не только ДЕкодировать, но и в первую очередь кодировать. А вот с этим всё было не так радужно, как того бы хотелось. Для полноценного, быстрого и качественного сжатия видео современных процессоров хватало разве что на стандартное разрешение формата MPEG2/MPEG4, не более.

Conroe принёс ностальгию по временам Pentium IIIГородок Конро на юго-востоке штата Техас был практически неизвестен до лета 2006 года, когда на прилавках магазинов стали поставляться новые процессоры компании Intel с одноимённым ядром, вернее ядрами. Дальний потомок процессора Pentium III Intel Core 2 был призван заменить процессоры на базе технологии NetBurst, и закрепить успехи видео(де)кодирования. Процессор обладал полноценными высокопроизводительными ядрами, которые могли достаточно эффективно лазить друг другу в большой кэш, и новыми инструкциями SSSE3 (3 буквы S). Среди новых инструкций было несколько ориентированных специально на кодирование видео. И хотя новые процессоры потеряли поддержку HyperThreading, они всё равно обладали такой внушительной производительностью, что сжатие HD видео в реальном времени уже не выглядело совсем непосильной задачей.

Однако, как уже было замечено, появление многоядерности принесло победу в бою, но не в сражении. Осенью 2007 года объединённая группа комитетов наносит ответный удар в виде нового профиля масштабируемого сжатия к стандарту H264 Scalable Video Coding (SVC). Сложность кодирования и декодирования возрастает в разы. Это был не полноценный стандарт, а всего лишь настройка над существующим, основная задумка которого – существенное повышение качества видео, передаваемого по сетям с потерями. Теперь в видео потоке один и тот же фильм мог храниться в разных разрешениях, и более высокие разрешения использовали более низкие в качестве опорных. У такого решения был ещё один дополнительный плюс: теперь устройства, которые не нуждалось в HD качестве фильма, могли декодировать только часть потока с необходимым разрешением.

Но ничто уже не могло поменять ситуацию в обратную сторону. Компания Intel в начале 2008 закрепляет свой успех выходом процессора на ядре Penryn с новыми инструкциями SSE4.1. Как скажут позже – это было самое большое SIMD расширение со времён процессора Pentium III. Тут были и абсолютно новые инструкции, заточенные на кодирование цифрового видео, и новые расширения для уже существующих SIMD инструкций. Кодирование HD видео в формате H264 уже уверенно движется в реальном времени с приемлемым качеством.
Вышедший в ноябре 2009 новый профиль для кодирования видео снятого с нескольких точек для формата H264 Miltiview video coding (MVC) не мог ничего изменить. Новый профиль не добавлял ничего нового, просто описывал правила и способы организации битового потока для сжатия видео снятого с нескольких камер. Не смотря на то, что производительности процессоров 2009 года не хватало, чтобы сжимать подобное видео в реальном времени, это был вопрос одного, максимум двух поколений процессоров.

Переход на встроенный контроллер памяти дал многоТак и произошло. На рынок вышел процессор с кодовым именем Nehalem, снова подаривший нам радость использования технологии HyperThreading. Среди прочих достоинств процессор нёс на себе контроллер памяти и кольцевую шину, которая более подходила для связи между большим количеством быстрых ядер, чем морально-устаревшая FSB. Процесс сжатия HD фильма в отличном качестве, который раньше занимал всю ночь, теперь пролетает за «считанные» часы. В воздухе витал дух победы. Однако, компания Intel была бы не компания Intel, если бы не поставила красивый заключительный аккорд в этой борьбе.

SandyBridge кодировал видео быстрее всех ЦПУИ он прозвучал: в январе 2011 было объявлено о начале продаж процессора на ядре SandyBridge. Кто вертел фирменную синюю коробочку упаковки процессора, наверняка заметили слова Intel Quick Sync среди списка features процессора. Именно так называется технология аппаратного сжатия видео, которая доступна каждому пользователю через Intel media SDK. За этими тремя простыми английскими словами скрывается труд десятков инженеров и программистов компании, в том числе и мой.

В 2002 году я разговаривал с одним своим коллегой насчёт оптимизации и мультимедиа-ориентированности современных процессоров (как вы помните, время господства технологии SSE2). И на какой-то мой довод коллега ответил, что процессоры станут мультимедиа-ориентированными только тогда, когда там появится инструкция idct. Могли ли мы предположить в далёком 2002, что спустя всего 9 лет жизнь оправдает гораздо более смелые планы и ожидания?

Теперь сжатие видео для любимого iPad – не проблема. HD сериал из 24 серий по 20 минут кодируется за 20 минут. Фильм на 1.5 часа кодируется за 5 минут. Больше не надо тратить своё время и оставлять компьютер включенным на ночь. Достаточно просто сходить и налить чай. Процессоры победили.

PS: На этом я хотел бы закончить своё повествование, но это было бы лукавством. В воздухе опять пахнет бурей. Дело в том, что объединенная группа комитетов разрабатывает следующий стандарт сжатия цифрового видео – High Efficiency Video Coding (HEVC). HEVC будет нести в себе лучшие качества H264 формата, но при этом будет обладать огромным количеством новых особенностей и возможностей, которые предъявят повышенные требования к ЦПУ. И борьба между стандартами видеосжатия и процессорами может выйти на новый виток. И так до бесконечности.

Upd. В предпоследнем абзаце шла речь про пересжатие HD видео для определённого гаджета — iPad. Извиняюсь, что упустил этот момент.

Upd2. Хабровчане, будем чуть дружелюбнее и рассудительнее. Я уверен, что со временем программные средства развивались, и некоторые негативные эффекты, описанные в статье, со временем прошли. Например, winamp перестал «икать» на медленных процессорах.
Автор: @victor_cherepanov
Intel
рейтинг 416,63

Комментарии (115)

  • +11
    Все же фильмы на СД дисках с надписями «DivX» и «Качество DVD» выглядели куда хуже самого DVD, но на 16" ЭЛТ мониторе это не сильно бросалось в глаза.
  • 0
    А я помню 97 год, Video CD (MPEG 1). Приходилось ставить масштаб 200%, потому что видео на полный экран мой комп ну никак не тянул…
    • +1
      Да, 352х288, как сейчас помню. :)
    • +1
      QuickView и понтовая S3Trio какраз позволяли смотреть без тормозов (QV умел както запускать S3 так, что она аппаратно растягивала изображение)
      • 0
        Ага, у меня тоже была S3 Trio 64V+ с дополнительным, вторым мегобайтом видеопамяти.
        А так как комп (Pentium 100, 16 Mb RAM) не очень тянул DivX, то я терпеливо переводил их в VideoCD (тот самый MPEG-1) на два диска вместо одного и смотрел потом в QV без тормозов, но в так себе качестве.
        На 14-дюймовом мониторе Samsung SyncMaster 3 NE этго было весьма достаточно.
        • +1
          У меня был аж Pentium 200 MMX, 128 Mb RAM, S3 Virge/VX 4mb, но DivX тянулся только с низким качеством (т.е. не все фильмы шли :) ). MPEG-1 как и MPEG-2 спасали всегда и на 14'' LG Studioworks 44i это выглядело шикарно :)
          ps этот ещё жив :)
  • +26
    Грамотно сделанный пост.
    Видишь на главной, история, скриншотик — ух как интересно.
    А дальше логотипы процессоров.
    • +14
      маркетинг такой маркетинг ;)
      • –6
        Где-то с третьего абзаца было такое чувство, что автор работает в Intel. Так и вышло.
        • +25
          То есть название блога об этом вам не намекнуло? :)
        • +2
          Помню первый раз, так сказать, Intel сильно «удивил» меня в статье про 64-разрядную архитектуру процессоров. Такой PR-щины ещё поискать =)
          • 0
            Вот именно. А на названия блогов я смотрю в последнюю очередь.
    • +7
      Мы сначала хотели поставить фотографии процессоров, но это выглядело хуже :)

      А вообще, наверное, любой пост можно назвать «маркетингом». Включая, разумеется, и этот. А особенно учитывая то, что он расположен в корпоративном блоге. Но ведь главное, — чтобы маркетинг был интересным, я ошибаюсь?

      • +1
        Фотографии процессоров куда круче!
        • 0
          Вообще-то идеально было бы сжатие одного видео разными кодеками + скрины.
          • 0
            Ну, да. Но если выбирать между логотипами процессоров и их фотографиями — я бы выбрал второе.
            • +1
              У меня на рабочем месте есть маленькая коллекция — «тот самый» Pentium 60 c пресловутой ошибкой, просто Pentium 133, Celeron 850 и Pentium D на три гигагерца. В следующем посте выложу фото.
              • +2
                Сейчас попробую вспомнить, что есть у меня… 8088й, 80286й, пару 386х, полный модельный ряд 486х, несколько Pentium (обычный, Pro, MMX, Overdrive). Есть купермайны и мендочино. Может быть, что-то из списка уже потерялось.
                Всё равно, будет здорово посмотреть.
            • 0
              изнутри)
        • 0
          <img src="" alt=«T-800 Brain Chip Processor»/>
  • +4
    Спасибо, было интересно. Но разве всё современное видео не пересчитывается, используя видеокарту?
    • 0
      А разве в современных процессорах Intel видеокарта не встроенная?
      • +1
        Тащемта, не все декодеры умеют использовать GPU. К примеру, ffdshow использует только процессор, а CoreAVC — и GPU.
      • 0
        Нет, не встроенная.
        5820K скромно намекает, что нет, видео отдельно — видеокарта отдельно. Это вообще касается серий X820K, X930K и т.д.

        Встроенная видеокарта — это для бедных и для ноутбуков.
  • 0
    Хм, я что-то делал не так, наверное, но у меня на 80486 с 8 MB ОЗУ не заикался WinAmp даже во время работы в MS Office. Правда, слушал через кодек IIS Фраухоффер. Да и видео в divx на той же машине смотрел, правда, подтормаживало оно.
    • +2
      486DX2-66 мог играть mp3 только на 22КГц и без параллельного использования других программ. 486DX4-100 уже мог играть 44КГц. На Pentium 200MMX mp3-декодеры уже ели что-то типа 5-10%.
      • 0
        Восхищен!
      • 0
        Ох, в те далекие времена составлял табличку. И данные из нее:
        80486DX2 на частоте 66 МГц. Загрузка процессора до 20% (по данным Windows 95) при прослушивании mp3-файлов до 128 кбит/с включительно. Частоту звука на выходе не помню, но вполне может быть, что и 22 кГц. А может, и 44. Если у вас есть 80486DX2, можете поэкспериментировать с кодеком Fraunhofer-Gesellschaft IIS. У меня пока что нет возможности собрать «четверку», к сожалению.
        • 0
          А, нет. Посмотрел внимательнее. 44 кГц, стерео, максимальное качество.
        • +1
          Возможно, с декодером Fraunhofer и можно было что-то воспроизвести при 20% загрузке, но у меня были Winamp и ещё какой-то плеер для командной строки, и они для 22КГц съедали почти всё.

          Кстати, AVI файлы того времени на DX2-66 воспроизводились нормально, но там был звук PCM или ADPCM и очень низкое разрешение (в том числе по цветам), к сожалению, название кодека не могу вспомнить, но он был встроенный в Windows 95.
          • +1
            Ну, у меня «четверка» долгое время была единственной рабочей машиной, вплоть до 2001го года. И до 2006го активно использовалась. Поэтому выбирать я мог. И вот что я скажу: для таких машин музыку в Windows нужно слушать через WinPlay, а в DOS — через QuickView. С помощью этого самого QuickView я смотрел на 486м «Властелина колец» в озвучке Гоблина, он еще был в divx на двух cd-дисках.

            Сам не пробовал, но знающие люди говорят, что Debian Woody или Lenny справляется неплохо с подобными задачами на «четверках».
            • +1
              Понятно. Я списал 486 в начале 1998 года, когда выбор плееров был невелик, да и те, что были, не отличались совершенством.
            • 0
              Помню винамп заикался даже на Атлон ХР при игре в ninja.
              • 0
                А вы поставьте на свеженький комп свеженький винамп с каким-нибудь безумным модулем визуализации в разрешении 4096x3072. Тоже заикаться будет, небось.
                • 0
                  Тогда было без визуализации, да и флэш, наверное, больше нагрузки на процессор давал.
                  • +3
                    Ааа, флеш… У меня из-за него брат У меня из-за него отец новый компьютер купил.
            • 0
              На Pentium100 QuickView не справлялся с показом видео. Можно было только с отключенным звуком смотреть. Под ДОСом помню еще музыкальный плеер Cubic, который умел играть в фоне, это было просто чудом.
              • 0
                От многих факторов зависит. От скорости CD-привода (в PIO-режиме некоторые из старых CD-приводов отдавали едва ли полмегабайта в секунду, что для видео может быть маловато). От кодека. Так что какие-то видео QuickView не может посмотреть, а какие-то может.
            • +2
              Программистская мысль шагнула очень далеко с тех времён, когда Pentium 120 был топовым процессором. Как в функциональной оптимизации, так и в алгоритмической. Весьма допускаю, что современное, специально подогнанное ПО может выжать из «пожилых» машин больше, чем в своё время их ровестники.
            • 0
              Да, вторая часть в гоблине с DivX — в результате за 1 час реального времени просматривается 28 минут фильма.
        • +1
          Прелесть DCT (и других преобразований Фурье) в том, что можно вносить потери не только при кодировании, но и при декодировании: достаточно просто проигнорировать часть высокочастотных коэффициентов.

          Я, например, слушал mp3 на MC68020 @14 МГц (поверженного врага можно упоминать и в блоге Intel) без математического сопроцессора. Без заиканий, да. В 8-bit mono + до безобразия урезанные «верхи». При этом на компьютере вообще больше ничего нельзя было делать.

          Так что вы оба вполне можете оказаться правы: все зависит как от оптимизированности конкретного кода, выполняющего декодирование так и от настроек, с которыми этот код работает и даже от конкретных файлов, которые проигрываются (даже если «видимые» параметры как то битность на канал и частота дискретизации вроде бы одинаковые).

          Лично мои воспоминания говорят о том, что в одной из первых массовых игр, использующих mp3 — HoMM3 (а это поголовно P1/P2 — далеко не все апгрейдились сразу после выхода новых железок) — люди вырезали эти самые mp3 и играли в полной тишине потому что звук заикался и тормозил остальную игру (ну и плюс вырезание звука и видеороликов позволяло сэкономить лишнюю сотню мегабайт на диске).
          • 0
            А с видео такой трюк прокатит?
            • 0
              Вполне. Можно выкинуть де-блокинг у неопорных кадров, декодировать не все кадрый.

              Тот же всеми почитаемый CoreAVC одно время не проходил conformance тестирование для H264. Или у них была ошибка в деблокинге, или они его отключали :)
      • 0
        Хм. А как же я слушал mp3 на трёшке? Правда под полуосью.
      • 0
        Вот тут честно не очень соглашусь.
        Amd 5x86-133-P75 (133мгц)/16Mb ram/ Winamp 2.8/ win 95 osr2.1. Mp3 возможно слушать было только в режиме 11khz/stereo/128kbit. Второй задачей можно было разьве что в вордпаде книжку читать — на пасьянс или сапер ресурсов машины не хватало вообще.
        • 0
          С чем именно Вы не согласны? Я ничего не писал про Am5x86, который ставился на 486 плату и потому был очень сильно ограничен скоростью шины и памяти по сравнению с Pentium-ом.
          en.wikipedia.org/wiki/Am5x86
          • 0
            >486DX4-100 уже мог играть 44КГц
            Не согласен с этим.
            AMD 5x86 это по сути тот-же 486 с другим множителем частоты.
            • 0
              Возможно, дело в различном софте.
  • 0
    Эх, где бы теперь достать такой древний комп и сравнить/«погонять»…
    Жаль что в своё время всю технику не оставляли, а отдавали «в хорошие руки» или же продавали.

    Пост очень понравился — спасибо Вам :)

    И, кстати, спасибо за наводку на Intel media SDK!
    • +2
      *внимание, реклама!*
      Кстати, у автора данной статьи есть коллега, который много пишет о внутренностях Media SDK в своем блоге. К нему можно обратиться с вопросами. Ну а начать рекоммендую с этого поста: «А я рыба без трусов» или «и все-таки она вертится» :)

      Ну и раз уж нас обвиняют в «маркетинге», то любопытно было бы узнать — как вы думаете, постам, подобным этому, место на хабре?
      • +3
        Отчего же нет. Пишите, конечно.
      • +4
        Спасибо за дополнительные наводки — обязательно изучу чуть позже.
        Думаю до внутренностей я не сразу доберусь)

        Насчёт же «маркетинга»…

        Лично я не считаю подобные посты маркетингом. Ну серьёзно. Это примерно то же самое что обвинять Microsoft в том, что их лого красуется при загрузке Windows :)
        Все и так отлично знают Intel и не думаю что компания нуждается в какой-либо завуалированной-в-виде-истории рекламе.

        Да и Хабр сам по себе расчитан на наличие корпоративных блогов в своей жизни, тем более что в них нередко появляются весьма интересные статьи.

        Плюс, я думаю, многим интересно новые факты и истории об одной из известнейших компаний в индустрии, тем более задающей «ритм» ИТ жизни. Так что не обращайте внимание на таких людей — они во всём и везде видят лишь маркетинг и «злой умысел» — и продолжайте писать! :)
        • +4
          Спасибо, бальзам на душу. Ваши оценки очень стимулируют авторов. Будем стараться делать больше технических постов и меньше маркетингового мусора.
      • +2
        Ничего плохого не вижу в таком маркетинге. Топик весьма познавательный, и не суть, что он написан сотрудником Intel. Совсем не плохо, что рассказывается про решения от Intel в области работы с видео.

        От себя скажу. Связки Intel C2D E8400 + Nvidia 8800GTS для любого HD1080 видео будет хватать ещё очень надолго. Не процессорами едиными, как говорится.
        • 0
          Хватать-то оно хватает, но электричества такая связка съест в разы (это если оптимистично) больше, чем простой, но современный процессор со встроенным видеоядром, на «голой» материнской плате. И, если электричество дорогое (см. Европа), то апгрейд окупится достаточно быстро.

          От себя, по традиции :). Заменил в медиацентре Е5300 + Radeon 4670 на Pentium G620 и счета уменьшились настолько, что срок окупаемости получился порядка 12 месяцев. А через 2 года буду снова смотреть, появилось ли что-то эффективнее. Возможно, тогда будут ARM-системы, которые будут тянуть задачи медиацентров и качалок, кто знает?
  • –2
    Статья была бы просто отличная, если бы не одно «но»: полное отсутствие информации о процессорах AMD, ARM, роли видеокарт, CUDA.
    • +6
      эт ж интел, кэп)
      никто не заперащет адм взять и написать статью какую роль они внесли в какую-либо область.
    • +4
      Ограничения формата блога. Ничего не могу поделать :)
  • 0
    А почему забыли про H.263? Ведь собственно в нём появился деблокинг, встроенный в цикл кодирования, а не в H.261-м, как Вы написали.
    • 0
      MPEG4 ASP, о котором они написали, практически тоже самое, что и H.263, разве нет?
      • 0
        Что-то не нашел в статье упоминания MPEG-4 ASP ) Под ASP подразумевают обычно Advanced Simple Profile. MPEG-4 включает в себя Simple Profile H.263-го (без inloop deblocking) когда в заголовках кадров указана метка short_video_header.
        По деблокингу: существует большая принципиальная разница в использовании деблокинга в MPEG-4 и H.263/H.264. В MPEG-4 он не участвует в цепочке кодирования, а может лишь опционально использоваться декодером в качестве постфильтрации для уменьшения эффекта блочности, возникающего из-за квантизации DCT-коэффициентов, особенно на низких битрейтах. В H.263 и H.264 деблокинг встроен в цепочку кодирования, т.е. предсказания производятся от «деблокированного» кадра, что уменьшает ошибку предсказания и, как следствие, уменьшает количество информации для кодирования DCT коэффициентов. Это особенно эффективно на низких и очень низких битрейтах.
  • +2
    А WebM ничего не привнёс нового, разве?
    • 0
      Он, видимо, пока ещё не вошёл в «историю» :)
      • +1
        Ну там целая плеяда кодеков, начиная с TrueMotion-S (1995), и кончая VP8, используемым в WebM
        • +1
          Да, кодеков было больше, чем описано в статье. Было бы слишком длинно останавливаться на всех.
          С точки зрения производительности/качества WebM не принёс ничего слишком запоминающегося. Это хороший специализированный кодек для сети. Вряд ли он шагнёт дальше сети в ближайшее время.
    • 0
      нет, в нём вообще считай ничего нового кроме того, что он разрабатывался не открытым коммитетом, а закрытой тусовочкой.
  • 0
    А что за инструкция idct? Можно поподробнее?
    • +2
      Inverse discrete cosine transform — обратное дискретное косинусное преобразование.
      DCT используется при кодировании JPEG/MPEG/Theora, например.
  • +1
    Давненько так развернуто не читал по теме :) Спасибо доставило.
    • +4
      Простите, вы упустили пару вещей.
      Держите: «,» и «удовольствие».
      Не за что!
  • +2
    >Теперь сжатие видео – не проблема. HD сериал из 24 серий по 20 минут кодируется за 20 минут. Фильм на 1.5 часа кодируется за 5 минут.

    Что это за феерическая хуита? Нет, ну правда.
    У вас «HD сериал» кодируется со скоростью 24*20*24/20=576 кадров в секунду?
    «Фильм на 1.5 часа» на скорости 1.5*60*24/5=432 кадра в секунду?

    Какое вырвиглазное мыло должно быть на выходе, чтобы кодировать на 2 порядка быстрее, чем это делают все нормальные люди? И под «два порядка» я имею в виду то, что говорю.В данный момент кодирую исходник 1080p@24 с исходным битрейтом 6 в мегабит на скорости 7 кадров в секунду(x264 --preset veryslow), максимальный fps, который выдал x264 --preset ultrafast равен 128 кадрам в секунду. Процессор i2500k@4.6GHz, практически лучшее, что можно сегодня купить у Интела.

    Прежде чем переводить/перепечатывать маркетинговую хуиту, проверьте приводимые элементарно проверяемые факты, выраженные в числах.
    • +2
      Я не маркетолог, я разработчик. Тут накладка вышла. На входе было HD видео, на выходе — видео для iPad. Всё остальное верно.
      • +5
        С произвольным даунскейлом можно получить произвольный результат на произвольном железе.
    • +2
      Правило #9: Хабр — для спокойных людей. Просим оставить хамство, грубость, мат, прочие проявления агрессии и неадекватности для других ресурсов — на Хабре это не в почёте.
  • 0
    некоторые читатели еще помнят, как икал winamp, если пошевелить мышкой
    Помню на 486 процессоре (помоему частота была то ли 80 то ли 100МГц) воспроизведение музыкального файла с частотой дискретизации 22КГц проходило нормально, а при попытке вопсроизвести с частотой 44КГц — воспроизведение захлебывалось.
    При этом Pentium с частотой 60МГц — музыкальный файл с 44КГц проигрывал хорошо. Это было явным доказательством более высокой производительности.
  • 0
    Кроме восхваленного интела на рынке были
    1. аппаратные декодеры mpeg1
    2. аппаратные декодеры mpeg2
    3. gpu с cuda/opencl, выполняющие роль аппаратного декодера, на порядки более быстрого, чем процессор.

    В частности, я прекрасно смотрел mpeg1 на pentium 133, а hd-видео прекрасно смотрю, не нагружая процессор и на 10%.
    • 0
      Стоит заметить что 1 и 2 не были доступны широкому кругу пользователей. Максимум, что они могли использовать — аппаратные средства своих графических адаптеров. Там были свои недостатки.
      Cuda/openCL — достаточно свежие разработки, в 2006 про них ничего не было слышно. И если nVidia пытается продвигать свои продукты, то AMD, которая тоже имеет свою технологию аппаратного кодирования Stream,… Не будем о грустном.
      • 0
        Тащемта, OpenCL разработали в Apple. Потом пришла ATI, и только потом — nVidia, вместе с кучей других людей, из которых в итоге вышла Chronos.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Core i7 — 2600S.
      Ещё раз заострю внимание, что сжимался HD фильм в iPad разрешение аппаратным средствами встроенного графического ядра процессора…
  • 0
    Спасибо, интересно.

    «Надеюсь, некоторые читатели еще помнят, как икал winamp, если пошевелить мышкой» — AMD K5-90, винамп в бэкграунде, снаружи среда разработки, ничего не икало. Что я делал не так?

    «Pentium III, «ускоряющий Интернет»» — да, редкостное было рекламное позорище. Правда, хомячки наверняка хавали.

    «Теперь, чтобы проигрывать видео в формате HD, одного процессора (даже с технологией HyperThreading) уже недостаточно» — смотрел без тормозов 720p на AthlonXP 3000+. Что же я снова делал не так?
    • +2
      Как я уже отмечал в комментариях, что со временем программные средства шагнули вперёд, и сейчас, допускаю, winamp больше не икает на слабых компьютерах (уточните ещё ОС, пожалуйста).

      Pentium III действительно ускорял интернет. Врочем, как и Word и Winamp — за счёт более шустрой системной шины.

      Хотя Athlon 3000+ достаточно мощный процессор, как Вы понимаете, здесь всё зависит от формата сжатия и битрейта. 720p MPEG2 — без проблем. 720p CABAC H264 — терзают меня смутные сомнения.
      • 0
        winamp больше не икает на слабых компьютерах (уточните ещё ОС, пожалуйста)
        Это было в конце прошлого века. Соответственно, винамп старый, ОС — Win95SR2. Процессор AMD :-)

        Pentium III действительно ускорял интернет. Врочем, как и Word и Winamp — за счёт более шустрой системной шины
        Ой-вэй, системная шина 100MHz появилась еще на K6-2. Но каким образом более высокая частота системной шины влияла на скорость передачи данных — решительно непонятно. Хотя если для Вас «интернет» равняется «иконке на рабочем столе с буквой е», то таки да, ускорял ;-)

        720p CABAC H264 — терзают меня смутные сомнения
        Что такое «кабак», я не знаю. Речь идет про 720p XVid и 720p H264 через CoreAVC. WMV, понятное дело, работало черти как. Причем речь не про K8, а про K7.
        • 0
          На Pentium-120 и такой же ОС у меня винамп икал. Возможно, здесь имели место быть и другие факторы.

          Речь в статье идёт про продукцию компании Intel.
          Системная шина во времена Pentium II/III была единственным связующим звеном между процессором и памятью. Соответственно, увеличение частоты системной шины вело к ускорению обмена данными между двумя этими устройствами. Рекламная компания 1999 года была разработана на Западе, с учётом западных пользователей, где скорость подключения корпоративного (а зачастую и домашнего) интернета уже не была узким местом при навигации в сети. Узким местом было декодирование JPEG и рендеринг HTML страниц. Pentium III устранил как раз узкое место. Страницы реально стали отображаться быстрее.

          Xvid — это MPEG4 ASP кодек. Часто, в целях совместимости, фильмы кодировались этим кодеком с использованием весьма ограниченного набора параметров, что упрощало процесс сжатия/расжатия.
          H264 от CoreAVC — это уже H264 кодек, но опять же надо смотреть, как был сжат фильм. Очень часто для упрощения использовался только Baseline профиль, поэтому нельзя сказать, что 720p спокойно декодировался на Вашей машине.
          CABAC — это арифметическое сжатие энтропии (остаточных коэффициентов), которое пришло на смену Хаффману. Сейчас почти все фильмы в сети сжимают именно с помощью CABAC'а, т.к. он даёт существенное повышение качества сжатие, по сравнению с VLC. Недостатком этого метода является более высокие требования к вычислительной мощи процессора.

          С другой стороны, производительность WMV даёт какие-то намётки на скорость работы. Полноценное разжатие H264го (CABAC, четверть-пиксельное предсказание, B-кадры, мелкие разбиения макроблока, де-блокинг) работает медленнее, чем WMV. Хотя, даже здесь возможны варианты.
          • 0
            «Системная шина во времена Pentium II/III была единственным связующим звеном между процессором и памятью»
            Оно так в продукции Интел было вплоть до недавнего времени.

            «Страницы реально стали отображаться быстрее»
            Не могу понять, Вы технический работник или рекламный?

            «поэтому нельзя сказать, что 720p спокойно декодировался на Вашей машине»
            Очевидно, он декодировался святым духом.

            «производительность WMV даёт какие-то намётки на скорость работы»
            Производительность WMV всегда была отвратной на фоне прочих.
            • 0
              Полностью технический.
              Т.е. Вы не верите, что на скорость рендеринга HTML страниц может оказывать скорость шины процессора?

              Само разрешение 720p — ни есть показатель. Как Вы понимаете, просто копировать память на AthlonXP 3000+ можно со скоростью 2666MBs / (1280х720x1.5) = 1928 fps. Это ни о чём не говорит. Как и слова «у меня игрался фильм». В своих словах «процессора с HT было недостаточно» я имел ввиду, что процессора с HT было недостаточно для проигрывания фильма сжатого с вменяемым битрейтом с любой комбинацией использованных фич. Никто не будет покупать программный декодер, если на нём написано «проигрывает H264 720p на Pentium III», а внизу маленькими буквами «только базовый профиль, I/P кадры, без деблокинга». Всех интересует возможность проигрывания всего безобразия, разрешённого стандартом.

              Если Вы мне пришлёте кусочек фильма, то я с удовольствием его расковыряю и скажу, как он был сжат. Впрочем, Вы можете сделать это и сами — в сети полно программных средств для определения характеристик сжатых фильмов.
      • 0
        В целом — спасибо, было интересно. Но не удержался таки, вставлю свои пять копеек.

        Вы, уважаемый автор, к сожалению, изредка ошибаетесь. Winamp действительно не «икал» на 486-х (W95) и тем паче на любых пентиумах (оси W95, W98). Это первая погрешность. А вот если поставить на это же железо «шагнувшие вперед» программные средства (ME 2000 XP 2003 и +), то не то что винамп, даже блокнот икать будет — и это вторая погрешность (уже в комментариях). Аппаратные кодеры и декодеры были, и причем довольно доступные (плату видеозахвата еще до VIVO в видеокартах я помнится покупал баксов за 50, через неё гонялся контент, и в, и из) — третья. Ускорение Интернета на PIII — гм…

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

        А статья, на самом деле, замечательная. Правда.
        • 0
          50 долларов в каком году? В 2000 и 2011 это весьма разные 50 долларов :).

          Про ускорение интернета я ответил в комментарии выше. Pentium III действительно ускорял интернет :)
    • +2
      H.264 на AthlonXP 3000+? Что, правда?
      • +1
        Истинная. Или вы сомневаетесь?
      • 0
        H.264 на Celeron M 900 мГц CoreAVC идет.
        • 0
          В стандарте H264 много профилей и фич, большинство из которых — неподъёмная задача для этого процессора. Другое дело, если включена поддержка декодирования на графическом адаптере. Но тогда процессор здесь не причём.
          • 0
            Я думаю тут дело в CoreAVC, он каким-то образом некоторые фичи намеренно не использует на старых процессорах, так как у меня на нетбуке видеокарты нету не считая древнего интеловского адаптера встроенного в 945й чип.
  • 0
    sandybridge процессоры действительно фантастический прорыв. На наших задачах почти двухкратное ускорение по сравнению с core 2.

    Компьютеры за 10 тыс рублей с мощнейшими Core i5 ставят под вопрос целесообразность вложений в Cuda =)

    Только вот про Quick Sync непонятно. Где можно увидеть пример _работающего_ приложения, пользущегося этой технологией и сравнимого по качеству результата с libx264?
    • 0
      Для многих, к сожалению, разницы никакой из-за того, что пока AVX регистры работают только с плавучкой. Но приятно слышать, что у кого-то двухкратный прирост. Вот выйдет Haswell… :)

      Кстати там ещё будут FMA инструкции, так что плавучку можно будет ещё сильнее ускорить.
    • 0
      Большинство производителей программ для сжатия (Roxio, Corel, ArcSoft и т.д.) уже добавили поддержку Quick Sync в свои приложения. Более того, обычно программы с поддержкой новых технологий Intel выходят или раньше самих процессоров, или одновременно с ними. Это результат работы программы ранней адаптации компании.

      Для конечного пользователя это выглядит, как значительное повышение скорости перекодирования при запуске на новом железе.
      • 0
        я ориентируюсь на самую авторитетную лабораторию: compression.ru/video/codec_comparison/h264_2011/
        • +1
          Это известные ребята, мы с ними работаем.
          К сожалению, не увидел в статье даты, когда она была написана. Возможно просмотрел. И, насколько я понял, они измерили только качество, скорость не измеряли.
  • 0
    Вообще-то, 8 регистров MMX не такие уж и новые. Это части регистров сопроцессора. Поэтому нельзя одновременно использовать инструкции MMX и операции с дробными числами.
  • 0
    > В начале 1997 года Intel начала продавать процессоры, которые уже были способны
    > декодировать видео с приемлемой скорость. Нет, про HDTV разрешения ещё никто не мечтал,
    > но маленькое QCIF видео процессор уже способен был проигрывать без тормозов.
    > «Виновница» этого – технология MMX.

    Вы лукавите и сильно преуменьшаете производительность тогдашних процессоров.
    Под DOS и OS/2 плеер QV на PI-166MMX/Socket7 разогнанном до 200 без всяких тормозов проигрывал mpeg4 512 x 3xx с битрейтом 500-700кбс. AMD K6 200-300Мгц и подавно.
    При этом надо было иметь еще карточку от S3, которая поддерживала аппараратный scaling, иначе на полный экран не развернуть или развернуть с тормозами.

    Виндовый медиаплейр не играл на таком железе, согласен. Но это не единственная программа, не так ли.
    • 0
      В момент выхода стандартов обычно всегда производительности было мало. С ходом времени код кодеков «допиливался» для более ранних процессоров, что позволяло проигрывать без тормозов НЕКОТОРЫЕ фильмы, сжатые с использованием ограниченного набора параметров. Почему нет.
  • 0
    Спасибо, Ты меня вдохновил на написание подобной истории про 3d графику :)
    Но меня очень удивил прирост производительности от MMX в 3-4 раза. я могу поверить только в 2, для остального нужны пояснения :)
    • 0
      Многие вдохновились! Заходите, пишите :)
    • 0
      В 2 раза понятно почему, и еще избавились от возни с Х87 стековой машиной. На сингл флотах в 3 раза могло быть.
    • 0
      В некоторых задачах MMX давал и больший прирост.

      В большинстве своём, в процессе декодирования внутри кодеков используется тип short int. В ММХ регистр влазит 4 short'а. Т.е. по инструкциям add/sub должен быть прирост 4х, на практике достигается примерно 3х или чуть больше.

      Если надо было сложить два short'а, проверить на переполнение и привести результат к диапазону байта (от 0 до 255), то на генеральных регистрах это вообще туча инструкций. А на MMX всего две: сложение и запаковка short в byte. Обе быстрые и короткие.

      Ну и так далее :)
  • +3
    >Это много позже сжатие и разжатие цифрового видео стало коньком компании Intel.
    Спасибо, посмеялся.

    У вас так и не появилась инструкции idct. Ваши инструкции поиска векторов MPSADBW and PHMINPOSUW работают медленнее программных функций в x264, и разработчик x264 Dark Shikari открыто матюгается в вашу сторону, потому что вы ни разу не спрашивали какие инструкции реально нужно добавить для повышения производительности.
    А ваш QuickSync был очень ожидаем, ведь была вероятность что вы дадите разработчикам кодеков доступ ко внутренним быстрым функциям, как немного обещали. Но нет же, вы никого не послушали и выпустили только свою обёртку, закрыв доступ к низкоуровневым функциям этого сопроцессора. Да, получилось быстро, но качество на уровне --superfast, годиться лишь для временных файлов и быстрого кодирования для мобильных устройств, но не для архивации или дистрибъюции. А x264 вынужден продолжать дальше считать всё на CPU.

    «Dark Shikari, the lead developer of X264, has hinted that there are aspects of QuickSync that would greatly speed up the X264 rendering time if Intel gave them low level access to the API (not the high level SDK, which is useless for any software renderer). Basically there are certain operations that X264 could send to QuickSync instead of sending them to the CPU that QuickSync would handle much faster. However, Intel has made little to no indications they are open to opening QuickSync up. It is really too bad for Intel, they are simply losing out on an incredible opportunity to make their chips more attractive.»
    • 0
      Не надо смеятся. Достаточно взглянуть на специализированные форумы, где люди подбирают себе машины для видео редактирования/сжатия.

      Смотря какие функции, и как они реализованы. Врядли кто-нибудь способен написать функцию, которая считает 8 сумм абсолютных разностей за 4 такта. Именно столько работает инструкция MPSADBW. Вы до сих пор считаете, что их функции работают быстрее?
      То, что у них не получилось использовать эти инструкции в своих функциях, ещё не говорит, что функции быстрые, а инструкции бесполезные.

      По остальным вопросам — в отдел планирования, я — лишь разработчик.

      По личному опыту скажу, что я регулярно заливаю перед поездками видео на iPad, и скорость, с которой это происходит на SandyBridge — для меня главное. Я не пользуюсь --superfast настройкой, пользуюсь только --balanced. Визуальных артефактов не замечаю, видео после просмотра стираю.
      • 0
        Виктор, я не спорю, для временного просмотра QuickSync это находка, сконвертировал, посмотрел, удалил.
        Речь о более серьёзном применении, которого пока нет.

        О MPSADBW — forum.doom9.org/showpost.php?p=1474908&postcount=2:
        MPSADBW is useless. It can only be used to calculate a set of adjacent neighboring SADs, something that's only useful in an exhaustive search. x264 uses an exhaustive search algorithm (on sse2) that is much faster than mpsadbw.
        А как хотелось бы наоборот, чтобы аппаратный exh search был по скорости быстрее программного hex search:
        • –1
          Диджей, вы, я вижу, довольно глубоко разбираетесь в теме. Предположу даже, что ваша работа как-то связана с видеокодированием. Если вам нужна какая-нибудь фича — сформулируйте формальный запрос в форуме Media SDK! Еще раз ссылаться на парней из x264 большого смысла нет, — мы прекрасно знаем все их пожелания. Скажу даже больше, к ним уже выехали специальные люди ;).

          Работа «простых» девелоперов строится исходя их приоритетов, продиктованных либо ключевыми, либо типовыми заказчиками. Единственный способ сделать наш мир чуточку лучше — открыто высказывать свои обоснованные требования в правильном месте.

          Спасибо за понимание :)
        • 0
          Когда-нибудь компания Intel (возможно) откроет доступ к своему внутреннему железу для независимых разработчиков, и тогда все будут счастливы. Я думаю, что x264 парни нашли бы там всё, что их интересует.

          К сожалению, если это и случится, то не ближайшие год-два точно. Это вопросы уже высшего менеджмента, это не ко мне.
  • 0
    Наверное нужно было как-то кратко на пальцах еще рассказать принципы кодирования/декодирования видео, в чем там самая сложность и т.д. Ато с таким упоением рассказывается как все клево сделали, но я вот незнаю что такое «intra-предсказание» и «полупиксельные вектора», поэтому масштаб успеха оценить могу с трудом =)
    • 0
      Да, согласен, статья требует наличия каких-то базовых знаний. У меня есть коллега, который как раз пишет на эти темы, я спрошу его, не хочет ли он написать подробнее про базу видео-кодирования.
  • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    Жаль нету «Я ненавижу компанию», хочется исключить такие обманные посты из хабраленты…
    • +2
      В чём обман? Выражайтесь полнее.

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

Самое читаемое Разное