"WASAPI Renderer" - сдвиг интервалов частоты кадров

Evgeniy1990 · 27 мая 2016, 23:05:44

Краткое описание проблемы:

В нашем "MPC Audio Renderer", при использовании режимов WASAPI, присутствует такое скрытое явление, а если точнее, то явный скрытый баг, как сдвиг интервалов частоты кадров, а если более точнее, то отклонение частоты от нормы. Что оно (т.е. явление) из себя представляет? Оно представляет собой некий "сдвиг частоты", как вперед (т.е. в большую сторону), так и назад (т.е. в меньшую сторону), в зависимости от видео файлов, их частоты кадров, а также и от используемых методов синхронизации.

Данное скрытое явление (скрытый баг) может проявляться:

1. При открытии различных видео файлов
2. При переходе на следующий, или предыдущий видео файл в каталоге, или по списку (плейлисту)
3. Начиная с SVN r1543 - при перемотке
4. Начиная с SVN r1543 - при изменении настроек на лету (более редкое проявление)

Пример интервала сдвига частоты кадров в большую сторону:

Рассмотрим сам сдвиг частоты кадров - вперед, т.е. в большую сторону.

Итак, у нас есть некий видео файл, с постоянной частотой кадров = 23.976 FPS, т.е. "CFR = 23.976 FPS".
Если рендереры видео и аудио работают корректно, то частота кадров, во время всего процесса воспроизведения, полностью сохраняется и остается неизменной до самого конца, т.е. 23.976.

Отсюда можно выделить такой интервал ее работы, т.е. работы самой частоты кадров: [23.97 -> 23.98 -> 23.97] - это нормальный и при том совершенно корректный рабочий интервал частоты кадров, т.е. она какой была, такой и осталась до самого окончания воспроизведения.

Теперь рассмотрим, что же происходит при переходе на следующий видео файл с точно такой же постоянной частотой кадров = 23.976 FPS.

В случае перехода на следующий видео файл с аналогичной постоянной частотой кадров, может произойти сдвиг частоты кадров - вперед, т.е. вместо 23.976 FPS, в свойствах видео-рендерера, будет следующий интервал:
[23.88 -> 23.92 -> 23.87 -> 24.03 -> 24.04 -> 24.26], т.е. какая угодно частота кадров, но только не 23.976 FPS.
Соответственно, в случае сдвига, в свойствах видео-рендерера всегда будут показаны отклонения, а все потому, что работает совершенно не та частота кадров, а если выразиться еще точнее, то просто некорректно становится работать сама частота кадров.

Причем, можно сказать, что начался некий метод перебора частот кадров, т.е. плеер не смог подобрать нужную частоту кадров в нужный момент времени, а точнее, например, во время открытия видео файла, или же при других условиях, по непонятной причине, и начал перебирать все возможные частоты кадров, которые по его мнению, являются приближенными, или же более близкими к 23.976 FPS.

Скриншоты:

Первый: обычный типичный сдвиг частоты кадров от нормы - вперед: https://yadi.sk/i/ZrlzMdvts4r4T
Второй: более агрессивный сдвиг частоты кадров от нормы - вперед: https://yadi.sk/i/J-L8VfbKs4r8i

Чем большее, сильнее и агрессивнее сдвиг частоты кадров - вперед, или же назад, тем больше пропущенных кадров и тем сильнее и выше значения отклонений в статистике и свойствах видео-рендерера.

Небольшие комментарии:

1. Почему данное явление является скрытым и вообще скрытым багом?

Потому, что даже несмотря на явные отклонения частоты кадров от нормы, на большинстве более легких, или средних по тяжести видео файлах, данный баг не вызывает каких-либо проблем с их воспроизведением.

2. Тогда в чем его опасность и почему лучше всего стоит от него избавиться?

Как уже было сказано, данный скрытый баг не представляет никакой угрозы для обыкновенных видео файлов, но зато может представлять очень серьезную угрозу на более тяжелых видео файлах, к которым также относятся видео файлы с частотой кадров = 60.00 FPS. Если, не дай бог, на них произойдет хотя бы малейший сдвиг, особенно с частотой кадров, равной 60 FPS, то мы, в результате получим ступор, это в лучше случае, а в худшем, кроме него, получим зависание самого плеера, т.е. самой программы, что в дальнейшем приведет к падению видео и аудио драйверов, в результате чего может произойти BSOD, с указанием в его дампе якобы на проблемы со стороны видео и аудио драйверов, но понятно, что дело не в них. Тем более, если опять же взять "Sanear" и сравнить с ним работу, то в нем вообще нет данного явления, там коррекция работает абсолютно нормально и полностью корректно на все 100%.

