Похоже, что у нетфликса контент предзакодирован специально для их плеера(ов).
В результате декодеры работают с идеальными входными данными и плеерописателям можно "не напрягаться"
А что в итоге?
В сорцах Android есть баг, ок.
Из оригинальной статьи не понятно:
Код Netflix нативный или на Java/Kotlin?
Какое API используется для декодирования: штатный MediaCodec из Android SDK/NDK?
2.1 Если да, то почему бы не пихать данные в декодеры с максимальной скоростью? (синхронизация ведь все-равно произойдет на стороне рендеров)
Как была решена проблема?
3.1 Увеличением размера буферов
3.2 Использованием других примитивов синхронизации (а какие были до этого?)
3.3 Перепрошивкой всех приставок более новой версией ОС?
...
Это классическая ситуация, когда в прейбечном пэйплайне одна из веток (аудио/видео) подпирает другую.
Собсвенно для решения подобных проблем и делают асинхронные очереди по каждой ветке.
Забавно, что автору было дешевле изучить код AOSP, чем адаптировать свой код к суровой реальности.
Поправка — сцена с движением "blue_sky" https://media.xiph.org/video/derf/
PS: Я делал бенчмарки когда он был еще JEM'ом, но идея вроде как сохранилась
В драфте VVC есть "affine motion compensation": https://jvet.hhi.fraunhofer.de/
Работает ооочень медленно (енкодер)
На сценах c вращением типа "In to tree" из стандартных тестовых последовательностей
рвет в тряпки все классические блочные кодеры (прирост порядка +40% по BD-Rate)
Это называется метод ближайшего соседа. Картинка получается грубой, рваной, неприятной. Так происходит потому, что в конечном изображении была использована очень малая часть исходных пикселей
Быть может из-за эффекта наложения спектров?
Для уменьшения изображения — фильтруем сигнал ФНЧ, а потом прореживаем
Для увеличения — разбавляем сигнал нулями и потом фильтруем ФНЧ
Частота среза ФНЧ = ширине спектра сигнала после уменьшения / до увеличения
Свертка технически это и есть КИХ фильтр, АЧХ которого определяют коэффициенты свертки.
XCode Instruments умеет считать HW счетчики производительности.
Можно выбрать из большого списка, что интересует, например кэш промахи по данным L1.
Правда кол-во одновременно наблюдаемых счетчиков ограничено, но я думаю это ограничение конкретного CPU.
Правда на ARM, к сожалению, performance counters не доступны, но с другой стороны v-tune эту архитектуру вообще не поддерживает.
XCode Instruments не зависит от исходного кода, ему нужен бинарник и файл с символами.
Для полноты картины я бы использовал оба типа профайлеров.
У нас как раз такая практика — "настоящим" профайлером ищем узкие места, а потом обкладываем их в коде замерами, подобными сабжевым, и вперед оптимизировать.
Получаем преимущества обоих методов
точная локализация узких мест инструментальным профилированием (xcode, vtune, etc)
быстрые и повторяемые замеры ручным профилированием во время решения найденных проблем
Да, чтобы выяснить минимальный размер кэш линии, как было сказано в статье.
А еще эти ядра могуть уходить в offline.
Не знаю будет ли в этом случае работать set_affinity.
Эти советы хороши лишь для студентов, разбирающихся на коленке в реализации конкретного алгорима.
Если же рассматривать их с точки зрения реальных задач — это (местами) полнейший треш.
Не использовать готовые библиотеки — долго реализовывать и отлаживать свой велосипед
Ошибки округления (приведение к типу byte) — по максимуму используем арифметику с фиксированной точкой, чтобы оставаться в рамках целочисленных инструкций. Банально потому, что в тот же sse2 вектор влезет в 2 раза больше скаляров short, чем float.
Выход за границы диапазона — однозначно высчитывается на основании разрядности сигнала и коэффициентов фильтра. Из этого и выбирается разрядность скаляров фиксированной точки.
Используй float — см. предыдущий пункт, а также таблицу скоростей simd инструкций. У float латентность в несколько раз выше.
Используй абстракции, не используй индексацию по массивам — если ваш студент не может перебрать массив, то не понятно о чем с ним дальше можно разговариавать. Геттеры и сеттеры в данном контексте будут дичайшим бутылочным горлышком.
Путаница ширины и высоты — можно списать на невнимательность, а вот про stride или pitch стоило бы упомянуть, что ширину буфера иногда выгодно сделать кратной (в байтах) размеру кэш линии процессора, чтобы наиболее эффективно обрабатывать соседние строки.
Вангую стаю хейтеров с плакатами оптимизация — это зло!!!
Но вот когда от ваших студентов работодатель потребует realtime, им прийдеься учиться заново.
Не раз убеждался, и до сих пор считаю: то, что на сегодняшних процессорах является оптимизацией, через поколение-два будет замедлять скорость выполнения относительно наивной реализации, через 3-4 поколения будет вообще давать некорректный результат
Старые добрые игры, летающие на современном железе, с Вами не согласны.
Похоже, что у нетфликса контент предзакодирован специально для их плеера(ов).
В результате декодеры работают с идеальными входными данными и плеерописателям можно "не напрягаться"
Получается какая-то антиреклама.
Netflix выявил у себя архитектурную проблему и осознанно отказался фиксить.
А что в итоге?
В сорцах Android есть баг, ок.
Из оригинальной статьи не понятно:
2.1 Если да, то почему бы не пихать данные в декодеры с максимальной скоростью? (синхронизация ведь все-равно произойдет на стороне рендеров)
3.1 Увеличением размера буферов
3.2 Использованием других примитивов синхронизации (а какие были до этого?)
3.3 Перепрошивкой всех приставок более новой версией ОС?
...
Это классическая ситуация, когда в прейбечном пэйплайне одна из веток (аудио/видео) подпирает другую.
Собсвенно для решения подобных проблем и делают асинхронные очереди по каждой ветке.
Забавно, что автору было дешевле изучить код AOSP, чем адаптировать свой код к суровой реальности.
Из Элекарда.
Поправка — сцена с движением "blue_sky" https://media.xiph.org/video/derf/
PS: Я делал бенчмарки когда он был еще JEM'ом, но идея вроде как сохранилась
В драфте VVC есть "affine motion compensation": https://jvet.hhi.fraunhofer.de/
Работает ооочень медленно (енкодер)
На сценах c вращением типа "In to tree" из стандартных тестовых последовательностей
рвет в тряпки все классические блочные кодеры (прирост порядка +40% по BD-Rate)
Freddy Hardest, REX, Earth Shaker, Blasteroids, Savage
Быть может из-за эффекта наложения спектров?
Для уменьшения изображения — фильтруем сигнал ФНЧ, а потом прореживаем
Для увеличения — разбавляем сигнал нулями и потом фильтруем ФНЧ
Частота среза ФНЧ = ширине спектра сигнала после уменьшения / до увеличения
Свертка технически это и есть КИХ фильтр, АЧХ которого определяют коэффициенты свертки.
XCode Instruments умеет считать HW счетчики производительности.
Можно выбрать из большого списка, что интересует, например кэш промахи по данным L1.
Правда кол-во одновременно наблюдаемых счетчиков ограничено, но я думаю это ограничение конкретного CPU.
Правда на ARM, к сожалению, performance counters не доступны, но с другой стороны v-tune эту архитектуру вообще не поддерживает.
XCode Instruments не зависит от исходного кода, ему нужен бинарник и файл с символами.
У нас как раз такая практика — "настоящим" профайлером ищем узкие места, а потом обкладываем их в коде замерами, подобными сабжевым, и вперед оптимизировать.
Получаем преимущества обоих методов
XCode Instruments ИМХО вполне сравним с V-Tune'ом, бесплатно, без SMS
Да, чтобы выяснить минимальный размер кэш линии, как было сказано в статье.
А еще эти ядра могуть уходить в offline.
Не знаю будет ли в этом случае работать set_affinity.
что-то типа?
Такое возможно сделать в юзерспейсе?
Вот так поворот! Можно уточнить — речь идет о размере кеш линий инструкций или инструкций и данных?
PS: Спасибо за статью
Эти советы хороши лишь для студентов, разбирающихся на коленке в реализации конкретного алгорима.
Если же рассматривать их с точки зрения реальных задач — это (местами) полнейший треш.
Не использовать готовые библиотеки — долго реализовывать и отлаживать свой велосипед
Ошибки округления (приведение к типу byte) — по максимуму используем арифметику с фиксированной точкой, чтобы оставаться в рамках целочисленных инструкций. Банально потому, что в тот же sse2 вектор влезет в 2 раза больше скаляров short, чем float.
Выход за границы диапазона — однозначно высчитывается на основании разрядности сигнала и коэффициентов фильтра. Из этого и выбирается разрядность скаляров фиксированной точки.
Используй float — см. предыдущий пункт, а также таблицу скоростей simd инструкций. У float латентность в несколько раз выше.
Используй абстракции, не используй индексацию по массивам — если ваш студент не может перебрать массив, то не понятно о чем с ним дальше можно разговариавать. Геттеры и сеттеры в данном контексте будут дичайшим бутылочным горлышком.
Путаница ширины и высоты — можно списать на невнимательность, а вот про stride или pitch стоило бы упомянуть, что ширину буфера иногда выгодно сделать кратной (в байтах) размеру кэш линии процессора, чтобы наиболее эффективно обрабатывать соседние строки.
Вангую стаю хейтеров с плакатами оптимизация — это зло!!!
Но вот когда от ваших студентов работодатель потребует realtime, им прийдеься учиться заново.
Угу, иначе велик шанс создать монстра, вызывающего отчуждение у потребителя, привыкшего к родной инфраструктуре
Старые добрые игры, летающие на современном железе, с Вами не согласны.
Ассемблер ассемблеру рознь