Однако если выполнить модификации в Media Server, HAL, в драйвере ALSA
Вот бы вся статья об этом была, с подробным разбором кишков андроида, с указанием тех мест, где ребята из гугла конкретно облажались с дизайном платформы и вся звуковая low-latency индустрия от этого теперь страдает.
PS: В NDK вполне вменяемый пример использования OpenSL ES и платформа x86 там ни чем особо не выделяется.
на си это сделано так: сначала цикл по пикселям, затем цикл по компонентам пикселя и уже в самой глубине switch, выбирающий нужную функцию. На c++ тоже самое: сначала switch, затем вызов одной и той же шаблонной функции обхода пикселей и компонент, но в качестве аргумента — лямбда функция обработки одной компоненты
В 2006-2010гг работал в организации, занимающейся транзитом электроэнергии.
Там на головной подстанции РЗА еще с 1940-х годов сохранилась (General Electric вроде).
В целом по региону ситуация была такова, что на всех головных подстанциях работал диспетчерский персонал для осуществления отключений.
АСДУ если и были, то, либо на удаленных объектах в глуши, либо на модных предприятиях.
Так что Ваш гаджет если и имеет отношение к действительности, то как правило к оконечному потребителю в виде модного дата-центра.
А основная «цепочка» построена на гораздо более простых, надежных и проверенных временем электротехнических узлах.
В некоторых случаях (google nacl newlib/glibc) лучше будет -std=gnu99, иначе становятся недоступными POSIX расширения, такие как strdup и др.
Пару слов о портабельности и замечательном компиляторе MSVC, который так несправедливо упустили из повествования
— если MSVC достаточно свежий (>=13), то поддержка c99 там хоть какая-то, да есть
— если MSVC более старый, то можно использовать трюк: на все сишные единицы компиляции вешаем свойство «язык С++» и получаем возможность собирать Си код.
Пример для cmake:
set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE CXX)
Конечено, есть и минусы — придется таскать за собой stdbool.h, статическая инициализация именованных полей структур перестанет работать, в switch case нельзя будеть объявлять переменные (прыжок через инициализацию) и т.п.
SSE не полностью совместим с IEEE 754, поэтому результаты могут отличаться от скалярной версии
Большинство современных процессоров являются скалярными
Поправка — суперскалярными.
SSE и AVX векторы всегда попадают в одну кэш линию, если они выравнены по 16 и 32 байта, соответственно
Невыровненные векторы читать/писать можно, для этого есть специальные версии команд загрузки/сохранения (безусловно, это может отразиться на производительности).
Для векторов, лежащих на границе двух кэш линий есть специальный SSE3 интринсик _mm_lddqu_si128
Сложные алгоритмы потребуют изобретательность, но без этого никуда
именно поэтому я бы сменил показатель «усилия программиста» на умеренно высокие
Ценой малых усилий мы можем получать от системы как можно большей производительности, задействуя все возможные аппаратные ресурсы
на самом деле далеко не все, т.к. используете только узкое подмножество инструкций
ИМХО SIMD создан не для того, чтобы «не надо было думать», а для того, чтобы выжать максимум из конкретного CPU.
вы действительно получаете кросс-процессорную поддержку на С#
Собственно про аналитику ничего не сказано.
Как именно определить «падение», «праздное шатание», драку, пожар, и т.д., и т.п.?
В статье описан способ дешевой сегментации без конкретики как бороться с возникающими при этом проблемами (смена освещения, тени, перекрытия)
PS: Если исходное видео кодированное, то необходимость расчета яркости отпадает, кадры там уже в цветовом формате YUV. Плюс для снижения вычислительных затрат на сегментацию, можно использовать синтаксические элементы из кодированного видеопотока, например, векторы движения.
А при чем тут перекрытие?
Я про объем спектральных данных, которые потом будут квантоваться и кодироваться.
У MDCT их будет в 2 раза меньше, чем у Фурье.
Или Вы хотите сказать, что перекрытие на столько велико, что сводит на нет данное преимущество?
MDCT: it has half as many outputs as inputs (instead of the same number)
…
The 2N real numbers X_0, ..., X_2N-1 are transformed into the N real numbers
То есть с точки зрения сжатия MDCT (не путать с DCT) как минимум в 2 раза выгоднее Фурье, т.к. не содерджит мнимой части.
львиная доля компрессии достигается таким нехитрым способом, который на языке C# занимает буквально лишь несколько строк
На ультра низких битрейтах используются более изощренные инструменты кодирования, например: Parametric Stereo (AAC-HEv2) и Spectral Band Replication (AAC-HE), первый позволяет кодировать моно сигнал, а при декодировании опционально восстанавливать стерео, второй — кодировать только половину спектра, а при декодировании опционально восстанавливать верхние частоты расчетным путем, в обоих случаях в поток кладется некоторая дополнительная информация.
ЕМНИП в аудиокодеках используется косинусное преобразование (модифицированное DCT-IV), у которого в спектре есть только действительная часть(в 2 раза меньше данных, чем у классического фурье).
А какие есть методы объективной оценки искажения аудиосигналов?
PSNR как я понимаю не подойдет, т.к. упадет ниже плинтуса, даже если просто сдвинуть исхродный сигнал по фазе.
У Криса Касперски в книге по оптимизации программ и эффективному использованию памяти была описана подобная методика. Вы не в курсе, что сейчас еще осталось актуально из его рекомендаций? Например, организовывать доступ к памяти так, чтобы он как можно чаще попадал в разные банки DDR, минимизируя потери на регенерацию.
Интересно, как Android Studio будет стыковаться с нынешней системой сборки NDK, основанной на Android.mk / Application.mk? Будет грустно, если ребята из Google на нее просто забьют.
Киллер фича преобразования DCT-II, используемого в алгоритмах сжатия изображений, заключается в том, что большая часть энергии входного сигнала сосредоточена в области низких частот (левый верхний угол). Это позволяет заквантовывать в хлам высокие частоты и получать после прохода зигзагом большие серии нулей. Которые затем эффективно кодируются алгоритмом RLE и далее Хаффманом. Преобразование Уолша, на сколько мне известно, такими свойствами не обладает.
Для объективного сравнения двух кодеков можно сделать следующее: закодировать спроектированным и референсным(JPEG) кодеками серию картинок с увеличивающимися квантизациями и посчитать искажения (PSNR). Затем, для каждого кодека построить график зависимости PSNR от размера изображения.
Если разработанный Вами кодек будет иметь кривую PSNR(Bitrate), совпадающую с аналогичной кривой JPEG, то можно сказать что потери качества нет.
Если график будет над JPEG (при одинаковом размере файла — меньшее искажение), то надо срочно патентовать.
Если график будет ниже JPEG, то очевидно имеем просадку качества (на том же самом битрейте бОльшие искажения).
Очень подробная инструкция о том, как разрабатывать OpenCL код для Андроид.
И ни слова о том, что эта технология официально не поддерживается в данной ОС.
Гугл в качестве альтернативы OpenCL выдвинул свой RenderScript.
Вот бы вся статья об этом была, с подробным разбором кишков андроида, с указанием тех мест, где ребята из гугла конкретно облажались с дизайном платформы и вся звуковая low-latency индустрия от этого теперь страдает.
PS: В NDK вполне вменяемый пример использования OpenSL ES и платформа x86 там ни чем особо не выделяется.
Хрен редьки не слаще (с)
Там на головной подстанции РЗА еще с 1940-х годов сохранилась (General Electric вроде).
В целом по региону ситуация была такова, что на всех головных подстанциях работал диспетчерский персонал для осуществления отключений.
АСДУ если и были, то, либо на удаленных объектах в глуши, либо на модных предприятиях.
Так что Ваш гаджет если и имеет отношение к действительности, то как правило к оконечному потребителю в виде модного дата-центра.
А основная «цепочка» построена на гораздо более простых, надежных и проверенных временем электротехнических узлах.
В некоторых случаях (google nacl newlib/glibc) лучше будет -std=gnu99, иначе становятся недоступными POSIX расширения, такие как strdup и др.
Пару слов о портабельности и замечательном компиляторе MSVC, который так несправедливо упустили из повествования
— если MSVC достаточно свежий (>=13), то поддержка c99 там хоть какая-то, да есть
— если MSVC более старый, то можно использовать трюк: на все сишные единицы компиляции вешаем свойство «язык С++» и получаем возможность собирать Си код.
Пример для cmake:
set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE CXX)Конечено, есть и минусы — придется таскать за собой stdbool.h, статическая инициализация именованных полей структур перестанет работать, в switch case нельзя будеть объявлять переменные (прыжок через инициализацию) и т.п.
Intel 64 and IA-32 Architectures Optimization Reference Manual
3.8.3.3 Floating-point Exceptions in SSE/SSE2/SSE3 Code
SSE не полностью совместим с IEEE 754, поэтому результаты могут отличаться от скалярной версии
Поправка — суперскалярными.
Невыровненные векторы читать/писать можно, для этого есть специальные версии команд загрузки/сохранения (безусловно, это может отразиться на производительности).
Для векторов, лежащих на границе двух кэш линий есть специальный SSE3 интринсик _mm_lddqu_si128
именно поэтому я бы сменил показатель «усилия программиста» на умеренно высокие
на самом деле далеко не все, т.к. используете только узкое подмножество инструкций
ИМХО SIMD создан не для того, чтобы «не надо было думать», а для того, чтобы выжать максимум из конкретного CPU.
А как будут обстоять дела с ARM?
Как именно определить «падение», «праздное шатание», драку, пожар, и т.д., и т.п.?
В статье описан способ дешевой сегментации без конкретики как бороться с возникающими при этом проблемами (смена освещения, тени, перекрытия)
PS: Если исходное видео кодированное, то необходимость расчета яркости отпадает, кадры там уже в цветовом формате YUV. Плюс для снижения вычислительных затрат на сегментацию, можно использовать синтаксические элементы из кодированного видеопотока, например, векторы движения.
Да, более того, один из способов быстрого вычисления MDCT — через FFT
Поэтому движок FFT все-равно используют в кодеках
Я про объем спектральных данных, которые потом будут квантоваться и кодироваться.
У MDCT их будет в 2 раза меньше, чем у Фурье.
Или Вы хотите сказать, что перекрытие на столько велико, что сводит на нет данное преимущество?
…
The 2N real numbers X_0, ..., X_2N-1 are transformed into the N real numbers
То есть с точки зрения сжатия MDCT (не путать с DCT) как минимум в 2 раза выгоднее Фурье, т.к. не содерджит мнимой части.
На ультра низких битрейтах используются более изощренные инструменты кодирования, например: Parametric Stereo (AAC-HEv2) и Spectral Band Replication (AAC-HE), первый позволяет кодировать моно сигнал, а при декодировании опционально восстанавливать стерео, второй — кодировать только половину спектра, а при декодировании опционально восстанавливать верхние частоты расчетным путем, в обоих случаях в поток кладется некоторая дополнительная информация.
ЕМНИП в аудиокодеках используется косинусное преобразование (модифицированное DCT-IV), у которого в спектре есть только действительная часть(в 2 раза меньше данных, чем у классического фурье).
А какие есть методы объективной оценки искажения аудиосигналов?
PSNR как я понимаю не подойдет, т.к. упадет ниже плинтуса, даже если просто сдвинуть исхродный сигнал по фазе.
Видимо, то же самое произошло, когда Google не устроил стандарт OpenCL для Android и родился «самый правильный» стандарт RenderScript.
Для объективного сравнения двух кодеков можно сделать следующее: закодировать спроектированным и референсным(JPEG) кодеками серию картинок с увеличивающимися квантизациями и посчитать искажения (PSNR). Затем, для каждого кодека построить график зависимости PSNR от размера изображения.
Если разработанный Вами кодек будет иметь кривую PSNR(Bitrate), совпадающую с аналогичной кривой JPEG, то можно сказать что потери качества нет.
Если график будет над JPEG (при одинаковом размере файла — меньшее искажение), то надо срочно патентовать.
Если график будет ниже JPEG, то очевидно имеем просадку качества (на том же самом битрейте бОльшие искажения).
И ни слова о том, что эта технология официально не поддерживается в данной ОС.
Гугл в качестве альтернативы OpenCL выдвинул свой RenderScript.
Интел свой квик синк H265 в том числе на этих стримах тестирует.
Взять его можно, например, здесь.