Aleksoid1978 · 28 мая 2016, 03:52:57

Вот я охреневаю, извините за грубость, - опять просто БОЛЬШАЯ КУЧА текста и по большому счету ни о чем.
По делу можно было описать в 2-3 строчки. И все.

Ну и опять же - не могу подтвердить. Я что дома что на работе использую WASAPI вывод в режиме Exclusive - если бы что-то было плохое, давно бы заметил. Так же очень много проверял перемотку и изменение настроек в последнем изменении - все гуд.

Evgeniy1990 · 28 мая 2016, 04:49:11

Цитата: Aleksoid1978Ну и опять же - не могу подтвердить. Я что дома что на работе использую WASAPI вывод в режиме Exclusive - если бы что-то было плохое, давно бы заметил. Так же очень много проверял перемотку и изменение настроек в последнем изменении - все гуд.

Проверьте пожалуйста режим "Shared". У меня такое чувство, что он у нас работает гораздо хуже.

Aleksoid1978 · 28 мая 2016, 05:09:28

Скажу честно - сам по себе режим Shared не особо интересен. В нем нет смысла - так можно юзать и обычный DS вывод, звук будет такой же, т.к. работает системный микшер и т.д.

Я конечно поставлю на заметку этот вопрос - но не стоит ожидать в ближайшее время изменений.

V0lt · 28 мая 2016, 05:44:15

Цитата: Aleksoid1978Вот я охреневаю, извините за грубость, - опять просто БОЛЬШАЯ КУЧА текста и по большому счету ни о чем.
По делу можно было описать в 2-3 строчки. И все.

Раз уж прочитал, расскажи в чем дело? :lol:

Aleksoid1978 · 28 мая 2016, 06:32:08

Да я и сам не особо понял - вроде как типа fps изменяется при переходе на новый файл или при перемотке. Но что в этом страшного - не понимаю. Это же не показатель.
[merge_posts_bbcode]Добавлено: 2016-05-28 13:32:08[/merge_posts_bbcode]

Ну и тем более я ну никак у себя не вижу чего-то страшного. После перемотки, особенно если очень сильно мотать, всегда значение fps прыгает. И не важно какой аудио вывод.

V0lt · 28 мая 2016, 07:06:14

Уф, прочитал. Было более-менее терпимо до появления гипотетических зависаний и BSOD-ов. Я даже не знаю, как это цензурно комментировать.

Aleksoid1978 · 28 мая 2016, 07:46:00

Но при этом есть пропуски кадров только если не попасть в ключевые при перемотке.

Evgeniy1990 · 31 мая 2016, 14:39:34

Цитата: Aleksoid1978Да я и сам не особо понял - вроде как типа fps изменяется при переходе на новый файл или при перемотке. Но что в этом страшного - не понимаю. Это же не показатель.
[merge_posts_bbcode]Добавлено: 2016-05-28 13:32:08[/merge_posts_bbcode]

Ну и тем более я ну никак у себя не вижу чего-то страшного. После перемотки, особенно если очень сильно мотать, всегда значение fps прыгает. И не важно какой аудио вывод.

FPS не то что изменяется, она просто сдвигается вперед, отчего уже нарушается точность, особенно в плане корректности перемотки. А если выразиться еще более точнее, то FPS просто "теряется", т.е было 23.976 (23.97), а становится неизвестно что [23.88/23.92/23.87/24.03/24.26]. Т.е. нарушилась работа постоянной частоты кадров и плеер методом перебора приближенных частот, начал перебирать значения, которые, как он считает, наиболее близкие к 23.976 FPS. Понятно, что перемотка уже корректно работать не будет, поскольку FPS стала нестабильной. Всегда будут пропущенные кадры, даже при быстрой перемотке строго по ключевым кадрам.
Сюда же и относится ситуация, когда в некоторых видео файлах отсутствуют данные.

V0lt · 01 июня 2016, 21:08:15

Evgeniy1990
Что бы говорить о баге, надо проверить всего два режима: DirectSound и WASAPI Shared - на одном устройстве, на одном файле, проделывая одни и те же действия, при этом включить статистику и следить не только за fps, но и загрузкой CPU.

