Комментарии 115
НЛО прилетело и опубликовало эту надпись здесь
А я помню 97 год, Video CD (MPEG 1). Приходилось ставить масштаб 200%, потому что видео на полный экран мой комп ну никак не тянул…
НЛО прилетело и опубликовало эту надпись здесь
QuickView и понтовая S3Trio какраз позволяли смотреть без тормозов (QV умел както запускать S3 так, что она аппаратно растягивала изображение)
Ага, у меня тоже была S3 Trio 64V+ с дополнительным, вторым мегобайтом видеопамяти.
А так как комп (Pentium 100, 16 Mb RAM) не очень тянул DivX, то я терпеливо переводил их в VideoCD (тот самый MPEG-1) на два диска вместо одного и смотрел потом в QV без тормозов, но в так себе качестве.
На 14-дюймовом мониторе Samsung SyncMaster 3 NE этго было весьма достаточно.
А так как комп (Pentium 100, 16 Mb RAM) не очень тянул DivX, то я терпеливо переводил их в VideoCD (тот самый MPEG-1) на два диска вместо одного и смотрел потом в QV без тормозов, но в так себе качестве.
На 14-дюймовом мониторе Samsung SyncMaster 3 NE этго было весьма достаточно.
Грамотно сделанный пост.
Видишь на главной, история, скриншотик — ух как интересно.
А дальше логотипы процессоров.
Видишь на главной, история, скриншотик — ух как интересно.
А дальше логотипы процессоров.
маркетинг такой маркетинг ;)
Где-то с третьего абзаца было такое чувство, что автор работает в Intel. Так и вышло.
То есть название блога об этом вам не намекнуло? :)
Помню первый раз, так сказать, Intel сильно «удивил» меня в статье про 64-разрядную архитектуру процессоров. Такой PR-щины ещё поискать =)
Мы сначала хотели поставить фотографии процессоров, но это выглядело хуже :)
А вообще, наверное, любой пост можно назвать «маркетингом». Включая, разумеется, и этот. А особенно учитывая то, что он расположен в корпоративном блоге. Но ведь главное, — чтобы маркетинг был интересным, я ошибаюсь?
А вообще, наверное, любой пост можно назвать «маркетингом». Включая, разумеется, и этот. А особенно учитывая то, что он расположен в корпоративном блоге. Но ведь главное, — чтобы маркетинг был интересным, я ошибаюсь?
Фотографии процессоров куда круче!
Вообще-то идеально было бы сжатие одного видео разными кодеками + скрины.
<img src="
" alt=«T-800 Brain Chip Processor»/>
" alt=«T-800 Brain Chip Processor»/>
Спасибо, было интересно. Но разве всё современное видео не пересчитывается, используя видеокарту?
А разве в современных процессорах Intel видеокарта не встроенная?
Тащемта, не все декодеры умеют использовать GPU. К примеру, ffdshow использует только процессор, а CoreAVC — и GPU.
Нет, не встроенная.
5820K скромно намекает, что нет, видео отдельно — видеокарта отдельно. Это вообще касается серий X820K, X930K и т.д.
Встроенная видеокарта — это для бедных и для ноутбуков.
5820K скромно намекает, что нет, видео отдельно — видеокарта отдельно. Это вообще касается серий X820K, X930K и т.д.
Встроенная видеокарта — это для бедных и для ноутбуков.
Хм, я что-то делал не так, наверное, но у меня на 80486 с 8 MB ОЗУ не заикался WinAmp даже во время работы в MS Office. Правда, слушал через кодек IIS Фраухоффер. Да и видео в divx на той же машине смотрел, правда, подтормаживало оно.
486DX2-66 мог играть mp3 только на 22КГц и без параллельного использования других программ. 486DX4-100 уже мог играть 44КГц. На Pentium 200MMX mp3-декодеры уже ели что-то типа 5-10%.
Восхищен!
Ох, в те далекие времена составлял табличку. И данные из нее:
80486DX2 на частоте 66 МГц. Загрузка процессора до 20% (по данным Windows 95) при прослушивании mp3-файлов до 128 кбит/с включительно. Частоту звука на выходе не помню, но вполне может быть, что и 22 кГц. А может, и 44. Если у вас есть 80486DX2, можете поэкспериментировать с кодеком Fraunhofer-Gesellschaft IIS. У меня пока что нет возможности собрать «четверку», к сожалению.
80486DX2 на частоте 66 МГц. Загрузка процессора до 20% (по данным Windows 95) при прослушивании mp3-файлов до 128 кбит/с включительно. Частоту звука на выходе не помню, но вполне может быть, что и 22 кГц. А может, и 44. Если у вас есть 80486DX2, можете поэкспериментировать с кодеком Fraunhofer-Gesellschaft IIS. У меня пока что нет возможности собрать «четверку», к сожалению.
А, нет. Посмотрел внимательнее. 44 кГц, стерео, максимальное качество.
Возможно, с декодером Fraunhofer и можно было что-то воспроизвести при 20% загрузке, но у меня были Winamp и ещё какой-то плеер для командной строки, и они для 22КГц съедали почти всё.
Кстати, AVI файлы того времени на DX2-66 воспроизводились нормально, но там был звук PCM или ADPCM и очень низкое разрешение (в том числе по цветам), к сожалению, название кодека не могу вспомнить, но он был встроенный в Windows 95.
Кстати, AVI файлы того времени на DX2-66 воспроизводились нормально, но там был звук PCM или ADPCM и очень низкое разрешение (в том числе по цветам), к сожалению, название кодека не могу вспомнить, но он был встроенный в Windows 95.
Ну, у меня «четверка» долгое время была единственной рабочей машиной, вплоть до 2001го года. И до 2006го активно использовалась. Поэтому выбирать я мог. И вот что я скажу: для таких машин музыку в Windows нужно слушать через WinPlay, а в DOS — через QuickView. С помощью этого самого QuickView я смотрел на 486м «Властелина колец» в озвучке Гоблина, он еще был в divx на двух cd-дисках.
Сам не пробовал, но знающие люди говорят, что Debian Woody или Lenny справляется неплохо с подобными задачами на «четверках».
Сам не пробовал, но знающие люди говорят, что Debian Woody или Lenny справляется неплохо с подобными задачами на «четверках».
Понятно. Я списал 486 в начале 1998 года, когда выбор плееров был невелик, да и те, что были, не отличались совершенством.
Помню винамп заикался даже на Атлон ХР при игре в ninja.
На Pentium100 QuickView не справлялся с показом видео. Можно было только с отключенным звуком смотреть. Под ДОСом помню еще музыкальный плеер Cubic, который умел играть в фоне, это было просто чудом.
Программистская мысль шагнула очень далеко с тех времён, когда Pentium 120 был топовым процессором. Как в функциональной оптимизации, так и в алгоритмической. Весьма допускаю, что современное, специально подогнанное ПО может выжать из «пожилых» машин больше, чем в своё время их ровестники.
Да, вторая часть в гоблине с DivX — в результате за 1 час реального времени просматривается 28 минут фильма.
Прелесть DCT (и других преобразований Фурье) в том, что можно вносить потери не только при кодировании, но и при декодировании: достаточно просто проигнорировать часть высокочастотных коэффициентов.
Я, например, слушал mp3 на MC68020 @14 МГц (поверженного врага можно упоминать и в блоге Intel) без математического сопроцессора. Без заиканий, да. В 8-bit mono + до безобразия урезанные «верхи». При этом на компьютере вообще больше ничего нельзя было делать.
Так что вы оба вполне можете оказаться правы: все зависит как от оптимизированности конкретного кода, выполняющего декодирование так и от настроек, с которыми этот код работает и даже от конкретных файлов, которые проигрываются (даже если «видимые» параметры как то битность на канал и частота дискретизации вроде бы одинаковые).
Лично мои воспоминания говорят о том, что в одной из первых массовых игр, использующих mp3 — HoMM3 (а это поголовно P1/P2 — далеко не все апгрейдились сразу после выхода новых железок) — люди вырезали эти самые mp3 и играли в полной тишине потому что звук заикался и тормозил остальную игру (ну и плюс вырезание звука и видеороликов позволяло сэкономить лишнюю сотню мегабайт на диске).
Я, например, слушал mp3 на MC68020 @14 МГц (поверженного врага можно упоминать и в блоге Intel) без математического сопроцессора. Без заиканий, да. В 8-bit mono + до безобразия урезанные «верхи». При этом на компьютере вообще больше ничего нельзя было делать.
Так что вы оба вполне можете оказаться правы: все зависит как от оптимизированности конкретного кода, выполняющего декодирование так и от настроек, с которыми этот код работает и даже от конкретных файлов, которые проигрываются (даже если «видимые» параметры как то битность на канал и частота дискретизации вроде бы одинаковые).
Лично мои воспоминания говорят о том, что в одной из первых массовых игр, использующих mp3 — HoMM3 (а это поголовно P1/P2 — далеко не все апгрейдились сразу после выхода новых железок) — люди вырезали эти самые mp3 и играли в полной тишине потому что звук заикался и тормозил остальную игру (ну и плюс вырезание звука и видеороликов позволяло сэкономить лишнюю сотню мегабайт на диске).
Хм. А как же я слушал mp3 на трёшке? Правда под полуосью.
Вот тут честно не очень соглашусь.
Amd 5x86-133-P75 (133мгц)/16Mb ram/ Winamp 2.8/ win 95 osr2.1. Mp3 возможно слушать было только в режиме 11khz/stereo/128kbit. Второй задачей можно было разьве что в вордпаде книжку читать — на пасьянс или сапер ресурсов машины не хватало вообще.
Amd 5x86-133-P75 (133мгц)/16Mb ram/ Winamp 2.8/ win 95 osr2.1. Mp3 возможно слушать было только в режиме 11khz/stereo/128kbit. Второй задачей можно было разьве что в вордпаде книжку читать — на пасьянс или сапер ресурсов машины не хватало вообще.
С чем именно Вы не согласны? Я ничего не писал про Am5x86, который ставился на 486 плату и потому был очень сильно ограничен скоростью шины и памяти по сравнению с Pentium-ом.
en.wikipedia.org/wiki/Am5x86
en.wikipedia.org/wiki/Am5x86
Эх, где бы теперь достать такой древний комп и сравнить/«погонять»…
Жаль что в своё время всю технику не оставляли, а отдавали «в хорошие руки» или же продавали.
Пост очень понравился — спасибо Вам :)
И, кстати, спасибо за наводку на Intel media SDK!
Жаль что в своё время всю технику не оставляли, а отдавали «в хорошие руки» или же продавали.
Пост очень понравился — спасибо Вам :)
И, кстати, спасибо за наводку на Intel media SDK!
*внимание, реклама!*
Кстати, у автора данной статьи есть коллега, который много пишет о внутренностях Media SDK в своем блоге. К нему можно обратиться с вопросами. Ну а начать рекоммендую с этого поста: «А я рыба без трусов» или «и все-таки она вертится» :)
Ну и раз уж нас обвиняют в «маркетинге», то любопытно было бы узнать — как вы думаете, постам, подобным этому, место на хабре?
Кстати, у автора данной статьи есть коллега, который много пишет о внутренностях Media SDK в своем блоге. К нему можно обратиться с вопросами. Ну а начать рекоммендую с этого поста: «А я рыба без трусов» или «и все-таки она вертится» :)
Ну и раз уж нас обвиняют в «маркетинге», то любопытно было бы узнать — как вы думаете, постам, подобным этому, место на хабре?
Отчего же нет. Пишите, конечно.
Спасибо за дополнительные наводки — обязательно изучу чуть позже.
Думаю до внутренностей я не сразу доберусь)
Насчёт же «маркетинга»…
Лично я не считаю подобные посты маркетингом. Ну серьёзно. Это примерно то же самое что обвинять Microsoft в том, что их лого красуется при загрузке Windows :)
Все и так отлично знают Intel и не думаю что компания нуждается в какой-либо завуалированной-в-виде-истории рекламе.
Да и Хабр сам по себе расчитан на наличие корпоративных блогов в своей жизни, тем более что в них нередко появляются весьма интересные статьи.
Плюс, я думаю, многим интересно новые факты и истории об одной из известнейших компаний в индустрии, тем более задающей «ритм» ИТ жизни. Так что не обращайте внимание на таких людей — они во всём и везде видят лишь маркетинг и «злой умысел» — и продолжайте писать! :)
Думаю до внутренностей я не сразу доберусь)
Насчёт же «маркетинга»…
Лично я не считаю подобные посты маркетингом. Ну серьёзно. Это примерно то же самое что обвинять Microsoft в том, что их лого красуется при загрузке Windows :)
Все и так отлично знают Intel и не думаю что компания нуждается в какой-либо завуалированной-в-виде-истории рекламе.
Да и Хабр сам по себе расчитан на наличие корпоративных блогов в своей жизни, тем более что в них нередко появляются весьма интересные статьи.
Плюс, я думаю, многим интересно новые факты и истории об одной из известнейших компаний в индустрии, тем более задающей «ритм» ИТ жизни. Так что не обращайте внимание на таких людей — они во всём и везде видят лишь маркетинг и «злой умысел» — и продолжайте писать! :)
Ничего плохого не вижу в таком маркетинге. Топик весьма познавательный, и не суть, что он написан сотрудником Intel. Совсем не плохо, что рассказывается про решения от Intel в области работы с видео.
От себя скажу. Связки Intel C2D E8400 + Nvidia 8800GTS для любого HD1080 видео будет хватать ещё очень надолго. Не процессорами едиными, как говорится.
От себя скажу. Связки Intel C2D E8400 + Nvidia 8800GTS для любого HD1080 видео будет хватать ещё очень надолго. Не процессорами едиными, как говорится.
Хватать-то оно хватает, но электричества такая связка съест в разы (это если оптимистично) больше, чем простой, но современный процессор со встроенным видеоядром, на «голой» материнской плате. И, если электричество дорогое (см. Европа), то апгрейд окупится достаточно быстро.
От себя, по традиции :). Заменил в медиацентре Е5300 + Radeon 4670 на Pentium G620 и счета уменьшились настолько, что срок окупаемости получился порядка 12 месяцев. А через 2 года буду снова смотреть, появилось ли что-то эффективнее. Возможно, тогда будут ARM-системы, которые будут тянуть задачи медиацентров и качалок, кто знает?
От себя, по традиции :). Заменил в медиацентре Е5300 + Radeon 4670 на Pentium G620 и счета уменьшились настолько, что срок окупаемости получился порядка 12 месяцев. А через 2 года буду снова смотреть, появилось ли что-то эффективнее. Возможно, тогда будут ARM-системы, которые будут тянуть задачи медиацентров и качалок, кто знает?
Статья была бы просто отличная, если бы не одно «но»: полное отсутствие информации о процессорах AMD, ARM, роли видеокарт, CUDA.
А почему забыли про H.263? Ведь собственно в нём появился деблокинг, встроенный в цикл кодирования, а не в H.261-м, как Вы написали.
MPEG4 ASP, о котором они написали, практически тоже самое, что и H.263, разве нет?
Что-то не нашел в статье упоминания 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 коэффициентов. Это особенно эффективно на низких и очень низких битрейтах.
По деблокингу: существует большая принципиальная разница в использовании деблокинга в MPEG-4 и H.263/H.264. В MPEG-4 он не участвует в цепочке кодирования, а может лишь опционально использоваться декодером в качестве постфильтрации для уменьшения эффекта блочности, возникающего из-за квантизации DCT-коэффициентов, особенно на низких битрейтах. В H.263 и H.264 деблокинг встроен в цепочку кодирования, т.е. предсказания производятся от «деблокированного» кадра, что уменьшает ошибку предсказания и, как следствие, уменьшает количество информации для кодирования DCT коэффициентов. Это особенно эффективно на низких и очень низких битрейтах.
А WebM ничего не привнёс нового, разве?
А что за инструкция idct? Можно поподробнее?
Давненько так развернуто не читал по теме :) Спасибо доставило.
>Теперь сжатие видео – не проблема. 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, практически лучшее, что можно сегодня купить у Интела.
Прежде чем переводить/перепечатывать маркетинговую хуиту, проверьте приводимые элементарно проверяемые факты, выраженные в числах.
Что это за феерическая хуита? Нет, ну правда.
У вас «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, практически лучшее, что можно сегодня купить у Интела.
Прежде чем переводить/перепечатывать маркетинговую хуиту, проверьте приводимые элементарно проверяемые факты, выраженные в числах.
Я не маркетолог, я разработчик. Тут накладка вышла. На входе было HD видео, на выходе — видео для iPad. Всё остальное верно.
Правило #9: Хабр — для спокойных людей. Просим оставить хамство, грубость, мат, прочие проявления агрессии и неадекватности для других ресурсов — на Хабре это не в почёте.
некоторые читатели еще помнят, как икал winamp, если пошевелить мышкойПомню на 486 процессоре (помоему частота была то ли 80 то ли 100МГц) воспроизведение музыкального файла с частотой дискретизации 22КГц проходило нормально, а при попытке вопсроизвести с частотой 44КГц — воспроизведение захлебывалось.
При этом Pentium с частотой 60МГц — музыкальный файл с 44КГц проигрывал хорошо. Это было явным доказательством более высокой производительности.
Кроме восхваленного интела на рынке были
1. аппаратные декодеры mpeg1
2. аппаратные декодеры mpeg2
3. gpu с cuda/opencl, выполняющие роль аппаратного декодера, на порядки более быстрого, чем процессор.
В частности, я прекрасно смотрел mpeg1 на pentium 133, а hd-видео прекрасно смотрю, не нагружая процессор и на 10%.
1. аппаратные декодеры mpeg1
2. аппаратные декодеры mpeg2
3. gpu с cuda/opencl, выполняющие роль аппаратного декодера, на порядки более быстрого, чем процессор.
В частности, я прекрасно смотрел mpeg1 на pentium 133, а hd-видео прекрасно смотрю, не нагружая процессор и на 10%.
Стоит заметить что 1 и 2 не были доступны широкому кругу пользователей. Максимум, что они могли использовать — аппаратные средства своих графических адаптеров. Там были свои недостатки.
Cuda/openCL — достаточно свежие разработки, в 2006 про них ничего не было слышно. И если nVidia пытается продвигать свои продукты, то AMD, которая тоже имеет свою технологию аппаратного кодирования Stream,… Не будем о грустном.
Cuda/openCL — достаточно свежие разработки, в 2006 про них ничего не было слышно. И если nVidia пытается продвигать свои продукты, то AMD, которая тоже имеет свою технологию аппаратного кодирования Stream,… Не будем о грустном.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, интересно.
«Надеюсь, некоторые читатели еще помнят, как икал winamp, если пошевелить мышкой» — AMD K5-90, винамп в бэкграунде, снаружи среда разработки, ничего не икало. Что я делал не так?
«Pentium III, «ускоряющий Интернет»» — да, редкостное было рекламное позорище. Правда, хомячки наверняка хавали.
«Теперь, чтобы проигрывать видео в формате HD, одного процессора (даже с технологией HyperThreading) уже недостаточно» — смотрел без тормозов 720p на AthlonXP 3000+. Что же я снова делал не так?
«Надеюсь, некоторые читатели еще помнят, как икал winamp, если пошевелить мышкой» — AMD K5-90, винамп в бэкграунде, снаружи среда разработки, ничего не икало. Что я делал не так?
«Pentium III, «ускоряющий Интернет»» — да, редкостное было рекламное позорище. Правда, хомячки наверняка хавали.
«Теперь, чтобы проигрывать видео в формате HD, одного процессора (даже с технологией HyperThreading) уже недостаточно» — смотрел без тормозов 720p на AthlonXP 3000+. Что же я снова делал не так?
Как я уже отмечал в комментариях, что со временем программные средства шагнули вперёд, и сейчас, допускаю, winamp больше не икает на слабых компьютерах (уточните ещё ОС, пожалуйста).
Pentium III действительно ускорял интернет. Врочем, как и Word и Winamp — за счёт более шустрой системной шины.
Хотя Athlon 3000+ достаточно мощный процессор, как Вы понимаете, здесь всё зависит от формата сжатия и битрейта. 720p MPEG2 — без проблем. 720p CABAC H264 — терзают меня смутные сомнения.
Pentium III действительно ускорял интернет. Врочем, как и Word и Winamp — за счёт более шустрой системной шины.
Хотя Athlon 3000+ достаточно мощный процессор, как Вы понимаете, здесь всё зависит от формата сжатия и битрейта. 720p MPEG2 — без проблем. 720p CABAC H264 — терзают меня смутные сомнения.
winamp больше не икает на слабых компьютерах (уточните ещё ОС, пожалуйста)
Это было в конце прошлого века. Соответственно, винамп старый, ОС — Win95SR2. Процессор AMD :-)
Pentium III действительно ускорял интернет. Врочем, как и Word и Winamp — за счёт более шустрой системной шины
Ой-вэй, системная шина 100MHz появилась еще на K6-2. Но каким образом более высокая частота системной шины влияла на скорость передачи данных — решительно непонятно. Хотя если для Вас «интернет» равняется «иконке на рабочем столе с буквой е», то таки да, ускорял ;-)
720p CABAC H264 — терзают меня смутные сомнения
Что такое «кабак», я не знаю. Речь идет про 720p XVid и 720p H264 через CoreAVC. WMV, понятное дело, работало черти как. Причем речь не про K8, а про K7.
Это было в конце прошлого века. Соответственно, винамп старый, ОС — Win95SR2. Процессор AMD :-)
Pentium III действительно ускорял интернет. Врочем, как и Word и Winamp — за счёт более шустрой системной шины
Ой-вэй, системная шина 100MHz появилась еще на K6-2. Но каким образом более высокая частота системной шины влияла на скорость передачи данных — решительно непонятно. Хотя если для Вас «интернет» равняется «иконке на рабочем столе с буквой е», то таки да, ускорял ;-)
720p CABAC H264 — терзают меня смутные сомнения
Что такое «кабак», я не знаю. Речь идет про 720p XVid и 720p H264 через CoreAVC. WMV, понятное дело, работало черти как. Причем речь не про K8, а про K7.
На 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. Хотя, даже здесь возможны варианты.
Речь в статье идёт про продукцию компании 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. Хотя, даже здесь возможны варианты.
«Системная шина во времена Pentium II/III была единственным связующим звеном между процессором и памятью»
Оно так в продукции Интел было вплоть до недавнего времени.
«Страницы реально стали отображаться быстрее»
Не могу понять, Вы технический работник или рекламный?
«поэтому нельзя сказать, что 720p спокойно декодировался на Вашей машине»
Очевидно, он декодировался святым духом.
«производительность WMV даёт какие-то намётки на скорость работы»
Производительность WMV всегда была отвратной на фоне прочих.
Оно так в продукции Интел было вплоть до недавнего времени.
«Страницы реально стали отображаться быстрее»
Не могу понять, Вы технический работник или рекламный?
«поэтому нельзя сказать, что 720p спокойно декодировался на Вашей машине»
Очевидно, он декодировался святым духом.
«производительность WMV даёт какие-то намётки на скорость работы»
Производительность WMV всегда была отвратной на фоне прочих.
Полностью технический.
Т.е. Вы не верите, что на скорость рендеринга HTML страниц может оказывать скорость шины процессора?
Само разрешение 720p — ни есть показатель. Как Вы понимаете, просто копировать память на AthlonXP 3000+ можно со скоростью 2666MBs / (1280х720x1.5) = 1928 fps. Это ни о чём не говорит. Как и слова «у меня игрался фильм». В своих словах «процессора с HT было недостаточно» я имел ввиду, что процессора с HT было недостаточно для проигрывания фильма сжатого с вменяемым битрейтом с любой комбинацией использованных фич. Никто не будет покупать программный декодер, если на нём написано «проигрывает H264 720p на Pentium III», а внизу маленькими буквами «только базовый профиль, I/P кадры, без деблокинга». Всех интересует возможность проигрывания всего безобразия, разрешённого стандартом.
Если Вы мне пришлёте кусочек фильма, то я с удовольствием его расковыряю и скажу, как он был сжат. Впрочем, Вы можете сделать это и сами — в сети полно программных средств для определения характеристик сжатых фильмов.
Т.е. Вы не верите, что на скорость рендеринга HTML страниц может оказывать скорость шины процессора?
Само разрешение 720p — ни есть показатель. Как Вы понимаете, просто копировать память на AthlonXP 3000+ можно со скоростью 2666MBs / (1280х720x1.5) = 1928 fps. Это ни о чём не говорит. Как и слова «у меня игрался фильм». В своих словах «процессора с HT было недостаточно» я имел ввиду, что процессора с HT было недостаточно для проигрывания фильма сжатого с вменяемым битрейтом с любой комбинацией использованных фич. Никто не будет покупать программный декодер, если на нём написано «проигрывает H264 720p на Pentium III», а внизу маленькими буквами «только базовый профиль, I/P кадры, без деблокинга». Всех интересует возможность проигрывания всего безобразия, разрешённого стандартом.
Если Вы мне пришлёте кусочек фильма, то я с удовольствием его расковыряю и скажу, как он был сжат. Впрочем, Вы можете сделать это и сами — в сети полно программных средств для определения характеристик сжатых фильмов.
В целом — спасибо, было интересно. Но не удержался таки, вставлю свои пять копеек.
Вы, уважаемый автор, к сожалению, изредка ошибаетесь. Winamp действительно не «икал» на 486-х (W95) и тем паче на любых пентиумах (оси W95, W98). Это первая погрешность. А вот если поставить на это же железо «шагнувшие вперед» программные средства (ME 2000 XP 2003 и +), то не то что винамп, даже блокнот икать будет — и это вторая погрешность (уже в комментариях). Аппаратные кодеры и декодеры были, и причем довольно доступные (плату видеозахвата еще до VIVO в видеокартах я помнится покупал баксов за 50, через неё гонялся контент, и в, и из) — третья. Ускорение Интернета на PIII — гм…
Видимо, отсюда и происходит непонимание аудитории которая припоминает одно и уважаемого автора, который припоминает иное. Но не обижайтесь, на хабре давно уже принято цепляться к мелочам, не имеющим отношения к сабжу. Это такое как бы самовыражение. Давно наблюдается сие, да и сам я тоже как видите грешен.
А статья, на самом деле, замечательная. Правда.
Вы, уважаемый автор, к сожалению, изредка ошибаетесь. Winamp действительно не «икал» на 486-х (W95) и тем паче на любых пентиумах (оси W95, W98). Это первая погрешность. А вот если поставить на это же железо «шагнувшие вперед» программные средства (ME 2000 XP 2003 и +), то не то что винамп, даже блокнот икать будет — и это вторая погрешность (уже в комментариях). Аппаратные кодеры и декодеры были, и причем довольно доступные (плату видеозахвата еще до VIVO в видеокартах я помнится покупал баксов за 50, через неё гонялся контент, и в, и из) — третья. Ускорение Интернета на PIII — гм…
Видимо, отсюда и происходит непонимание аудитории которая припоминает одно и уважаемого автора, который припоминает иное. Но не обижайтесь, на хабре давно уже принято цепляться к мелочам, не имеющим отношения к сабжу. Это такое как бы самовыражение. Давно наблюдается сие, да и сам я тоже как видите грешен.
А статья, на самом деле, замечательная. Правда.
H.264 на AthlonXP 3000+? Что, правда?
sandybridge процессоры действительно фантастический прорыв. На наших задачах почти двухкратное ускорение по сравнению с core 2.
Компьютеры за 10 тыс рублей с мощнейшими Core i5 ставят под вопрос целесообразность вложений в Cuda =)
Только вот про Quick Sync непонятно. Где можно увидеть пример _работающего_ приложения, пользущегося этой технологией и сравнимого по качеству результата с libx264?
Компьютеры за 10 тыс рублей с мощнейшими Core i5 ставят под вопрос целесообразность вложений в Cuda =)
Только вот про Quick Sync непонятно. Где можно увидеть пример _работающего_ приложения, пользущегося этой технологией и сравнимого по качеству результата с libx264?
Для многих, к сожалению, разницы никакой из-за того, что пока AVX регистры работают только с плавучкой. Но приятно слышать, что у кого-то двухкратный прирост. Вот выйдет Haswell… :)
Кстати там ещё будут FMA инструкции, так что плавучку можно будет ещё сильнее ускорить.
Кстати там ещё будут FMA инструкции, так что плавучку можно будет ещё сильнее ускорить.
Большинство производителей программ для сжатия (Roxio, Corel, ArcSoft и т.д.) уже добавили поддержку Quick Sync в свои приложения. Более того, обычно программы с поддержкой новых технологий Intel выходят или раньше самих процессоров, или одновременно с ними. Это результат работы программы ранней адаптации компании.
Для конечного пользователя это выглядит, как значительное повышение скорости перекодирования при запуске на новом железе.
Для конечного пользователя это выглядит, как значительное повышение скорости перекодирования при запуске на новом железе.
я ориентируюсь на самую авторитетную лабораторию: compression.ru/video/codec_comparison/h264_2011/
Вообще-то, 8 регистров MMX не такие уж и новые. Это части регистров сопроцессора. Поэтому нельзя одновременно использовать инструкции MMX и операции с дробными числами.
> В начале 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, иначе на полный экран не развернуть или развернуть с тормозами.
Виндовый медиаплейр не играл на таком железе, согласен. Но это не единственная программа, не так ли.
> декодировать видео с приемлемой скорость. Нет, про HDTV разрешения ещё никто не мечтал,
> но маленькое QCIF видео процессор уже способен был проигрывать без тормозов.
> «Виновница» этого – технология MMX.
Вы лукавите и сильно преуменьшаете производительность тогдашних процессоров.
Под DOS и OS/2 плеер QV на PI-166MMX/Socket7 разогнанном до 200 без всяких тормозов проигрывал mpeg4 512 x 3xx с битрейтом 500-700кбс. AMD K6 200-300Мгц и подавно.
При этом надо было иметь еще карточку от S3, которая поддерживала аппараратный scaling, иначе на полный экран не развернуть или развернуть с тормозами.
Виндовый медиаплейр не играл на таком железе, согласен. Но это не единственная программа, не так ли.
Спасибо, Ты меня вдохновил на написание подобной истории про 3d графику :)
Но меня очень удивил прирост производительности от MMX в 3-4 раза. я могу поверить только в 2, для остального нужны пояснения :)
Но меня очень удивил прирост производительности от MMX в 3-4 раза. я могу поверить только в 2, для остального нужны пояснения :)
Многие вдохновились! Заходите, пишите :)
В 2 раза понятно почему, и еще избавились от возни с Х87 стековой машиной. На сингл флотах в 3 раза могло быть.
В некоторых задачах MMX давал и больший прирост.
В большинстве своём, в процессе декодирования внутри кодеков используется тип short int. В ММХ регистр влазит 4 short'а. Т.е. по инструкциям add/sub должен быть прирост 4х, на практике достигается примерно 3х или чуть больше.
Если надо было сложить два short'а, проверить на переполнение и привести результат к диапазону байта (от 0 до 255), то на генеральных регистрах это вообще туча инструкций. А на MMX всего две: сложение и запаковка short в byte. Обе быстрые и короткие.
Ну и так далее :)
В большинстве своём, в процессе декодирования внутри кодеков используется тип short int. В ММХ регистр влазит 4 short'а. Т.е. по инструкциям add/sub должен быть прирост 4х, на практике достигается примерно 3х или чуть больше.
Если надо было сложить два short'а, проверить на переполнение и привести результат к диапазону байта (от 0 до 255), то на генеральных регистрах это вообще туча инструкций. А на MMX всего две: сложение и запаковка short в byte. Обе быстрые и короткие.
Ну и так далее :)
>Это много позже сжатие и разжатие цифрового видео стало коньком компании 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.»
Спасибо, посмеялся.
У вас так и не появилась инструкции 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.»
Не надо смеятся. Достаточно взглянуть на специализированные форумы, где люди подбирают себе машины для видео редактирования/сжатия.
Смотря какие функции, и как они реализованы. Врядли кто-нибудь способен написать функцию, которая считает 8 сумм абсолютных разностей за 4 такта. Именно столько работает инструкция MPSADBW. Вы до сих пор считаете, что их функции работают быстрее?
То, что у них не получилось использовать эти инструкции в своих функциях, ещё не говорит, что функции быстрые, а инструкции бесполезные.
По остальным вопросам — в отдел планирования, я — лишь разработчик.
По личному опыту скажу, что я регулярно заливаю перед поездками видео на iPad, и скорость, с которой это происходит на SandyBridge — для меня главное. Я не пользуюсь --superfast настройкой, пользуюсь только --balanced. Визуальных артефактов не замечаю, видео после просмотра стираю.
Смотря какие функции, и как они реализованы. Врядли кто-нибудь способен написать функцию, которая считает 8 сумм абсолютных разностей за 4 такта. Именно столько работает инструкция MPSADBW. Вы до сих пор считаете, что их функции работают быстрее?
То, что у них не получилось использовать эти инструкции в своих функциях, ещё не говорит, что функции быстрые, а инструкции бесполезные.
По остальным вопросам — в отдел планирования, я — лишь разработчик.
По личному опыту скажу, что я регулярно заливаю перед поездками видео на iPad, и скорость, с которой это происходит на SandyBridge — для меня главное. Я не пользуюсь --superfast настройкой, пользуюсь только --balanced. Визуальных артефактов не замечаю, видео после просмотра стираю.
Виктор, я не спорю, для временного просмотра 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:
Речь о более серьёзном применении, которого пока нет.
О 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:
Диджей, вы, я вижу, довольно глубоко разбираетесь в теме. Предположу даже, что ваша работа как-то связана с видеокодированием. Если вам нужна какая-нибудь фича — сформулируйте формальный запрос в форуме Media SDK! Еще раз ссылаться на парней из x264 большого смысла нет, — мы прекрасно знаем все их пожелания. Скажу даже больше, к ним уже выехали специальные люди ;).
Работа «простых» девелоперов строится исходя их приоритетов, продиктованных либо ключевыми, либо типовыми заказчиками. Единственный способ сделать наш мир чуточку лучше — открыто высказывать свои обоснованные требования в правильном месте.
Спасибо за понимание :)
Работа «простых» девелоперов строится исходя их приоритетов, продиктованных либо ключевыми, либо типовыми заказчиками. Единственный способ сделать наш мир чуточку лучше — открыто высказывать свои обоснованные требования в правильном месте.
Спасибо за понимание :)
Когда-нибудь компания Intel (возможно) откроет доступ к своему внутреннему железу для независимых разработчиков, и тогда все будут счастливы. Я думаю, что x264 парни нашли бы там всё, что их интересует.
К сожалению, если это и случится, то не ближайшие год-два точно. Это вопросы уже высшего менеджмента, это не ко мне.
К сожалению, если это и случится, то не ближайшие год-два точно. Это вопросы уже высшего менеджмента, это не ко мне.
Наверное нужно было как-то кратко на пальцах еще рассказать принципы кодирования/декодирования видео, в чем там самая сложность и т.д. Ато с таким упоением рассказывается как все клево сделали, но я вот незнаю что такое «intra-предсказание» и «полупиксельные вектора», поэтому масштаб успеха оценить могу с трудом =)
НЛО прилетело и опубликовало эту надпись здесь
Жаль нету «Я ненавижу компанию», хочется исключить такие обманные посты из хабраленты…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История развития форматов видеосжатия