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

V0lt · 14 мая 2016, 11:51:12

Aleksoid1978
Сурс-фильтр ничего не должен решать, он должен отдавать то, что его просят. Все эти "ускоряющие" фичи должны быть на стороне плеера. У нас и в MPC-HC для этого весь функционал и опции имеются.
[merge_posts_bbcode]Добавлено: 2016-05-14 11:51:12[/merge_posts_bbcode]

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

Evgeniy1990 · 14 мая 2016, 12:03:22

Цитата: V0ltAleksoid1978Хочется мотать быстро - включаем перемотку по ключевым кадрам. Если хочется точность выключаем. А сейчас вы тут пытаетесь сделать безальтернативный вариант, когда точная перемотка будет просто невозможна.

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

Цитата: V0ltА ты хочешь, чтобы сплиттер делал свою работу неправильно

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

А есть ли способ исправить этот баг таким образом, чтобы не нарушалась логика перемотки по кадрам и не было задержки?

V0lt · 14 мая 2016, 12:09:23

Цитата: Evgeniy1990А есть ли способ исправить этот баг таким образом, чтобы не нарушалась логика перемотки по кадрам и не было задержки?

В волшебной стране может быть.

Aleksoid1978 · 14 мая 2016, 12:13:49

Ну вот я считаю что +200мс(к примеру, раз 500 многовато) никоим образом не нарушать ничего. Да вы это даже визуально не заметите. Зато благоприятно отразится на скорости перемотки.

Ну если прям таки против - то становимся на 1-ом варианте.

Evgeniy1990 · 14 мая 2016, 12:22:49

Цитата: Aleksoid1978Ну вот я считаю что +200мс(к примеру, раз 500 многовато) никоим образом не нарушать ничего. Да вы это даже визуально не заметите. Зато благоприятно отразится на скорости перемотки.

Ну если прям таки против - то становимся на 1-ом варианте.

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

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

Я вполне согласен с мнением V0lt\'a. Нельзя нарушать логику работы перемотки.

V0lt · 14 мая 2016, 12:52:57

Цитата: Aleksoid1978Ну вот я считаю что +200мс(к примеру, раз 500 многовато) никоим образом не нарушать ничего. Да вы это даже визуально не заметите. Зато благоприятно отразится на скорости перемотки.

Это на данном файле незаметно, но ключевые кадры не всегда удачно располагаются.

ЦитироватьНу если прям таки против - то становимся на 1-ом варианте.

Я за точную работу сурс-фильтров.

Evgeniy1990 · 14 мая 2016, 12:59:41

Цитата: V0ltЯ за точную работу сурс-фильтров.

Я тоже. В общем, мы определились. Оставляем первый вариант.

Aleksoid1978 · 14 мая 2016, 13:12:31

Цитата: V0lt
Цитата: Aleksoid1978Ну вот я считаю что +200мс(к примеру, раз 500 многовато) никоим образом не нарушать ничего. Да вы это даже визуально не заметите. Зато благоприятно отразится на скорости перемотки.
Это на данном файле незаметно, но ключевые кадры не всегда удачно располагаются.

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

V0lt · 14 мая 2016, 13:26:55

Не всего 200 мс, а целых 4...12 кадров промаха (зависит от fps). Зачем вообще промахиваться при переходе, когда требуется конкретное время? Я понимаю промах при клике по таймлайну (там сам клик часто большую погрешность имеет и там промахом рулит плеер (см. опции MPC-HC)), но зачем делать так, когда нужна точность?

В общем я против, чтобы сурс-фильтр ошибался. Это неправильно.

Leo · 14 мая 2016, 19:11:45

Если кому-то интересно, то я на стороне V0lt\'а. Если точная перемотка - пофиг на скорость, если пофиг на точность - мотаем по ключевым.

V0lt · 14 мая 2016, 21:17:46

Мысли на тему...

Спойлер

Все переходы которые у нас имеются.
1. Команда "Переход..."
2. Шаг вперед и назад
3. Переход вперед и назад (по ключевым кадрам)
4. Позиции глав
5. Переходы короткий, средний и длинный
6. Поиск по таймлайну

Имхо, 1-4 должны всегда перематываться точно. Т.к. во всех этих случаях указывается конкретное время, а некоторые режимы без точного перехода вообще не будут работать.

5 довольно спорный на счет точности. Много нюансов.

А вот 6 вполне может быть неточным, что сейчас и реализовано в опции "Быстрая перемотка (по ключевым кадрам)".
Но Я думаю для этого случая нужен дополнительный комбинированный режим. Режим, который будет зависеть от длительности видео и длины сикбара. Но это совсем офтопик уже.

[свернуть]