Видео 360 не может достичь вывода 60P

Я пытаюсь проверить производительность видео 360 с версией 11.62465, видеовыход 360 не может достигать 60P, когда мы воспроизводим видео FHD @ 60P 360. Декодирование видео будет обновлять видеокадр каждые 14–17 мс, но приложение не может вызывать SbPlayerGetCurrentFrame() через 16 мс, тогда происходит пропуск кадров. Частота пропуска кадров составляет почти 20%. Я попытался использовать chrome://tracing/ для проверки производительности и обнаружил, что иногда растеризатор длился 40 мс, продолжительность процессора составляет всего 8 мс, значит ли это, что возможностей графического процессора недостаточно? Будет ли поток рендеринга кобальта блокироваться другими модулями?

Статус графического процессора


cobalt
person Kai Wang    schedule 05.09.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Если продолжительность ЦП на кадр составляет 8 мс, то это звучит так, как будто GPU недостаточно мощен для достаточно быстрой обработки каждого видеокадра. Поток рендеринга Cobalt никогда не должен блокироваться другими модулями, хотя, возможно, стоит дважды проверить, что ваша реализация SbPlayerGetCurrentFrame() не требует много времени для рендеринга (возможно, он получает блокировку?).

Вы можете использовать chrome://tracing/, чтобы проверить производительность средства визуализации при воспроизведении видео не в формате 360 FHD@60P и сравнить эту производительность с воспроизведением видео в формате 360. Это скажет вам, влияет ли на производительность рендерера процесс декодирования в текстуру или нет.

person Andrew Top    schedule 05.09.2017
comment
Спасибо за ваше объяснение. В нашем дизайне только декодирование в текстуру будет использовать графический процессор для рендеринга, а не 360-градусное видео будет использовать видеотракт HW. Мы не можем это сравнивать. Мы сохраним последний кадр вывода видео, а SbPlayerGetCurrentFrame() немедленно получит последний кадр без какой-либо блокировки. Сейчас мы проверяем производительность графического процессора. - person Kai Wang; 06.09.2017
comment
Мы используем DS5 для проверки загрузки графического процессора и обнаружили, что графический процессор всегда работает на 100%, как и в предыдущем комментарии, я думаю, что узкое место находится в части графического процессора. Кстати, есть ли какие-либо предложения о возможностях графического процессора, если мы хотим выполнять рендеринг FHD @ 60P? - person Kai Wang; 06.09.2017
comment
Вы можете изменить SbPlayerOutputModeSupported(), чтобы сообщить, что он поддерживает только декодирование в текстуру, чтобы заставить видео не 360 использовать декодирование в текстуру. Но почти наверняка я думаю, что проблема в большом видео, проходящем через блок графического процессора, независимо от того, 360 это или нет. Пока нет способа предположить, что вы не можете отображать 360-градусное видео с высоким разрешением, хотя мы рассматриваем возможность передачи этой информации через SbMediaCanPlayMimeAndKeySystem(). - person Andrew Top; 08.09.2017
comment
Привет, Эндрю, я изменил SbPlayerOutputModeSupported(), как вы предложили, и производительность видео не 360 FHD @ 60P почти такая же, как у видео 360. - person Kai Wang; 12.09.2017
comment
См. прикрепленное изображение результата DS5: Канал 1 означает, что растеризатор получает текущий кадр, Канал 2 означает, что VDEC уведомил о наличии нового видеокадра. Часть выбора показывает, что Rasterizer получает текущий кадр почти за 33 мс, даже если GPU свободен. Это немного странно. Получит ли растеризатор видеокадр по VSYNC, если нет, то чего он ждет? - person Kai Wang; 12.09.2017
comment
Привет, Кай, похоже, большую часть времени мы рендерим каждые 16 мс (60 кадров в секунду), но время от времени мы рендерим 33 мс (30 кадров в секунду)? Глядя на опубликованный вами снимок экрана, кажется, что 1 проблемный кадр занял немного больше 16 мс для рендеринга, и из-за этого он пропустил событие VSYNC (которое происходит каждые 16 мс), и поэтому он будет придется ждать следующего (поэтому GPU будет простаивать). Другими словами, если для рендеринга кадра требуется (даже немного) больше 16,6 мс, то частота кадров для этого кадра упадет до 30 кадров в секунду. Итак, похоже, что растеризатор ждет VSYNC. - person Andrew Top; 13.09.2017
comment
Привет, Эндрю, рендеринг не выполняется за 16 мс или 33 мс, иногда это будет 22 мс. Рендеринг выполняется в MessageLoop::RunTask и будет запускаться каждые COBALT_MINIMUM_FRAME_TIME_IN_MILLISECONDS (16,4 мс). Возможно, он не ожидает события VSYNC. Когда происходит случай NG, RasterizeRenderTreeToCanvas и VisitRenderTree будут работать долгое время, даже если продолжительность ЦП невелика. Возможно, нам нужно проверить, чего они ждут. - person Kai Wang; 15.09.2017