Search options (Page 1 of 3)

MAG79, всё ещё есть шанс увидеть заветную таблицу?..

Доброе утро. Никаких новостей пока нет?

Да-да, очень нужна помощь! Я уже прикидывал возможность такой реализации, но поскольку там идет смещение на кадр каждую секунду (для той пары, которая с интервалом 24 кадра), то через X секунд ещё и порядок строк нужно будет менять, т.к. последовательность выделяемых диапазонов кадров тоже будет меняться с течением времени. У этого delta.txt не очень простая структура. Мне вообще кажется, что это нереализуемая задача, а если даже ВДРУГ такое и возможно реализовать, то это скорее всего получится какая-то дико сверхсложная формула в Экселе.

В анимациях нет нужды, я предпочитаю статичный набор картинок (это удобнее, нагляднее и главное точнее).
Да и я вообще не жалуюсь на проблемы с пониманием... вот у вас же в предыдущих сообщениях было:

В вашем архиве (panoram_move) выбранного фрагмента видео из 52 кадров указано:
3d, 8j, 13j... [т.е. 3-4 дубли, между 8-9 - скачок, и между 13 и 14 тоже скачок]
Относительно исходных физических кадров (т.е. исходного видео) скачок именно между 8-9, поэтому и возник вопрос, что получается в delta.txt надо учитывать выброшенный ранее (на 3-4) дубль и смещение на кадр, вот тогда с учетом ранее выброшенного кадра уже получится скачок между 7-8.

Спасибо. Это, конечно, замечательно, что я не ошибся с анализом этого видео и подтвердились все найденные мной проблемы в этом видео (хотя было бы и очень странно, если бы не подтвердились, потому что за время многочисленных  экспериментов и попыток по его восстановлению я это видео изучил очень хорошо).
Так а не подскажете, что теперь тут можно сделать? Как я написал в предыдущем комментарии, хотя я нашел и понял все ошибки, но идей как работать с такой периодичностью у меня больше нет.

Благодарю! С упрощением теперь понятно.
А всё-таки, насчет упрощения с использованием SelectRangeEvery - его совсем никак не получится применить?

Я правильно понимаю, что по сути тратятся ресурсы на удвоение кадров для всего видео, а потом выбираются только нужные кадры?
А нельзя делать рассчитывание промежуточных кадров только между двумя необходимыми кадрами? (для увеличения быстродействия)

К сожалению, не удалось.

Так что большая просьба ознакомиться с моим сэмплом (4 имеющиеся проблемы я описал в своем первом комментарии), а то у меня уже закончились идеи, где именно искать ошибку.
Примечание: В моем семпле дубли совсем не в тех местах, где скачки, т.е. нужна не простая замена дубля на рассчитанный кадр, а 2 разных действия (выкидывание кадра в нужном месте и добавление кадра в нужном месте).
А целом необходимо выбросить 2 дубля и добавить 2 рассчитанных кадра.

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

MAG79
Добрый вечер.
Ваш прекрасный код в этом комментарии (отдельное за него спасибо!) очень интересный и полезный, он вдохновил меня на эксперименты с теми видео, которые раньше я считал не подлежащими нормальному восстановлению плавности.

Но тут мне попался фильм с крайне необычным и сложным случаем сочетания дропов и скачков (хоть всё это и имеет чёткую последовательность!), который полностью "восстановить" мне не удалось.
Семпл (видео 25fps, продолжительность 5 минут): http://sendfile.su/1274221

В этом видео 4 проблемы (из них я понял как решать только первые 3 проблемы):
1) 1 дубль - 1 раз каждые 25 кадров

2) 1 скачок (пропуск кадра) - 1 раз каждые 25 кадров
Эти первые 2 проблемы прекрасно решаются по аналогии с тем способом из Вашего комментария чуть выше.

3) 1 дубль - 1 раз каждые 24 кадра
Если бы не существовало 4-й проблемы, то эту проблему можно было бы решить, применив (после предыдущего этапа) выкидывание каждого 24-го кадра (к примеру начиная с 20 кадра) при помощи SelectEvery. Как-то так:

SelectEvery(24,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,20,21,22,23)

4) 1 скачок - 1 раз каждые 24 кадра.
Вот здесь я и не знаю как реализовать смещение на 1 кадр каждую секунду, т.е. необходимый сдвиг для вставки в нужное место рассчитанного промежуточного кадра.

Мне подобное видео уже попадалось несколько раз и как-то даже удалось найти и ознакомиться с исходником, сравнение с которым подтвердило мои догадки: как ни странно, но такое кривое видео получают из вполне стандартных случаев (29,970fps в которых все кадры уже прогрессивные и просто каждый 5-й кадр-дубль, либо опять-таки 29,970fps, в которых после этапа объединения полукадров, тоже получается каждый 5-й кадр-дубль) вследствие использования простого понижения fps (вместо использования алгоритма анализа кадров для поиска и выбрасывания именно дублей), которое просто выбрасывает каждый 5-й кадр (чаще всего нормальный кадр, если только случайно не совпадает, что этот кадр как раз дубль), который дублем не является, что дает из исходных (4+1) кадров, соответственно, (3+1) кадров (3 нормальных +1 дубль).

