MPC-BE forum

Описание проблемы:

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

Условия воспроизведения:

1. MPC Audio Renderer (WASAPI: Shared/Exclusive Mode\'s)
2. Видео файлы с переменной частотой кадров (VFR), с возможностью переключения частот во время воспроизведения

Алгоритм воспроизведения:

1. Скачать этот видео файл
2. Запустить его
3. После запуска, во время его воспроизведения, дождаться времени 00:00:30

Фактический результат:

При использовании "MPC Audio Renderer", на 30-ой секунде появится бегущая строка в виде иероглифов, которая будет идти со скоростью примерно 25 кадров в секунду, вместо 60 кадров, что конечно же неправильно и в дальнейшем (далее) вызовет рассинхрон.

Ожидаемый результат:

При использовании "MPC Audio Renderer", на 30-ой секунде появится бегущая строка в виде иероглифов, которая сразу же должна идти (пробежать) со скоростью 60 кадров в секунду, т.е. должно сработать переключение с одной частоты кадров на другую, а после того, как бегущая строка пройдет полностью, то вернуться обратно на прежнюю частоту кадров.
[merge_posts_bbcode]Добавлено: 2018-02-10 00:13:46[/merge_posts_bbcode]

P.S. ! Ни в коем случае после открытия данного примера видео файла не перематывать его до указанного времени, иначе баг может не проявиться. Т.е. баг проявляется только в том случае, если видео не перематывать.

Проверил на стандартном DirectSound выводе - никаких ускорений до 60 кадров после 30 секунды не заметил.

P.S. Дело во встроенном видео-декодере, с LAV ускоряется. Так же если поменять сплиттер на LAV - правда тогда вообще все видео рывками идет ))

Короче - кривизна еще та, руки бы оторвать тому кто такое сделал ))

Цитата: Aleksoid1978P.S. Дело во встроенном видео-декодере, с LAV ускоряется.

А каким местом тут видеодекодер замешан?
Видеодекодер ведь не должен выдумывать левые временные метки.

Цитата: Aleksoid1978Проверил на стандартном DirectSound выводе - никаких ускорений до 60 кадров после 30 секунды не заметил.

P.S. Дело во встроенном видео-декодере, с LAV ускоряется. Так же если поменять сплиттер на LAV - правда тогда вообще все видео рывками идет ))

Короче - кривизна еще та, руки бы оторвать тому кто такое сделал ))

Проверил связки фильтров:

MPC MP4/MOV Source + MPC Video Decoder + MPC Audio Renderer - проблема есть
MPC MP4/MOV Source + MPC Video Decoder + DirectSound Audio Renderer - проблемы нет

MPC MP4/MOV Source + LAV Video Decoder + MPC Audio Renderer - проблемы нет
MPC MP4/MOV Source + LAV Video Decoder + DirectSound Audio Renderer - проблемы нет

LAV Splitter Source + MPC Video Decoder + MPC Audio Renderer - проблемы нет
LAV Splitter Source + MPC Video Decoder + DirectSound Audio Renderer - проблемы нет

LAV Splitter Source + LAV Video Decoder + MPC Audio Renderer - проблемы нет
LAV Splitter Source + LAV Video Decoder + DirectSound Audio Renderer - проблемы нет

Никаких рывков, при использовании "LAV Filters" и "DirectSound Audio Renderer" нет.
Следовательно, видео полностью нормальное.

Проблема именно в связке "MPC MP4/MOV Source + MPC Video Decoder + MPC Audio Renderer".
И тут одно из двух, либо "MPC Audio Renderer", либо "MPC Video Decoder" в паре с "MPC Audio Renderer".

P.S. Я честно и абсолютно точно могу вам сказать, что это однозначно поломка, ибо я раньше давным давно просматривал этот сериал, при использовании только встроенных фильтров, с использованием "MPC Audio Renderer" и такой проблемы не было.
[merge_posts_bbcode]Добавлено: 2018-02-10 08:57:59[/merge_posts_bbcode]

V0lt / Aleksoid1978

Да, это действительно поломка. Вот первоначальный диапазон: [1.5.0.1823 -> 1.5.2.3369]

Продолжаю поиски:

[1.5.0.1823 -> 1.5.1.2737]
[1.5.1.2237 -> 1.5.1.2737]
[1.5.1.2237 -> 1.5.1.2500]
[1.5.1.2300 -> 1.5.1.2500]
[1.5.1.2300 -> 1.5.1.2399]
[1.5.1.2300 -> 1.5.1.2360]
[1.5.1.2300 -> 1.5.1.2330]
[1.5.1.2310 -> 1.5.1.2330]
[1.5.1.2310 -> 1.5.1.2320]
[1.5.1.2315 -> 1.5.1.2320]

Окончательный диапазон поиска:

[1.5.1.2317 -> 1.5.1.2320]

Вывод: косяк возник в SVN r2319.

Evgeniy1990
Спасибо.
По описанию похоже r2319 повлияло.

Цитата: V0ltEvgeniy1990
Спасибо.
По описанию похоже r2319 повлияло.

Совершенно верно!
[merge_posts_bbcode]Добавлено: 2018-02-10 09:31:54[/merge_posts_bbcode]


 [r2320] by aleksoid

