"MPC Matroska Source" - затуп при переходе на след. главу [Исправлено]

Evgeniy1990 · 13 мая 2016, 23:25:20

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

! Данный баг является полностью стабильным на все 100%, воспроизвести его можно всегда, в том числе и на новых операционных системах (Win7 - Win10), при определенном алгоритме.

Итак, алгоритм воспроизведения бага:

1. Скачать этот видео файл: https://yadi.sk/i/8bl8lgYZrhHec
2. Открыть его
3. После его открытия, сразу же кликнуть на кнопку "Следующий" на панели управления

Фактический результат: получим этот самый "затуп", когда видео кадры и соответственно звук стоят на месте, в шкала прогресса воспроизведения продолжает двигаться дальше.

Ожидаемый результат: затупа, при переходе на следующие главы, быть не должно.

P.S. Если заменить наш встроенный фильтр-источник "MPC Matroska Source" на "LAV Splitter Source", то бага не будет. Отсюда и вытекает следующий и очевидный вывод, что баг находится именно в нашем встроенном фильтре-источнике "MPC Matroska Source".

Также, в момент "затупа" можно заметить небольшое нарастание нагрузки на сам плеер, который очень смахивает на утечку памяти.
[merge_posts_bbcode]Добавлено: 2016-05-13 23:25:20[/merge_posts_bbcode]

Ваша цель - перейти на главу "Opening". Именно на ней вы и получите "затуп".
Навигация -> Перейти... -> Opening. Вот и все, что требуется выполнить.

V0lt · 14 мая 2016, 00:05:40

нарастание нагрузки ≠ утечка памяти
[merge_posts_bbcode]Добавлено: 2016-05-14 00:05:40[/merge_posts_bbcode]

Для этого файла перемотка тупит при некоторых значениях времени. С главой просто совпало.

Если правильно посчитал, глава на позиции 02:00.100, а блищайшие ключевые кадры 01:55.147 и 02:00.110.
Вроде как неудачное положение начала главы, но переварить 119 кадров видеокарта должна была быстро, ну пол секунды максимум. А тут что-то серьезнее.

Aleksoid1978 · 14 мая 2016, 04:24:06

Надо смотреть, т.к. наш MatroskaSplitter не находит кл. кадр по данному времени, вот в Debug логе:

Код Выделить

[6392] mpc-be.exe(tid 40c)    42663 : CMatroskaSplitterFilter::DemuxSeek() : Seek Two - 00:02:00,110 => 00:00:00,010, [1201100000 -     100000] 
[6392] mpc-be.exe(tid 40c)    42663 : CMatroskaSplitterFilter::DemuxSeek() : Final(Cluster timecode) - 00:02:00,110 => 00:00:00,010, [1201100000 -     100000]

Как мы видим - перемотка переходит почти в самое начало, поэтому и затуп.
[merge_posts_bbcode]Добавлено: 2016-05-14 10:54:27[/merge_posts_bbcode]

Кажется понял в чем дело - просто неправильно работала логика, подправлю.

[merge_posts_bbcode]Добавлено: 2016-05-14 11:24:06[/merge_posts_bbcode]

Вот проверяем - https://yadi.sk/d/7voKvL-UrhQt5
Сразу попрошу - погонять побольше mkv на перемотке чтобы проверить что ничего не поломалось.

Ну и вот сам патч - https://yadi.sk/d/6Ykr1TNhrhQtf

Evgeniy1990 · 14 мая 2016, 06:42:30

Цитата: Aleksoid1978Вот проверяем - https://yadi.sk/d/7voKvL-UrhQt5
Сразу попрошу - погонять побольше mkv на перемотке чтобы проверить что ничего не поломалось.

Ну и вот сам патч - https://yadi.sk/d/6Ykr1TNhrhQtf

Проверил тестовый билд. Стало лучше, т.е. исчез затуп, но не до конца, т.е. при переходе на главу Opening все же есть небольшое ожидание на 1 - 2 секунды, которого вообще быть не должно.

При использовании "LAV Splitter Source" все полностью нормально, нет ожидания.

Aleksoid1978 · 14 мая 2016, 07:01:08

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

Ну позже как домой доберусь тщательно сравню.

Evgeniy1990 · 14 мая 2016, 07:07:17

Цитата: Aleksoid1978Странно, у меня одинаковое поведение. Небольшая задержка там все равно есть, из-за того что ключевой кадр немного впереди и необходимо время на чтение и декодирование.

Ну позже как домой доберусь тщательно сравню.

Вот именно - "небольшая задержка все же есть" А ее быть не должно, в общем, у себя дома, пожалуйста еще раз сравните работу нашего MPC Matroska Source и внешнего LAV Splitter Source. Вы сможете увидеть отличие, обратив внимание на шкалу прогресса воспроизведения и на само видео.

Aleksoid1978 · 14 мая 2016, 07:14:14

А что там со шкалой и видео?? У меня одинаковое поведение.

Evgeniy1990 · 14 мая 2016, 07:47:12

Цитата: Aleksoid1978А что там со шкалой и видео?? У меня одинаковое поведение.

Просто, когда вы будете у себя дома сравнивать работу нашего MPC Matroska Source с вашими изменениями в патче с LAV Splitter Source, при переходе на главу Opening, сразу же посмотрите на видео а затем сразу же на прогресс воспроизведения. Хотя, я думаю, что вы это уже видели, когда при переходе на главу Opening у вас есть еще 1- 2 секундная задержка, при этом прогресс воспроизведения движется дальше.

