тут перечислен десяток каких то узкополезных кому то утилит
Да Вы, батенька, шутник. FFmpeg - по сути стал стандартом мультимедиа API. Такие компании, как Intel и nVidia в составе сових SDK для аппаратного сжатия сами пишут модули для инфраструктуры FFmpeg. Большинство медиаплееров, пригодных для практического использования, содержат в своей основе FFmpeg явно или косвенно (например, через bad или ugly плагины GStreamer'a).
Любопытно, а в более сложных CISC инструкциях типа REP (привет memcpy) тоже нет подкапотного разваливания на микрокод и все сделано по-настоящему аппаратно?
Формату JPEG в этом году исполнилось 30 лет, нужно отдать должное его разработчикам, т.к. он до сих пор имеет свою нишу.
Впрочем, интерес представляет даже не сам JPEG, а возможность использования линейных преобразований для сжатия без потерь.
В сжатии изображений преобразование предназначено для минимизации среднеквадратичной ошибки, вносимой квантованием. Оптимальным считается преобразование Карунена-Лоэва, а DCT-II является его наилучшим приближением для сжатия изображений. То есть, пеобразование является необходимым этапом при сжатии с Потерями.
Если интерес представляет именно сжатие без потерь, стоит обратить внимание на соответсвующие инструменты кодирования:
предсказание DCT коэффициентов по соседним (уже закодированным) блокам (H.263/MPEG-4 Part 2)
предсказание пикселей текущего блока, по восстановленным соседним (Intra predict, H.264 и т.п.)
сегментация изображения с целью кодирования больших равномерных областей бОльшими блоками (квадро-дерево H.265 и т.п.)
для "Screen" контента использовать сжатие с палитрой (H.265)
продвинутые алгоритмы энтропийного сжатия остаточной информации Huffman (с фиксированными таблицами) -> CAVLC -> CABAC
В современных форматах сжатия изображений это реализовано в том или ином виде.
Удивительно! Мы получили сравнимые с результатом A4000 цифры. Несмотря на большую частоту работы чипа, больший объем используемой видеопамяти и большее энергопотребление, A5000 осилила энкодинг только 14 потоков и спасовала на пятнадцатом. Это фиаско...
С одной стороны результат вполне ожидаемый, т.к. обе карты имеют на борту один модуль NVENC (см. [1]).
С другой стороны результат странный, т.к. в связи с более высокой частотой чипа "The performance should scale according to the video clocks as reported by nvidia-smi for other GPUs of every individual family" (см. [2]). Как вариант, прирост тактовой частоты был недостаточен для того, чтобы успеть еще один профиль кодирования на целевом разрешении, но это не точно.
Нет, так это не работает, увы. Медицинская техника всё-таки
Это на самом деле очень интересный момент. По идее сабжевый агрегат косвенно несет ответственность за здоровье. А следовательно должен пройти серьезную сертификацию, и до кучи, если является средством измерения внесен в единый гос реестр СИ. И вот в этом процессе подобные архитектурные "решения" следовало бы присекать на корню ИМХО.
Поддерживаю, 2^32 уровней квантования хватит, чтобы залезть в область тепловых шумов компонент РЭА, что сводит на нет всякий смысл АЦП таких разрядностей.
Производящий поток пушит данные в MIDI устройство вызовами midiOutLongMsg() или midiStreamOut(), а в колбэке MOM_DONE получаем уведомление, что железяка воспроизвела нотки и можно в нее пушить дальше. Но это не точно.
Таймер = дёрганье колбэков из потока. И да, потоку нужно в общем случае ставить повышенный приоритет. Если вы про какие-то другие колбэки, то объясните, пожалуйста. Кроме того, воспроизведение аудио != обработка воспроизводимого аудио.
Воспроизведение аудио - это по сути вывод последовательности дискретных отсчетов в ЦАП. ЦАП работает с фиксированной частотой дискретизации. В него невозможно запихать данных больше, чем размер буфера, стоящего перед ним. Устройство вывода звука "подпирает" источник данных и это нормально.
сомнительно, что VLC, Windows Media Player, плеер Chrome и много других программ используют антипаттерн
Я не говорил, что данные проекты используют антипаттерн. Тут скорее сделан ошибочный вывод того, как они работают на основе того факта, что их процесс в планировщеке ОС имеет бОльшее разрешение системного таймера. Без какого-либо анализа кодовой базы.
Расскажите, пожалуйста, как вам видится идеальная реализация плейбека
См. главу 2 Вывод звука. Объяснения там, конечно, на уровне "сначала рисуем один овал, затем другой, а потом дорисовываем сову", но поверхностная суть просматривается.
Классический подход при воспроизведении мультимедийных данных – раз в N единиц времени смотреть, что́ нужно подать на устройство вывода (видео-, звуковую карту и т.д.) в данный момент времени, и при необходимости отсылать новые данные (кадр, аудиобуфер) на это устройство
Это антипаттерн. Все вменяемые audio API построены на механизме колбэков, которые дергаются из тредов с повЫшенным приоритетом.
В таких случаях информация часто расположена достаточно плотно (особенно в случае с аудио), а временны́е отклонения в её воспроизведении хорошо заметны ушам, глазам и прочим человеческим органам. Поэтому N выбирается небольшим, измеряется в миллисекундах, и часто используется значение 1.
Высокое разрешение необходимо не для ровного плейбэка, а для достижения низкой задержки. Что, в частности, очень актуально для real-time музыкального ПО.
Если сильно хочется таймер высокого разрешения на win32, то ничего лучше недокументированного API Вам не найти. Как уже писали выше это ф-ции NtSetTimerResolution и NtDelayExecution, но даже первой хватить, чтобы "стандартные" таймерные API стали более отзывчивыми. Также не забываем задать приоритет потоку таймера выше нормального, без этого NtSetTimerResolution может не спасти.
Да вся наша жизнь – это сплошное преодоление препятствий.
Д. Канеман в своей книге "Думай медленно, решай быстро" дает посыл, что бОльшую часть в формировании успешной карьеры/жизни/… играет удача. Если человеку повезло оказаться в нужном месте в нужное время, то его шансы на успех многократно возрастают.
PS: Официальная документация cmake зачастую только добавляет вопросов в поиске решения проблемы. ИМХО больше пользы от ресурсов посвященных современным способам использования cmake, например https://cliutils.gitlab.io/modern-cmake/
Если внешняя зависимость поддерживает cmake, то для ExternalProject, начиная с 3.11, есть лучшая альтернатива — FetchContent. Она стягивает зависимость в configure time, что заменяет головняки подлючения к основному проекту простым add_subderictory.
Ок, резиновый int не переполнися пока есть свободная RAM.
Но тогда появляется другая проблема — сложность арифметических операций будет пропорциональна размерам num, den. Сложность алгоритмов становится неопределенной.
С помощью одного значения BigInt мы можем представлять произвольно большие целые числа. Но если мы создадим пару из целых чисел, то сможем представлять произвольно большие или маленькие числа.
Можем, но практического смысла в этом нет, т.к. арифметические операции с рациональными дробями могут очень быстро раздувать числитель и знаменатель до достижения переполнения. Например, если в цикле складывать числа с разными знаменятелями, метод simplify перестанет справляться со своей задачей. Решая эту проблему, мы введем погрешность, заменив simplify на нормализацию и… изобретем float
Как минимум не помешают гарантии того, что аккумулятор не воспламенится и не сожгет владельца. Или пролитый чай не приведет к короткому замыканию и поражению электрическим током.
Потому, что синхронизация плейбэчных мультимедиа графов должа происходить в конечной точке — аудио/видео рендере, а не где-то по пути перед декодером.
Так работают медиафреймворки DirectShow/GStreamer/OpenMAX и в них нет таких детских болячек, как в сабжевой статье.
Разумеется, если мы пишем аудио рендер, например на Qt, с использованием QAudioOutput, то должны повысить приоритет потоку, разгребающему входную очередь до QThread::TimeCriticalPriority. В противном случае получим заикания.
У нетфликс своеобразное решение, они подпирают аудио/видео ветки посередине.
При том, что потом будет еще один подпор на рендере (скорость работы DMA для звукового ЦАП никто под нас подстраивать не будет, оно потребляет данные монотонно со скоростью штатного кварцевого генератора).
Похоже, что у нетфликса контент предзакодирован специально для их плеера(ов).
В результате декодеры работают с идеальными входными данными и плеерописателям можно "не напрягаться"
Да Вы, батенька, шутник. FFmpeg - по сути стал стандартом мультимедиа API. Такие компании, как Intel и nVidia в составе сових SDK для аппаратного сжатия сами пишут модули для инфраструктуры FFmpeg. Большинство медиаплееров, пригодных для практического использования, содержат в своей основе FFmpeg явно или косвенно (например, через bad или ugly плагины GStreamer'a).
Любопытно, а в более сложных CISC инструкциях типа REP (привет memcpy) тоже нет подкапотного разваливания на микрокод и все сделано по-настоящему аппаратно?
Формату JPEG в этом году исполнилось 30 лет, нужно отдать должное его разработчикам, т.к. он до сих пор имеет свою нишу.
В сжатии изображений преобразование предназначено для минимизации среднеквадратичной ошибки, вносимой квантованием. Оптимальным считается преобразование Карунена-Лоэва, а DCT-II является его наилучшим приближением для сжатия изображений. То есть, пеобразование является необходимым этапом при сжатии с Потерями.
Если интерес представляет именно сжатие без потерь, стоит обратить внимание на соответсвующие инструменты кодирования:
предсказание DCT коэффициентов по соседним (уже закодированным) блокам (H.263/MPEG-4 Part 2)
предсказание пикселей текущего блока, по восстановленным соседним (Intra predict, H.264 и т.п.)
сегментация изображения с целью кодирования больших равномерных областей бОльшими блоками (квадро-дерево H.265 и т.п.)
для "Screen" контента использовать сжатие с палитрой (H.265)
продвинутые алгоритмы энтропийного сжатия остаточной информации Huffman (с фиксированными таблицами) -> CAVLC -> CABAC
В современных форматах сжатия изображений это реализовано в том или ином виде.
С одной стороны результат вполне ожидаемый, т.к. обе карты имеют на борту один модуль NVENC (см. [1]).
С другой стороны результат странный, т.к. в связи с более высокой частотой чипа "The performance should scale according to the video clocks as reported by nvidia-smi for other GPUs of every individual family" (см. [2]). Как вариант, прирост тактовой частоты был недостаточен для того, чтобы успеть еще один профиль кодирования на целевом разрешении, но это не точно.
Литература
[1] https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new
[2] https://docs.nvidia.com/video-technologies/video-codec-sdk/nvenc-application-note/index.html#nvenc-performance
Это на самом деле очень интересный момент. По идее сабжевый агрегат косвенно несет ответственность за здоровье. А следовательно должен пройти серьезную сертификацию, и до кучи, если является средством измерения внесен в единый гос реестр СИ. И вот в этом процессе подобные архитектурные "решения" следовало бы присекать на корню ИМХО.
Поддерживаю, 2^32 уровней квантования хватит, чтобы залезть в область тепловых шумов компонент РЭА, что сводит на нет всякий смысл АЦП таких разрядностей.
Как-то так я полагаю: https://docs.microsoft.com/en-us/windows/win32/multimedia/using-a-callback-function-to-manage-buffered-playback
Производящий поток пушит данные в MIDI устройство вызовами midiOutLongMsg() или midiStreamOut(), а в колбэке MOM_DONE получаем уведомление, что железяка воспроизвела нотки и можно в нее пушить дальше. Но это не точно.
Воспроизведение аудио - это по сути вывод последовательности дискретных отсчетов в ЦАП. ЦАП работает с фиксированной частотой дискретизации. В него невозможно запихать данных больше, чем размер буфера, стоящего перед ним. Устройство вывода звука "подпирает" источник данных и это нормально.
Я не говорил, что данные проекты используют антипаттерн. Тут скорее сделан ошибочный вывод того, как они работают на основе того факта, что их процесс в планировщеке ОС имеет бОльшее разрешение системного таймера. Без какого-либо анализа кодовой базы.
Много лет назад занимался разработкой нативной кодек SDK для мобильных платформ, с тех пор сохранились заметки на тему рендеров: https://docs.google.com/document/d/1T9T65-NN92e_xHzr4AV15LSHdhMAmTaJy4XQsirwaws/edit?usp=sharing
См. главу 2 Вывод звука. Объяснения там, конечно, на уровне "сначала рисуем один овал, затем другой, а потом дорисовываем сову", но поверхностная суть просматривается.
В случае win32 можно попробовать waveOut из https://docs.microsoft.com/en-us/windows/win32/api/mmeapi/
Либо что-то еще, например DirectShow аудио рендер, но это уже совсем другая история (с)
Это антипаттерн. Все вменяемые audio API построены на механизме колбэков, которые дергаются из тредов с повЫшенным приоритетом.
Высокое разрешение необходимо не для ровного плейбэка, а для достижения низкой задержки. Что, в частности, очень актуально для real-time музыкального ПО.
Если сильно хочется таймер высокого разрешения на win32, то ничего лучше недокументированного API Вам не найти. Как уже писали выше это ф-ции NtSetTimerResolution и NtDelayExecution, но даже первой хватить, чтобы "стандартные" таймерные API стали более отзывчивыми. Также не забываем задать приоритет потоку таймера выше нормального, без этого NtSetTimerResolution может не спасти.
Если хочется точности сверх 1мс, то таймеры можно комбинировать со спинлоками, вот очень интерсеная статья на данную тему: https://timur.audio/using-locks-in-real-time-audio-processing-safely
Ваш новый велосипед похож на Forward Error Correction FEC, используемый в частности для транспорта мультимедиа контента.
Д. Канеман в своей книге "Думай медленно, решай быстро" дает посыл, что бОльшую часть в формировании успешной карьеры/жизни/… играет удача. Если человеку повезло оказаться в нужном месте в нужное время, то его шансы на успех многократно возрастают.
Можно, но так никто не делает, т.к для этого управляющий ток должен быть больше тока коммутируемой нагрузки. Поэтому всё-таки нельзя
PS: Официальная документация cmake зачастую только добавляет вопросов в поиске решения проблемы. ИМХО больше пользы от ресурсов посвященных современным способам использования cmake, например https://cliutils.gitlab.io/modern-cmake/
Если внешняя зависимость поддерживает cmake, то для ExternalProject, начиная с 3.11, есть лучшая альтернатива — FetchContent. Она стягивает зависимость в configure time, что заменяет головняки подлючения к основному проекту простым add_subderictory.
Ок, резиновый int не переполнися пока есть свободная RAM.
Но тогда появляется другая проблема — сложность арифметических операций будет пропорциональна размерам num, den. Сложность алгоритмов становится неопределенной.
Можем, но практического смысла в этом нет, т.к. арифметические операции с рациональными дробями могут очень быстро раздувать числитель и знаменатель до достижения переполнения. Например, если в цикле складывать числа с разными знаменятелями, метод simplify перестанет справляться со своей задачей. Решая эту проблему, мы введем погрешность, заменив simplify на нормализацию и… изобретем float
Будьте любезны, также интересует стоимость разработки механики, износостойких композиционных материалов, схемотехники, ПО, сборки и настройки.
Как минимум не помешают гарантии того, что аккумулятор не воспламенится и не сожгет владельца. Или пролитый чай не приведет к короткому замыканию и поражению электрическим током.
Вы не правы. В комментарии выше описал почему
Потому, что синхронизация плейбэчных мультимедиа графов должа происходить в конечной точке — аудио/видео рендере, а не где-то по пути перед декодером.
Так работают медиафреймворки DirectShow/GStreamer/OpenMAX и в них нет таких детских болячек, как в сабжевой статье.
Разумеется, если мы пишем аудио рендер, например на Qt, с использованием QAudioOutput, то должны повысить приоритет потоку, разгребающему входную очередь до QThread::TimeCriticalPriority. В противном случае получим заикания.
У нетфликс своеобразное решение, они подпирают аудио/видео ветки посередине.
При том, что потом будет еще один подпор на рендере (скорость работы DMA для звукового ЦАП никто под нас подстраивать не будет, оно потребляет данные монотонно со скоростью штатного кварцевого генератора).
Похоже, что у нетфликса контент предзакодирован специально для их плеера(ов).
В результате декодеры работают с идеальными входными данными и плеерописателям можно "не напрягаться"