Изменение : MP4Splitter/Bento4 - добавлены поддержка новый атомов кодека H.264(\'avlg\' и \'xalg\'). Небольшая чистка неиспользуемого кода.
    2017-01-26 01:20:14     Tree
[r2319] by aleksoid

Изменение : MPCVideoDec - исправлено проигрывание файлов(VC-1/MPEG2) с флагом 3:2 pull down(29.97 -> 23.97).
Изменение : MPCVideoDec - добавлен "хак" для предотвращения ситуаций когда кадр получает временные метки "старее" предыдущего. Это избавит от пропуска кадров и падения fps при проигрывании некоторого видео-контента.
    2017-01-25 04:33:11     Tree
[r2318] by v0lt

Откорректированы размеры надписей в окне "О программе" ("About...").

[merge_posts_bbcode]Добавлено: 2018-02-10 09:42:52[/merge_posts_bbcode]

Aleksoid1978 был прав, проблема действительно во встроенном "MPC Video Decoder", из-за SVN r3219, но проявляется она только при использовании опять же встроенного "MPC Audio Renderer".

Я правильно подозревал, что тут одно из двух - или сам MPC Audio Renderer, или же пара: "MPC Video Decoder" + "MPC Audio Renderer". В итоге оказалась эта пара: "MPC Video Decoder" + "MPC Audio Renderer".

[merge_posts_bbcode]Добавлено: 2018-02-10 09:54:23[/merge_posts_bbcode]

Дело в этом "хаке" в SVN r3219. Он вообще некорректный, поскольку также вызывает и другие проблемы.

Aleksoid1978
А почему для видеокадров не игнорировать длительность. Ну как это было ранее.
rtStart = ...;
rtStop = rtStart +1;Я бы вообще для видеокадров rtStop выкинул, как бесполезный параметр. Но врядли это возможно.

Нельзя игнорировать длительность - поскольку на ее основе делает "расчет" начала следующего кадра. Зачем это нужно - да потому что не всегда пакеты приходят в декодеры с временными метками.

По поводу r3219 - если отбросить данный сэмпл с переменным fps, какие еще проблемы(чтобы не быть голословным) ??
Для чего я это делал 100% не помню - но то что неверно когда пакеты идут:
1 -> 2 -> 3
а метки
0 -> 40000 -> 20000.

В таком случае 3 пакет просто проигнорируется видео-рендерером.

Цитата: Aleksoid1978Нельзя игнорировать длительность - поскольку на ее основе делает "расчет" начала следующего кадра. Зачем это нужно - да потому что не всегда пакеты приходят в декодеры с временными метками.

Имхо, начало кадра надо всегда брать от сплиттера. А конец (rtStop) неважен абсолютно, т.к. кадр будет висеть пока следующий кадр его не заменит

Если сплиттер ничего не дал, то это плохой сплиттер, его и надо переделывать. Если переделать не получается, тогда просто расчитывать время следующего кадра, но в rtStop текущего его не писать.
[merge_posts_bbcode]Добавлено: 2018-02-10 13:46:57[/merge_posts_bbcode]

Если декодер все же пишет rtStop, то он должен дождаться следующего кадра, а не выдумывать его длительность.
Но проще когда rtStop = rtStart +1.

[merge_posts_bbcode]Добавлено: 2018-02-10 13:52:30[/merge_posts_bbcode]

Цитата: Aleksoid1978Для чего я это делал 100% не помню - но то что неверно когда пакеты идут:
1 -> 2 -> 3
а метки
0 -> 40000 -> 20000.

В таком случае 3 пакет просто проигнорируется видео-рендерером.

А это случайно не случай IBP -> IPB, когда В-кадры идут не по тайм коду, а для удобства декодирования.

MPEG-TS/PS формат позволяет такой режим - когда временные метки вставляются только в ключевые кадры, а остальные могут идти без временных меток. Так что от расчета длительности никуда не уйти.

Ну и пока я никаких изменений по r2319 не будут. Надо сперва будет вспомнить зачем я это делал ))

Цитата: Aleksoid1978Ну и пока я никаких изменений по r2319 не будут. Надо сперва будет вспомнить зачем я это делал ))

Пожалуйста: http://forum.ru-board.com/topic.cgi?forum=5&topic=49025&start=180#15

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

Цитата: Aleksoid1978По поводу r3219 - если отбросить данный сэмпл с переменным fps, какие еще проблемы(чтобы не быть голословным) ??

Вот такая проблема еще была у меня.

Также, при связке "MPC Video Decoder" + "MPC Audio Renderer" был случай, когда во время воспроизведения исчез звук, кадры остановились, но сам прогресс воспроизведения пошел дальше. Это плавающая проблема, которую повторно воспроизвести мне пока не удалось.

И все эти проблемы также были именно при связке "MPC Video Decoder" + "MPC Audio Renderer".

Однозначно, что изменение в SVN r2319 - 100% некорректное. Ибо после него, проявляются различные другие проблемы и большинство различных видео файлов, в том числе и с постоянными частотами кадров, могут воспроизводиться также некорректно.

Ой ладно, вот начинается непонятно что. Аж бесит - когда нифига не шарющие люди(без обид) начинает что-то там утверждать.

Цитата: Aleksoid1978Ой ладно, вот начинается непонятно что. Аж бесит - когда нифига не шарющие люди(без обид) начинает что-то там утверждать.

Я просто говорю как есть, тем более, что у меня было несколько аналогичных проблем, которые я написал.
У всех общее - это связка "MPC Video Decoder" + "MPC Audio Renderer". А видео файлов с переменной частотой кадров довольно немалое количество, практически, большинство из них - это аниме и большинство работает также некорректно. А вносить изменение, которое портит воспроизведение большинству видео файлов - это неправильно.