Это я просто еще разок вам напомнил на что нужно будет обратить внимание, при сравнении, чтобы вы видели в чем разница, в чем заключается отличие.

Aleksoid1978 · 14 мая 2016, 10:31:15

Так - обновил билд и патч, ссылки прежние.
Проверяем.

V0lt · 14 мая 2016, 10:55:33

Цитата: Evgeniy1990Вот именно - "небольшая задержка все же есть" А ее быть не должно,

С чего ты взял? Сотня кадров волшебным образом декодируются?

Evgeniy1990 · 14 мая 2016, 10:57:01

Цитата: V0lt
Цитата: Evgeniy1990Вот именно - "небольшая задержка все же есть" А ее быть не должно,
С чего ты взял. Сотня кадров волшебным образом декодируются?

А вы проверьте пожалуйста с LAV Splitter Source. Сами увидите, как он легко все 119 кадров обрабатывает просто разом за долю секунды.

V0lt · 14 мая 2016, 11:13:29

Aleksoid1978
Идею с rtMaxDelta крайне не одобряю. Это плеер может решать насколько точно ему перематывать в соответствии с его настройками, а сплиттеру если сказали мотать на 2 минуты, следовательно мотай на 2 минуты или на ключевой кадр который находится раньше этого времени.
[merge_posts_bbcode]Добавлено: 2016-05-14 11:13:29[/merge_posts_bbcode]

Evgeniy1990
Пофиг на LAV, он тоже не идеал.

Рассказываю правило перемотки, которому обязаны следовать все сурс-фильтры.
Допустим у нас ключевые кадры располагаются по номерам 0, 100, 200, 300 и т.д. Допустим нам надо перемотать на 195 кадр и собственно говоря увидеть его. Сплиттер должен будет отмотать на ключевой кадр под номером 100 и отдать всю последовательность от 100 до 195 декодеру. Декодер перемалывает все эти кадры и когда достигнет 195-го сообщает плееру - готово. Плеер показывает нам 195 кадр. Все хорошо и корректно.

А ты хочешь, чтобы сплиттер делал свою работу неправильно, из-за чего плеер покажет не 195 кадр, а 200-й. Зато как в LAV, тфу.

Evgeniy1990 · 14 мая 2016, 11:28:20

Цитата: V0ltEvgeniy1990
Пофиг на LAV, он тоже не идеал.

Рассказываю правило перемотки, которому обязаны следовать все сурс-фильтры.
Допустим у нас ключевые кадры располагаются по номерам 0, 100, 200, 300 и т.д. Допустим нам надо перемотать на 195 кадр и собственно говоря увидеть его. Сплиттер должен будет отмотать на ключевой кадр под номером 100 и отдать всю последовательность от 100 до 195 декодеру. Декодер перемалывает все эти кадры и когда достигнет 195-го сообщает плееру - готово. Плеер показывает нам 195 кадр. Все хорошо и корректно.

А ты хочешь, чтобы сплиттер делал свою работу неправильно, из-за чего плеер покажет не 195 кадр, а 200-й. Зато как в LAV, тфу.

Да, я согласен, что даже и LAV Splitter - далеко не идеал, но ведь надо с чем-то сравнивать. А сравнивать имеет смысл только с актуальными на сегодняшний день фильтрами.

Спасибо вам за краткое пояснение. Я вас понял.

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

Aleksoid1978:

Цитата: Aleksoid1978Так - обновил билд и патч, ссылки прежние.
Проверяем.

Проверил обновленный тестовый билд. Теперь больше нет никакой задержки, при переходе на главу "Opening".
Все работает быстро, как и положено. В общем, проблема полностью устранена - это мой ответ по поводу второго тестового билда и патча соответственно. Т.е. работает так, как и с LAV Splitter Source.

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

Aleksoid1978 · 14 мая 2016, 11:36:19

Дело не в том как в LAV - просто так быстрее. Я не брал LAV за какой-то идеал. Просто на нашем примере намного быстрее буквально немного взять вперед - чем много назад. Может быть 500мс и много, тут можно решить. Но вы можете сравнить оба варианта и посмотреть - мы что потеряли какой то кадр ?? Если так - то плохо. Но я что-то не заметил этого.

Кстати, раньше(еще со времен MPC-HC или даже MPC/Gabest) так и было, перемотка примерно +- 500мс.
[merge_posts_bbcode]Добавлено: 2016-05-14 18:36:19[/merge_posts_bbcode]

Можно уменьшить с 500мс до 100-200 к примеру, тогда такое будет если и происходить то очень редко и на получаемой картинке практически не отобразится.

Evgeniy1990 · 14 мая 2016, 11:41:31

Цитата: Aleksoid1978Дело не в том как в LAV - просто так быстрее. Я не брал LAV за какой-то идеал. Просто на нашем примере намного быстрее буквально немного взять вперед - чем много назад. Может быть 500мс и много, тут можно решить. Но вы можете сравнить оба варианта и посмотреть - мы что потеряли какой то кадр ?? Если так - то плохо. Но я что-то не заметил этого.

Кстати, раньше(еще со времен MPC-HC или даже MPC/Gabest) так и было, перемотка примерно +- 500мс.

Мы вообще ничего не потеряли. Единственное отличие второго тестового билда и патча от первых в том, что во втором тестовом билде и патче полностью отсутствует какая-либо задержка. Не знаю, насколько сильно это может повлиять как-то на перемотку? Я проверил перемотку на нескольких матрешках - и в первом и во втором случаях они перематываются нормально.

В общем, решение остается за вами.