Во встроенном фильтре-источнике "MPC Matroska Source" наблюдаю значение джиттера выше, чем "LAV Splitter Source"?
Пример видео файла: https://yadi.sk/d/b1VG0aLKpAjKh
При использовании встроенного фильтра-источника: "MPC Matroska Source", в свойствах и статистике видео-рендерера, значение джиттера всегда = 10 мс, при этом сам видео файл воспроизводится нормально.
При использовании внешнего фильтра-источника: "LAV Splitter Source", в свойствах и статистике видео-рендерера, значение джиттера всегда = 1 мс или 0 мс, при этом сам видео файл также воспроизводится нормально.
Проблема:
Если обрезать, или разделить этот видео файл по частям, то после его открытия будут отклонения и пропуски кадров, другими словами - некорректное воспроизведение.
Ссылка на части от данного видео файла: https://yadi.sk/i/NZ-1Le-PpAjto и https://yadi.sk/i/b8En--vFpAjxD
__________________________
отредактировано модератором
Про джиттер не баг вообще.
А резка изменила файл.
Было:Режим частоты кадров : Переменный
Частота кадров : 50,000 кадров/сек
Частота кадров в оригинале : 25,000 кадров/секСтало:Режим частоты кадров : Постоянный
Частота кадров : 25,000 кадров/секПолученные файлы и в других плеерах будут так же колбасить.
Резать интерлейсные MKV на автомате нельзя.
Интересно, у нас вообще есть какие-нибудь программы, те же конвертеры, где можно грамотно разрезать и разделять такие интерлейсные видео файлы на части?
Хмм, mkvmerge GUI v8.3.0 64bit отрезал хорошо, полученные файлы играют нормально.
Цитата: V0ltХмм, mkvmerge GUI v8.3.0 64bit отрезал хорошо, полученные файлы играют нормально.
Спасибо за ответ, скачал и обновил MKVToolNix до последней версии 8.8.0 х64 - сделал обрезку с размером в 100 Мб.
Запустил и проверил - воспроизводится нормально.
[merge_posts_bbcode]Добавлено: 2016-02-22 19:26:01[/merge_posts_bbcode]
Дело в том, что в данном случае, значение джиттера = 10 мс все же имеет значение, т.е. оно влияет на открытие и дальнейшее воспроизведение.
Проверив эту интерлейсную матрешку на видеокарте "ATI Radeon HD 5770", она же "ASUS EAH5770", я полностью убедился в том, что дело здесь нечисто.
Итак, у меня получились следующие результаты, с учетом последних тестов:
Тест 1: Windows 7, x64 + ASUS EAH5770 + "MPC Matroska Source" + EVR Custom:В свойствах и статистике видео-рендерера, значение джиттера оказалось равным 5 мс.
Если обратить внимание только на свойства видео-рендерера, то там значения такие: 5, -7, 3, последние два из которых могут меняться и быть совершенно разными.
Тест 2: Windows 7, x64 + ASUS EAH5770 + "LAV Splitter Source" + EVR Custom:В свойствах и статистике видео-рендерера, значение джиттера равно 1 мс.
Если обратить внимание только на свойства видео-рендерера, то там только одно единственное значение: 1, остальные два значения всегда равны 0.
Тест 3: Windows 8.1 x64 + ASUS EAH5770 + "MPC Matroska Source" + EVR Custom:В свойствах и статистике видео-рендерера, значение джиттера всегда равно 10 мс.
Если обратить внимание только на свойства видео-рендерера, то там только одно единственное значение: 10, остальные два значения всегда равны 0.
Тест 4: Windows 8.1, x64 + ASUS EAH5770 + "LAV Splitter Source" + EVR Custom:В свойствах и статистике видео-рендерера, значение джиттера всегда равно 1 мс.
Если обратить внимание только на свойства видео-рендерера, то там только одно единственное значение: 1, остальные два значения всегда равны 0.
Тест 5: Windows 10 TH2 x64 + ASUS EAH5770 + "MPC Matroska Source" + EVR Custom:В свойствах и статистике видео-рендерера, значение джиттера всегда равно 10 мс.
Если обратить внимание только на свойства видео-рендерера, то там только одно единственное значение: 10, остальные два значения всегда равны 0.
Тест 6: Windows 10 TH2, x64 + ASUS EAH5770 + "LAV Splitter Source" + EVR Custom:В свойствах и статистике видео-рендерера, значение джиттера всегда равно 1 мс.
Если обратить внимание только на свойства видео-рендерера, то там только одно единственное значение: 1, остальные два значения всегда равны 0.
Исходя из этих шести данных тестов, получается следующая картина, в виде разницы в значении джиттера:
1. При конфигурации:
Windows 7, x64 + ASUS EAH5770 + "MPC Matroska Source" + EVR Custom:
В свойствах и статистике видео-рендерера, значение джиттера в данном видео файле всегда равно
5 мс.2. При конфигурации:
Windows 8.1, x64 + ASUS EAH5770 + "MPC Matroska Source" + EVR Custom:
В свойствах и статистике видео-рендерера, значение джиттера в данном видео файле всегда равно
10 мс.
3. При конфигурации:
Windows 10 TH2, x64 + ASUS EAH5770 + "MPC Matroska Source" + EVR Custom:
В свойствах и статистике видео-рендерера, значение джиттера в данном видео файле всегда равно
10 мс.
Т.е. на Windows 7 + ASUS EAH5770 - джиттер строго = 5 мс + также имеются два других рандомных значения, вместо нулей.
На Windows 8.1 и Windows 10, при той же самой видеокарте ASUS EAH5770, джиттер всегда строго равен 10 мс, при этом два других значения в свойствах видео-рендерера всегда равны 0.
Очень странно, на одной системе джиттер = 5 мс, на других = 10 мс, при использовании нашего фильтра-источника: "MPC Matroska Source".
Если взять внешний фильтр-источник: "LAV Splitter Source", то на новых операционных системах (Win7 - Win10), на любой видеокарте, значение джиттера всегда строго равно 1 мс.
Причем, на Windows 7, при конфигурации "
ASUS EAH5770 + "MPC Matroska Source" + EVR Custom", после открытия данной интерлейсной матрешки, наблюдается явление "Frame Repeat", т.е. некое повторение уже прошедших кадров, а также присутствуют и промелькают в самом начале мелкие артефакты, в режиме DXVA2.
Артефакты также присутствуют на Windows 8.1 и Windows 10 TH2, но только на видеокарте "ASUS EAH5770", даже при использовании самых последних версий драйверов: "AMD Catalyst 15.7.1 WHQL".
Если взять NVIDIA GeForce GTX 465, или GTX 650 Ti, то значение джиттера на новых системах (Win7 - Win10), всегда строго равно 10 мс, при этом в самом начале воспроизведения нет артефактов, пропусков кадров после открытия, в отличие от ASUS EAH5770.
Отсюда могу сделать вывод, что пропуски кадров на ASUS EAH5770 - это некорректная работа, а точнее декодирование первых начальных кадров, не случайно же есть артефакты, более низкий джиттер вместо 10 мс - 5 мс, особенно на Windows 7.
И уже, исходя из данного вывода можно сделать окончательное заключение, что у данной интерлейсной матрешки не должно быть джиттера, равного 10 мс, при использовании встроенного фильтра-источника: "MPC Matroska Source".
Ибо с внешним фильтром-источником: "LAV Splitter Source" - ситуация уже совершенно другая...
В общем, надо разобраться с нашим фильтром-источником: "MPC Matroska Source".
Вот ясно видно, даже по тестам, что где-то что-то работает не так, т.е. здесь все же есть некий баг, во только в каком он месте - непонятно, если не в MPC Matroska Source, то где тогда он может быть?
P.S. Вам, уважаемый
V0lt, я скажу так, что при 5 мс, даже сам плеер ведет себя слегка тяжеловато, как будто бы идет очень сильная на него нагрузка в процессе воспроизведения интерлейсной матрешки.
Что это значит? Вот я открыл эту интерлейсную матрешку, после открытия сдвинул курсор мышки в сторону, при этом он еле-еле сдвинулся в сторону, как будто бы нагрузка на CPU, при DXVA2, составляла 100%. Отсюда и пропуски кадров с артефактами. С LAV Source опять таки все иначе, т.е. например, нет нагрузки, пропусков кадров, даже если они и есть, то их гораздо меньше, т.е. при внешнем фильтре, плеер ведет себя более свободно, чем при встроенном.
Я конечно пробовал увеличить значение размера буфера для встроенных сплиттеров (фильтров-источников) и значение буфера EVR Custom, даже до максимальных, но увы, это, к сожалению, не помогло.
Достаточно интересная проблема - дело в том что видео 25i, но при укладке в MKV почему-то длительность кадра выставляется как для 50fps. Наш сплиттер использует именно это значение для расчета - а вот LAV Source возможно берет значение из H.264 SPS данных - а там как положено указано 25fps.
Отсюда и не совсем корректное проигрывание - особенно если включить VSync.
[merge_posts_bbcode]Добавлено: 2016-02-23 12:01:23[/merge_posts_bbcode]
Вот проверяем как стало - https://yadi.sk/d/YzazqPWRpL8aY
Цитата: Aleksoid1978Достаточно интересная проблема - дело в том что видео 25i, но при укладке в MKV почему-то длительность кадра выставляется как для 50fps. Наш сплиттер использует именно это значение для расчета - а вот LAV Source возможно берет значение из H.264 SPS данных - а там как положено указано 25fps.
Не берет он оттуда данные, нельзя так делать.
Цитата: Aleksoid1978Вот проверяем как стало - https://yadi.sk/d/YzazqPWRpL8aY
Проверил тестовый билд на Windows 7 - 10 + ASUS EAH5770, в том числе и на NVIDIA GeForce-ах.
Вот теперь стало гораздо лучше, а если еще точнее, то вообще
превосходно!
Преимущества тестового билда:
1. Избавились от артефактов в самом начале воспроизведения.
2. Избавились от значительного пропуска кадров в самом начале воспроизведения.
3. Избавились от сильной нагрузки, после открытия и начала воспроизведения.
4. Избавились от высокого значения джиттера. Теперь он всегда строго равен 1 мс на всех новых операционных системах (Win7 - Win10) как на ATI/AMD Radeon HD, так и на NVIDIA GeForce.
5. Избавились от странного эффекта (явления) "повторения пройденных кадров" в самом начале воспроизведения.
В общем, теперь данный видео файл, полностью на все 100%, воспроизводится нормально. Грац! :)
[merge_posts_bbcode]Добавлено: 2016-02-23 08:26:16[/merge_posts_bbcode]
Также проверил тестовый билд на данном видео файле, при наличии активной VSync - теперь он стал нормально воспроизводится, при наличии задействованной вертикальной синхронизации (VSync).
Цитата: V0ltЦитата: Aleksoid1978Достаточно интересная проблема - дело в том что видео 25i, но при укладке в MKV почему-то длительность кадра выставляется как для 50fps. Наш сплиттер использует именно это значение для расчета - а вот LAV Source возможно берет значение из H.264 SPS данных - а там как положено указано 25fps.
Не берет он оттуда данные, нельзя так делать.
Если не берет - то откуда тогда fps выставляется 25(хотя в заголовке он равен 50) и время пакета тоже 25 fps.
Aleksoid1978
Я взял данный файл убрал аудиодороги и запаковал обратно как 60i. MPC-BE и MPC-HC показывают статистику правильно, а твой тестовый билд нет.
Сможешь написать код который будет доставать флаг интерлейса из видеопотока?
Цитата: V0ltAleksoid1978
Я взял данный файл убрал аудиодороги и запаковал обратно как 60i. MPC-BE и MPC-HC показывают статистику правильно, а твой тестовый билд нет.
Сможешь написать код который будет доставать флаг интерлейса из видеопотока?
Я не спорю что мой билд корректный. Я просто показал как оно может быть.
По поводу флага интерлейса - а что он даст ?? Опять же костыль - модифицировать зашитые значения в шапке ??
А если он нужен - он уже есть, там где парсятся H264 данные, один из параметров как раз указывает на интерлейс.
[merge_posts_bbcode]Добавлено: 2016-02-23 16:57:44[/merge_posts_bbcode]
Хм - я нашел что делает LAVSource, почему он выставляет 25fps.
if (container == "matroska" && r_avg && tb_avg && (avstream->codec->codec_id == AV_CODEC_ID_H264 || avstream->codec->codec_id == AV_CODEC_ID_MPEG2VIDEO)) {
float factor = (float)r_avg / (float)tb_avg;
if ((factor > 0.4 && factor < 0.6) || (factor > 1.9 && factor < 2.1)) {
pvi->AvgTimePerFrame = tb_avg;
}
}
r_avg - это значение из контейнера = 200000
tb_avg - это значение из видео-данных = 400000
как мы видим - в результате расчета присваивается значение из видео-потока.
Aleksoid1978
Одно дело точно знать, что поток интерлейсный и на основании этого делать какие-то выводы. Другое дело гадать на как ты предлагаешь.
Я уже раз 20 говорил, что значение fps в потоке может быть от балды. Главное значение в контейнере, либо непосредственно записанное, либо записанное через временные метки. Для интерлейса как бы получается дополнительный нюанс, тут надо подумать.
Повторюсь. Исходный файл у меня играет нормально, ничего не дергает, ничего не напрягается.
Вот второй вариант, как у LAVSource - https://yadi.sk/d/mOHVOjHGpLYTX
Цитата: V0ltAleksoid1978
Одно дело точно знать, что поток интерлейсный и на основании этого делать какие-то выводы. Другое дело гадать на как ты предлагаешь.
Я уже раз 20 говорил, что значение fps в потоке может быть от балды. Главное значение в контейнере, либо непосредственно записанное, либо записанное через временные метки. Для интерлейса как бы получается дополнительный нюанс, тут надо подумать.
Повторюсь. Исходный файл у меня играет нормально, ничего не дергает, ничего не напрягается.
1 - Включи VSync и посмотри на значение fps :)
2 - В потоке (H.264/MPEG2/HEVC) в принципе не может быть значения от балды. Его может не быть - это да, но если оно там есть - то верное.
В 21-й раз объясняю. Взяли поток с камеры 60p. Замедлить до 24p и прикрутили спокойную музыку. Замедлили через параметры контейнера, без перекодировки. В итоге в контейнере правильные 24p, а в потоке левые 60p.
Еще бывает когда кодировали RAW данные стандартным скриптом (по умолчанию там обычно 25fps), а после упаковывали в контейнер с конкретным значением fps.
[merge_posts_bbcode]Добавлено: 2016-02-23 11:03:36[/merge_posts_bbcode]
Это сообщение (http://mpc-be.org/forum/viewtopic.php?pid=917#p917) ты похоже вообще читал.
Проверь мой последний тестовый билд и уже потом говори ))
Цитата: Aleksoid1978Вот второй вариант, как у LAVSource - https://yadi.sk/d/mOHVOjHGpLYTX
Проверил второй тестовый билд на новых системах Win7 - Win10.
Он работает также, как и первый тестовый на данном видео файле, т.е. нормально и корректно.
Еще раз перечислю основные преимущества:
1. Отсутствие артефактов в начале воспроизведения
2. Отсутствие сильных пропусков кадров в начале воспроизведения
3. Отсутствие сильно нагрузки в начале воспроизведения, после открытия видео файла
4. Отсутствие высокого значения джиттера.
5. Отсутствие эффекта повторения кадров в начале воспроизведения
В общем, сейчас работает также нормально, а самое главное - корректно и правильно, как и при "LAV Splitter Source".
В принципе, можете оставить тогда этот второй вариант, если он, по вашему мнению, является наиболее корректным и наиболее правильным также и для остальных случаев, которые вы тут обсуждаете.
P.S. Лично я не вижу ничего такого критического в тестовых билдах, да и статистика видео-рендерера правильная.
Цитата: Aleksoid1978Проверь мой последний тестовый билд и уже потом говори ))
Увы но что LAV, что твой билд сливают на матрешке 30p полученной из 60p.
Играет то нормально, как и текущая версия, только вот в статистике ерунда записана.
То что в статистике вместо 30 показывается 60 - это все ерунда, на проигрывание не влияет. Намного лучше чтобы интерлейс играли.
[merge_posts_bbcode]Добавлено: 2016-02-23 22:40:11[/merge_posts_bbcode]
Залил изменения в 1202.
Цитата: Aleksoid1978Намного лучше чтобы интерлейс играли.
Сейчас итак играет. Все было хорошо, но вот некоторым циферки не понравились.
[merge_posts_bbcode]Добавлено: 2016-02-23 15:55:59[/merge_posts_bbcode]
Вопрос. Зачем ты везде используешь
BOOL вместо стандартного
bool?
Блин - да не играет тот файл нормально. Включи VSync и посмотри значения fps в EVR реднерер - он в районе 44-46 кадров и идут пропуски.
По поводу BOOL - просто больше нравиться. Так же и к примеру ULONG вместо unsigned long long и т.д.
Не подтверждаю. В начале да, 20-25 кадров или полукадров вылетает. Потом все нормально идет: 50 fps, никаких пропусков.
Скачал обрезок - идет рывками. GF 560ti.
Нерезанный и на svn играл нормально.
Цитата: V0ltСейчас итак играет. Все было хорошо, но вот некоторым циферки не понравились.
Звучит так, будто бы я во всем виноват...
Мне не понравились вовсе не значения, а корректность воспроизведения таких видео файлов, особенно с самого начала.
Сделав несколько тестов я в этом полностью убедился. У нормальных видео файлов, особенно с CFR, никак не может быть постоянное значение джиттера = 10 мс, интерлейсные видео файлы - не исключение. Тут возможны только два варианта, или сам видео файл не совсем корректный, или что-то не так работает в самой программе, в которой он был открыт. Поскольку мы точно знаем, что видео файл полностью корректный, следовательно что-то не так в самой программе.
К тому же, в SVN 1200, во время воспроизведения данного видео файла, т.е. этой интерлейсной матрешки, очень часто видны горизонтальные полосы, особенно на лицах персонажей, во время их перемещения, даже несмотря на тот факт, что работает аппаратный деинтерлейс, т.е. удвоенная частота кадров, равная 50 FPS.
Во втором тестовом билде, как и в первом тестовом, этих горизонтальных полос, при работе аппаратного деинтерлейса, с удвоенной частотой кадров в 50 FPS, вообще нет.
Это также говорит о том, что работа аппаратного деинтерлейса также улучшилась.
Даже на видео файлах с VFR, где частота кадров может меняться во время воспроизведения, поскольку она является переменной и джиттер, во время ее изменения, начинает также расти, я не видел чтобы он рос до 10 мс, максимум это до 3 - 4 мс. Иногда от 5 до 7 мс, но это уже редкость. Причем, после роста до определенного значения, происходит резкое падение до минимума, т.е. до 1 мс или вообще 0 мс, что конечно же правильно для VFR.
Поэтому, если на нормальном видео файле мы видим такое высокое значение джиттера, да еще и на постоянной основе, значит явно уже где-то, что-то работает не так, как положено. К тому же, у нас есть с чем можно сравнить.
[merge_posts_bbcode]Добавлено: 2016-02-23 16:53:42[/merge_posts_bbcode]
Цитата: LeoСкачал обрезок - идет рывками. GF 560ti.
В этой теме были указаны ссылки на кривые обрезки, которые в любых плеерах воспроизводятся также криво.
Лучше скачайте пожалуйста нормальный сэмпл и проверьте еще раз.
Вот вам, пожалуйста, ссылка на нормальный сэмпл данной интерлейсной матрешки:
https://yadi.sk/i/uXfRSgFqpMheP
Цитата: V0ltНе подтверждаю. В начале да, 20-25 кадров или полукадров вылетает. Потом все нормально идет: 50 fps, никаких пропусков.
Включи VSync, включи статистику и смотри на fps, также в статистике самого EVR custom. Если уж прям все будет чётко - сделай плиз скрин статистики экрана и самого EVRCustom.
Цитата: Aleksoid1978Включи VSync, включи статистику и смотри на fps, также в статистике самого EVR custom. Если уж прям все будет чётко - сделай плиз скрин статистики экрана и самого EVRCustom.
Пожалуйста: SVN 1200 - открыл видео, включил VSync, открыл статистику видео-рендерера, значение FPS = 46.705.
Еще раз убедился в том, что файл работал некорректно.
У меня так (http://screenshotcomparison.com/comparison/163024) получилось.
Для 1201.
(http://s013.radikal.ru/i323/1602/db/13334bd05941t.jpg) (http://s013.radikal.ru/i323/1602/db/13334bd05941.png)
[merge_posts_bbcode]Добавлено: 2016-02-23 17:20:23[/merge_posts_bbcode]
Я не против хака, но по факту он не совсем корректен. Но пусть пока будет.
PS: изменил порядок методов определения fps в r1203.
[merge_posts_bbcode]Добавлено: 2016-02-23 17:52:23[/merge_posts_bbcode]
Вот скриншот для 1203.
(http://s020.radikal.ru/i707/1602/eb/50db955b6684t.jpg) (http://s020.radikal.ru/i707/1602/eb/50db955b6684.png)
Принципиальная разница только лишь в пропуске кадров в начале, которую не замечаешь. Форма зеленого графика на просмотр никак не влияет.
[merge_posts_bbcode]Добавлено: 2016-02-23 17:56:06[/merge_posts_bbcode]
MPC-BE v1.4.6 (build 1203) beta - x86 (https://yadi.sk/d/vaSuXUQDpMuQU), x64 (https://yadi.sk/d/S82CGMSapMuWJ).
V0lt, устраните (уберите) пожалуйста Warning C4800 "BOOL" в MatroskaSplitter.
Скриншот: https://yadi.sk/i/9I43VKg1pN3gC
[merge_posts_bbcode]Добавлено: 2016-02-23 21:37:09[/merge_posts_bbcode]
V0lt, Aleksoid1978, есть ли вообще какой-нибудь способ полностью и окончательно избавиться от пропусков кадров, при открытии видео файлов и начала их воспроизведения сразу после открытия?
Evgeniy1990
MPC-BE x64 билд 1203 и файл, который никто не досмотрел до конца :D. Открываю в окне или сразу на полном экране. В результате 0 пропущеных кадров (не ожидал). Если делаю переходы окно-полный экран, то естественно кадры пропускаются.
Проблемы не вижу.
Ну пропадет 10-20 кадров, не страшно, главное чтобы дальше было хорошо.
Цитата: V0ltEvgeniy1990
MPC-BE x64 билд 1203 и файл, который никто не досмотрел до конца :D. Открываю в окне или сразу на полном экране. В результате 0 пропущеных кадров (не ожидал). Если делаю переходы окно-полный экран, то естественно кадры пропускаются.
Проблемы не вижу.
А если открывать без запущенного окна плеера, т.е. при условии, что еще не запущена ни одна сессия?
Цитата: V0ltНу пропадет 10-20 кадров, не страшно, главное чтобы дальше было хорошо.
Дело в том, что по здравой логике они вообще не должны пропадать. По идее, я думаю, что это все же как-то можно вылечить, т.е. исправить.
P.S. Подождем ответа от
Aleksoid1978. Может быть у него есть некоторые идеи, или мысли, как это побороть.