• Распознавание товаров на полках с помощью нейронных сетей на технологиях Keras и Tensorflow Object Detection API
    +1
    Очень познавательно. ИНтересный хорошо объяснённый пример практического применения сетей.
  • Новые возможности Intel Media Server Studio 2016
    0
    Нашёл старую версию. Надо выбрать «скачать», ввести всю личную информацию, потом на последнем шаге будет доступен выбор версии.
  • Новые возможности Intel Media Server Studio 2016
    0
    Как сказал один великий человек «страшно далеки они от народа». Это я о фирме Интел. С одной стороны они выпустили замечательный продукт под Линукс, с другой стороны в версии 2017 выкинули поддержку предыдущих поколений процессоров. Хочется отметить, что продукт нацелен в первую очередь на использование профессиональными пользователями. А на профессиональном рынке так быстро машины не меняют. Решение, настроенное раз, работает годами. Я не против того, что новая версия не поддерживает старые процессоры. Но вы оставьте линк на старую версию, чтобы оставить в душе ложное чувство, что Интел заботится о своих пользователях чуть дальше момента покупки нового процессора. Спасибо.
    Буду благодарен за ссылку на предыдущий релиз.
  • AlphaGo на пальцах
    0
    Доходчиво, понятно!
  • (Само)идентификация процессоров. Часть вторая. Волосатый CPUID
    0
    Я склонен считать, что это была бага процессора. В официальной доке ничего такого нет.

    К нам обратились клиенты, которые жаловались, что наше ПО медленно работает на их достаточно топовой машине. После процесса отладки было обнаружено, что большинство оптимизированных функций не работают. Стали смотреть на процедуру идентификации процессора и обнаружили, что CPUID выдаёт нулевые биты для «предыдущих» SSE технолигий. Самое интересное, что наше ПО находило бит AVX, но проверяло наличие всех битов AVX/SSE42/SSE41/SSSE3 для запуска AVX версии. Пришлось поправить код, и довольствоваться одним битом.
  • (Само)идентификация процессоров. Часть вторая. Волосатый CPUID
    0
    Ещё одна фишка процессоров от AMD. Некоторые процессоры на ядре Bulldozer могут возвращать флаг AVX=1, но при этом флаги SSE42, SSE41 и SSSE3 равными 0, причём все эти технологии присутствуют. Зачем это сделано — не очень понятно. Но старые программы точно не смогут «обнаружить» технологии «занулёные» технологии.
  • Acceler8 2011 — Accelerate 2012 — и так далее
    –2
    Код не самый красивый, да и вообще не понятно, зачем такое написали, если известна длина копировая. Обычный memcpy справился бы лучше. Лекция за какой год?

    PS: Интел очень большой, сотни людей занимаются разными проектами и имеют порой диаметрально противоположные взгляды на какие-то вещи. Моя точка зрения — красивый код почти всегда самый быстрый. Не говоря о том, что он легко читается и поддерживается.
  • Acceler8 2011 — Accelerate 2012 — и так далее
    0
    Ну зря вы так. Первые пять мест действительно постарались. И алгоритм проработали, и распараллелили.

    С генерацией матрицы действительно вышла накладка, тут критика уместна.
  • Acceler8 2011 — Accelerate 2012 — и так далее
    0
    Одинаково некрасиво писали. Другое дело, что были элегантные решения, это да. Но написаны в коде они были уже не так элегантно, как придуманы.
  • Acceler8 2011 — Accelerate 2012 — и так далее
    0
    Требование «быстрого кода» никак не противоречит тому, чтобы писать красиво и читабельно. Я встречал в жизни буквально пару случаев, когда действительно код можно написать было «некрасивым» способом, чтобы он работал.

    Во всех прочих случая — банальная лень программистов оформлять свой код корректно. По крайней мере, прочитав большой объём кода участников, я не нашёл места, которое нельзя было бы написать «красиво».
  • История развития форматов видеосжатия
    +1
    Это известные ребята, мы с ними работаем.
    К сожалению, не увидел в статье даты, когда она была написана. Возможно просмотрел. И, насколько я понял, они измерили только качество, скорость не измеряли.
  • История развития форматов видеосжатия
    +2
    В чём обман? Выражайтесь полнее.
  • История развития форматов видеосжатия
    0
    Когда-нибудь компания Intel (возможно) откроет доступ к своему внутреннему железу для независимых разработчиков, и тогда все будут счастливы. Я думаю, что x264 парни нашли бы там всё, что их интересует.

    К сожалению, если это и случится, то не ближайшие год-два точно. Это вопросы уже высшего менеджмента, это не ко мне.
  • История развития форматов видеосжатия
    0
    В некоторых задачах MMX давал и больший прирост.

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

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

    Ну и так далее :)
  • История развития форматов видеосжатия
    0
    Полностью технический.
    Т.е. Вы не верите, что на скорость рендеринга HTML страниц может оказывать скорость шины процессора?

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

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

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

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

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

    Тот же всеми почитаемый CoreAVC одно время не проходил conformance тестирование для H264. Или у них была ошибка в деблокинге, или они его отключали :)
  • История развития форматов видеосжатия
    0
    В момент выхода стандартов обычно всегда производительности было мало. С ходом времени код кодеков «допиливался» для более ранних процессоров, что позволяло проигрывать без тормозов НЕКОТОРЫЕ фильмы, сжатые с использованием ограниченного набора параметров. Почему нет.
  • История развития форматов видеосжатия
    0
    В стандарте H264 много профилей и фич, большинство из которых — неподъёмная задача для этого процессора. Другое дело, если включена поддержка декодирования на графическом адаптере. Но тогда процессор здесь не причём.
  • История развития форматов видеосжатия
    0
    50 долларов в каком году? В 2000 и 2011 это весьма разные 50 долларов :).

    Про ускорение интернета я ответил в комментарии выше. Pentium III действительно ускорял интернет :)
  • История развития форматов видеосжатия
    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
    Большинство производителей программ для сжатия (Roxio, Corel, ArcSoft и т.д.) уже добавили поддержку Quick Sync в свои приложения. Более того, обычно программы с поддержкой новых технологий Intel выходят или раньше самих процессоров, или одновременно с ними. Это результат работы программы ранней адаптации компании.

    Для конечного пользователя это выглядит, как значительное повышение скорости перекодирования при запуске на новом железе.
  • История развития форматов видеосжатия
    +2
    Как я уже отмечал в комментариях, что со временем программные средства шагнули вперёд, и сейчас, допускаю, winamp больше не икает на слабых компьютерах (уточните ещё ОС, пожалуйста).

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

    Хотя Athlon 3000+ достаточно мощный процессор, как Вы понимаете, здесь всё зависит от формата сжатия и битрейта. 720p MPEG2 — без проблем. 720p CABAC H264 — терзают меня смутные сомнения.
  • История развития форматов видеосжатия
    0
    Стоит заметить что 1 и 2 не были доступны широкому кругу пользователей. Максимум, что они могли использовать — аппаратные средства своих графических адаптеров. Там были свои недостатки.
    Cuda/openCL — достаточно свежие разработки, в 2006 про них ничего не было слышно. И если nVidia пытается продвигать свои продукты, то AMD, которая тоже имеет свою технологию аппаратного кодирования Stream,… Не будем о грустном.
  • История развития форматов видеосжатия
    +2
    Core i7 — 2600S.
    Ещё раз заострю внимание, что сжимался HD фильм в iPad разрешение аппаратным средствами встроенного графического ядра процессора…
  • История развития форматов видеосжатия
    +4
    Ограничения формата блога. Ничего не могу поделать :)
  • История развития форматов видеосжатия
    +2
    Программистская мысль шагнула очень далеко с тех времён, когда Pentium 120 был топовым процессором. Как в функциональной оптимизации, так и в алгоритмической. Весьма допускаю, что современное, специально подогнанное ПО может выжать из «пожилых» машин больше, чем в своё время их ровестники.
  • История развития форматов видеосжатия
    +1
    Да, кодеков было больше, чем описано в статье. Было бы слишком длинно останавливаться на всех.
    С точки зрения производительности/качества WebM не принёс ничего слишком запоминающегося. Это хороший специализированный кодек для сети. Вряд ли он шагнёт дальше сети в ближайшее время.
  • История развития форматов видеосжатия
    +2
    Я не маркетолог, я разработчик. Тут накладка вышла. На входе было HD видео, на выходе — видео для iPad. Всё остальное верно.