![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Конвейер в картинках
Sep. 9th, 2012 03:55 pmНа днях занимался тем, что генерил интересные картинки, долго их созерцал, а по результату созерцания успешно ускорял код, не трогая в нем ни строчки. Теперь вот хочу поделиться.
Есть у меня программа, которая обрабатывает видео и показывает в процессе две картинки - "было" и "стало" (текущий обрабатываемый кадр). Как обычно поставлен такой процесс? Сплиттер читает очередной сжатый кадр из входного файла, декодер распаковывает его в картинку, нужная часть картинки рисуется в окошке "было", кадр как-то обрабатывается (в моем случае увеличивался методом super resolution), нужная часть обработанного кадра рисуется в окошке "стало", дальше компрессор его сжимает, а муксер пишет в выходной файл. Параллельно сплиттер также читает порции звука, и либо сразу отдает муксеру для записи в выходной файл, либо через цепочку декодер-энкодер. Делать все в описанном порядке не слишком эффективно, т.к. ядер обычно несколько, надо бы их загрузить. Для этого в цепочку были добавлены фильтры-параллелайзеры: такой фильтр получает порцию данных, складывает ее в очередь и тут же возвращает управление. В другом потоке он из очереди уже скармливает данные нижестоящему фильтру (работает все это в DirectShow, там все упомянутые компоненты - сплиттеры, кодеки, муксеры и пр. называются фильтрами и соединяются в граф, становясь его вершинами). В результате, как только декодер отдал распакованный кадр, он может сразу заняться распаковкой следующего кадра, а отданный только что кадр будет обрабатываться параллельно. Аналогично, как только кадр обработан, можно сразу заняться обработкой следующего, а сжатием его энкодер будет заниматься в отдельном потоке. Конвейер!
Столкнувшись со странными проседаниями производительности на двухядерном ноутбуке, я решил попристальнее изучить, как на практике работает этот конвейер, и где возникают тормоза. Для этого разные его части стали отмечать основные события в лог, но в текстовом виде его изучать оказалось трудно, поэтому был сделан конвертер таких логов в SVG, получились интересные картинки.
( Read more... )
Есть у меня программа, которая обрабатывает видео и показывает в процессе две картинки - "было" и "стало" (текущий обрабатываемый кадр). Как обычно поставлен такой процесс? Сплиттер читает очередной сжатый кадр из входного файла, декодер распаковывает его в картинку, нужная часть картинки рисуется в окошке "было", кадр как-то обрабатывается (в моем случае увеличивался методом super resolution), нужная часть обработанного кадра рисуется в окошке "стало", дальше компрессор его сжимает, а муксер пишет в выходной файл. Параллельно сплиттер также читает порции звука, и либо сразу отдает муксеру для записи в выходной файл, либо через цепочку декодер-энкодер. Делать все в описанном порядке не слишком эффективно, т.к. ядер обычно несколько, надо бы их загрузить. Для этого в цепочку были добавлены фильтры-параллелайзеры: такой фильтр получает порцию данных, складывает ее в очередь и тут же возвращает управление. В другом потоке он из очереди уже скармливает данные нижестоящему фильтру (работает все это в DirectShow, там все упомянутые компоненты - сплиттеры, кодеки, муксеры и пр. называются фильтрами и соединяются в граф, становясь его вершинами). В результате, как только декодер отдал распакованный кадр, он может сразу заняться распаковкой следующего кадра, а отданный только что кадр будет обрабатываться параллельно. Аналогично, как только кадр обработан, можно сразу заняться обработкой следующего, а сжатием его энкодер будет заниматься в отдельном потоке. Конвейер!
Столкнувшись со странными проседаниями производительности на двухядерном ноутбуке, я решил попристальнее изучить, как на практике работает этот конвейер, и где возникают тормоза. Для этого разные его части стали отмечать основные события в лог, но в текстовом виде его изучать оказалось трудно, поэтому был сделан конвертер таких логов в SVG, получились интересные картинки.
( Read more... )