Если загрузка CPU невысокая (в идеале лучше проверять загрузку по ядрам), а fps при этом ведет себя по разному (допустим в одном случае достаточно быстро восстанавливается до номинальных, а в другом, допустим, зависла на больших значениях) тогда да - можно констатировать возможную проблему.

А указанные скриншоты почти ни о чем не говорят. Нужен скриншот встроенной (Ctrl+J) статистики с графиками и прочим.

Evgeniy1990 · 01 июня 2016, 23:10:20

Цитата: V0ltEvgeniy1990
Что бы говорить о баге, надо проверить всего два режима: DirectSound и WASAPI Shared - на одном устройстве, на одном файле, проделывая одни и те же действия, при этом включить статистику и следить не только за fps, но и загрузкой CPU.

Если загрузка CPU невысокая (в идеале лучше проверять загрузку по ядрам), а fps при этом ведет себя по разному (допустим в одном случае достаточно быстро восстанавливается до номинальных, а в другом, допустим, зависла на больших значениях) тогда да - можно констатировать возможную проблему.

А указанные скриншоты почти ни о чем не говорят. Нужен скриншот встроенной (Ctrl+J) статистики с графиками и прочим.

Уже давным давно я сравнил работу DirectSound-аудио рендерера и WASAPI-рендерера, причем сравнивал на одном устройстве - "Realtek ALC889A", выполнив один и тот же алгоритм воспроизведения.

Что значит "возможная" проблема? Это явная и реальная проблема.

Вам, конечно, мои скриншоты ни о чем не говорят, зато мне говорят о реальной проблеме.
Вы сами себе задайте такой интересный вопрос - "как часто в свойствах видео-рендерера, во время воспроизведения видео файла, я вижу "плавающие" значения FPS и циферки, вроде 2 -2 -1, или 1 -4 3, если у меня видео файл имеет постоянную частоту кадров?"

Хорошо, я сделаю вам скриншоты со статистикой рендерера, но я сомневаюсь, что они вам хоть что-то скажут, или покажут, если вам даже скриншоты со свойствами видео-рендерера ничего не сказали.
[merge_posts_bbcode]Добавлено: 2016-06-01 23:10:20[/merge_posts_bbcode]

Я вам скажу даже, что при использовании "Sanear: WASAPI: Shared Mode" такой проблемы вообще нет и не проявляется.
Какой смысл сравнивать DirectSound, если баг конкретно в нашем MPC Audio Renderer?

Я могу вам прямо и точно сказать, что эта проблема со сдвигом частоты кадров появилась после того, как были добавлены эти методы синхронизации "Аудио по видео" и Видео по аудио", как будто бы без них наш WASAPI-рендерер не мог нормально работать. На самом деле, без данных методом синхронизации, наш MPC Audio Renderer работал просто превосходно, в прошлом я его сам лично очень тщательно тестировал и даже пользовался им.

Но, как обычно, нашлись те, которым не хватало нормальной обработки кривых файлов, при использовании WASAPI, из-за чего и были введены два метода синхронизации.

Еще тогда я был удивлен этим двум методам, которые являются явными костылями только лишь для того, чтлюы обрабатывать одну лишь единственную во всем мире ситуацию, когда аудио и видео данные имеют разную длину.

Скажу так, по поводу разной длины видео и аудио данных - это полнейший изврат, тем более в реале, на практике, таких видео файлов мы не получим и даже не встретим. А если и встретим, то просто скажем и сделаем вывод, что они всего лишь навсего - просто кривые. Нет смысла делать костыли под кривые видео файлы, да еще и с разной длиной данных.

Отсюда и имеем теперь на нормальных видео файлах такую вот проблему со сдвигом частоты кадров, потому что уже ясно то, что плеер, а точнее аудио-рендерер, используя эти методы синхронизации, почему-то пытается сделать подгонку под более точную и близкую частоту кадров, чего он вообще делать не должен.

Если уж хочется сделать подстройку под видео файлы с разной длиной данных, то это надо делать опционально, а не всегда, тем более с помощью методов синхронизации, которые также работают неточно, вероятность работы их корректности 50 на 50. А на тяжелых файлах - еще ниже. Искажения - прямое тому подтверждение.

P.S. На вашем месте, я бы сделал включение этих методов синхронизации через специальную опцию, но никак не сразу, поскольку подгонка аудио и видео данных, тем более для видео файлов с постоянной частотой кадров, вообще не нужна - это только нарушает корректность их работы, не говоря уже про перемотку и все остальное.

Aleksoid1978 · 02 июня 2016, 02:04:27

