MPC-BE forum

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

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

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

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

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

1. Скачать этот видео файл (https://yadi.sk/i/r1sSaBSv3SFj9M)
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 (https://sourceforge.net/p/mpcbe/code/2319/) повлияло.

Цитата: 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". А видео файлов с переменной частотой кадров довольно немалое количество, практически, большинство из них - это аниме и большинство работает также некорректно. А вносить изменение, которое портит воспроизведение большинству видео файлов - это неправильно.

Aleksoid1978
VFR отличается от обычного видео лишь тем, что время между кадрами непостоянное.
Если защита от кривизны основана на неправильно посчитанном rtStop, то эта защита плохая. Надо делать на основе rtStart.

PS: Про порядок B-кадров (возможно не в тему)

Спойлер

Допустил у нас будут такие кадры

Код Выделить Развернуть

1 2 3 4 5 6 7
I B B P B B Pто декодер будет их декодировать в таком порядке

Код Выделить Развернуть

1 4 2 3 7 5 6
I P B B P B BИногда в этом же "неправильном" порядке кадры могут быть упакованы в файл.

[свернуть]

Да я не говорю про rtStop, проверка идет на то чтобы rtStart текущего кадра был не меньше rtStart предыдущего.