MAG79
В скрипте GameDropFix_v4 сохранены все 8 вариантов замены одиночных, двойных и тройных дропов. Функциональность из скрипта не удалялась. Быстродействие не замерял, но вполне приемлемое. Тут уж либо быстродействие, либо универсальность
Ну просто чуть выше писали:

Т.е. возможно всё-таки планировалось повырезать лишнее, вот я и решил уточнить этот момент.

Ошибочное определение дропов настраивается параметрами min_move и max_stop (пкс). Первый параметр - минимальное движение в кадре, которое еще распознается за движение, второй - максимальное движение в кадре, который признается дропом при наличии рядом кадров с движением, быстрее текущего в move_idx раз.
Спасибо, в случае чего - теперь буду знать что попробовать подкрутить.

Но обе претензии несущественны, т.к. первая неожиданно  сокращает количество даже такого большого количества рядом расположенных дропов, а вторая частично ловит и заменяет смешанные кадры из двух соседних, частично ловит приостановки проводки камеры оператором в обоих случаях сглаживая рывки и опять же делая видео плавнее.
Да, согласен, такое несущественно. Меня лично больше волнуют не определившиеся пропущенные дропы, если таковые будут, но думаю теперь всё будет проще, когда известно какие параметры настраивать. При пользовании DoubleDropFix.avs (второй версии), именно с такой проблемой я столкнулся на той серии сериала, что я приводил ссылку на рутрекер чуть выше (после удаления циклических дублей, там оставались местами единичные дропы, но сильные артефакты сжатия похоже помешали нормальному детекту дропов (соседние одинаковые кадры отличались только сильными артефактами сжатия и видимо распознались как движение)

MAG79
Для начала - под конкретный файл. А дальше с каждой правкой скрипт будет все универсальней. Сразу всего не учтешь
ОК, "кривой" видеоматериал мне попадается относительно часто, так что будет на чём экспериментировать.

На сэмпле можно попробовать.
Отлично, буду ждать!

Но у меня встречный вопрос: неужели нет более качественной копии этого фильма на DVD/VHS/еще где-либо без выпавших кадров?
Я всегда стараюсь найти самое наилучшее качество (Blu-ray,HDTV,DVD9,DVD5), а  когда исходников не найти, нахожу и скачиваю все возможные варианты рипов, чтобы выбрать наилучший (по всем параметрам). Но иногда (преимущественно для редких фильмов и сериалов до 2000-х годов) выбирать просто не из чего (ни на закрытых трекерах, ни в др.местах, типа usenet), есть только один кривой рип с дропами. Без альтернатив. Разумеется, заниматься перекодировкой с фиксом дропов - это самая крайняя мера, т.к. просто нет другого выбора.

MAG79
Да
А какие тогда недостатки (в плане качества, а не скорости) имеет GameDropFix_v3 в сравнении с DoubleDropFix_v3? (если применять для кино продукции, а не для игрового видео)
Если интересует качество, то вроде как получается, что GameDropFix_v3 лучше и универсальнее (разве что может у него другие настройки чувствительности определения дропов, либо какие-то другие параметры настроенные под игровое видео?).

P.S. А раз анализ движения уже реализован в GameDropFix_v3 может можно его тогда добавить и в DoubleDropFix_v4? (если не сложно)

MAG79
Здравствуйте.
Есть вопрос по DoubleDropFix, а скорее проблема
Небольшой тестовый семпл (исходник + после обработки DoubleDropFix+на особо интересные проблемные места скрины с точным временем на них): http://sendfile.su/884431

Там вот никак не могу понять почему так сильно сбоит дропфикс, например, 1-ый пример (на скринах приложенных к архиву выше) это:
исходник : кадр1 - кадр2 - дубль - кадр4 - кадр5 (на нём смена сцены)
результат: кадр1 - кадр2 - Fix33* - кадр4 - кадр5
*Причем этот Fix33 построенный явно между кадрами 4 и 5, и как следствие получается заглядывание в будущее и перемигивание

2-ой пример:
исходник : кадр1 - кадр2 - кадр3 - дубль - дубль - кадр6 (на нем смена сцены)
результат: кадр1 - кадр2 - кадр3 - Fix33* - дубль - кадр6
*Тут Fix33 построен между кадрами 3 и 6, т.е. правильно, если бы ещё вместо второго дубля был Fix66 - было бы отлично, а так опять имеем перемигивание

Ну и третий пример на скринах, просто единичный замененный кадр, но почему-то с индикацией Fix66, т.е. и тут что-то пошло не так.

P.S. Перепробовал различные декодеры (LAV, ffdshow) с различными вариантами открытия в avs-скрипте: DSS2, ffvideosource, AVISource - безрезультатно