И опять ОГРОМНАЯ куча текста ... вот такие "поэмы" даже читать не хочется до конца, ей богу.

Evgeniy1990 · 02 июня 2016, 15:39:44

Цитата: Aleksoid1978И опять ОГРОМНАЯ куча текста ... вот такие "поэмы" даже читать не хочется до конца, ей богу.

Да не обращайте, пожалуйста, внимание на огромное количество текста, я ведь все-таки сразу предупредил, что данная тема, данный баг-репорт будет немаленьким.

Я всего лишь более подробно расписал ситуацию, что когда и откуда появилось, чтобы вам было понятно.
Я просто не знаю, как в "двух словах" вам это объяснить, тем более, что вы у себя это не видите и воспроизвести не можете. Вот поэтому я и описал более подробно всю сложившуюся ситуацию.
[merge_posts_bbcode]Добавлено: 2016-06-02 15:39:44[/merge_posts_bbcode]

Цитата: V0ltНужен скриншот встроенной (Ctrl+J) статистики с графиками и прочим.

V0lt/Aleksoid1978:

Пожалуйста, как и обещал, я сделал для вас два скриншота со статистикой видео-рендерера:

Первый скриншот - нормальная частота кадров: https://yadi.sk/i/nqQLF5qIsCnyK
Второй скриншот - ненормальная частота кадров: https://yadi.sk/i/Bmx-ptLTsCo53

Обратите пожалуйста внимание на частоту кадров (Frame rate) и на график воспроизведения.

В случае нормальной частоты кадров, график выглядит практически, или почти прямым.
В случае сдвига частоты кадров, график выглядит более волнистым и кривым.

Не знаю, помогут ли вам эти скриншоты, но раз вы попросили их сделать, я их разумеется сделал.

По поводу нагрузки на CPU - в случае нормальной частоты кадров и ненормальной, особой нагрузки на CPU нет, поскольку видео файл воспроизводится в аппаратном режиме - DXVA2.

Aleksoid1978 · 02 июня 2016, 16:20:42

Ну ок - скрины посмотрели. Но как такого добиться ?? Что надо сделать, какие условия ??

Evgeniy1990 · 02 июня 2016, 23:01:18

Цитата: Aleksoid1978Ну ок - скрины посмотрели. Но как такого добиться ?? Что надо сделать, какие условия ??

Данная проблема проявляется при разных условиях, я их все уже расписал в первом посте.

Есть один алгоритм воспроизведения, при котором проблема проявляется всегда, или ровно через 1 раз, по крайней мере у меня, у вас - не знаю. И именно благодаря ему, я и сделал для вас свои два скриншота.

По поводу скриншотов:

Первый скриншот, с нормальной частотой кадров, я сделал после обыкновенного открытия файла, т.е. просто запустил видео файл, при условии: "Автомасштаб = 100%".

Второй скриншот, но уже с ненормальной частотой кадров, этого же самого видео файла, я сделал иначе, по одному алгоритму воспроизведения, при котором проблема проявляется всегда, или ровно через 1 раз.

Условия:

1. Широкоформатные, или квадратные видео файлы, т.е. HD, или SD, без разницы
2. Наличие работы опции "Автомасштаб: 100%"
3. Полноэкранный режим работы
4. Автоматический переход в полноэкранном режиме работы на следующий файл в каталоге (папке)
5. Использование "MPC Audio Renderer (WASAPI: Shared/Exclusive Mode\'s)"

Итак, алгоритм воспроизведения (при условии автоматического перехода на следующий файл в папке в полноэкранном режиме):

1. Скачать эти два видео файла: https://yadi.sk/i/jVBo4L1RsDTrE и https://yadi.sk/i/Sgx76UeYsDTtQ
2. Положить их рядом друг с другом в одну папку
3. Включить опцию "Автомасштаб: 100%" и запустить первый видео файл - первую серию
4. После ее открытия, перейти в полноэкранный режим
5. В полноэкранном режиме навести курсор мышки на тулбар и нажать на кнопку "Следующий"
6. После перехода на следующий файл в папке, открыть свойства видео-рендерера, или статистику видео-рендерера.

Фактический результат: в статистике видео рендерера можно заметить что частота кадров (Frame rate) будет уходить за пределы 24 FPS, вместо нормальных 23.976 FPS, при этом график воспроизведения будет более волнистым.

Ожидаемый результат: в статистике видео рендерера должна быть частота кадров, не выходящая за пределы 23.978 FPS, при этом график воспроизведения должен быть практически ровным.