Topic: Буфер кадров для SVP

Что хочется от SVP теперь:
Сканирование от 3-х кадров вперед (что как думаю, может привести к добавлению функции уплавлять только зумы\движения камеры)
Использование начиная от 2-х проходного уплавления (типа как в двух проходном кодировании, чтобы просмотреть что и как уплавлять, а потом уже более качественно выполнить)
Использование Ram памяти для хранения видео потока, с целью устранить проседания кадров. (и эти 3 пункта можно рассматривать в совокупности - например на 3 кадра вперед, думаю можно организовать при 2 проходном уплавлении, чему может способствовать свободная ram)/ Ну и чтобы подытожить, даю согласие на ожидание перед просмотром уплавленного видео, хоть пол часа smile (Чтобы "устаканилось" и было готово к качественному воспроизведению)

2 (edited by danil4eg 18-02-2013 09:48:04)

Re: Буфер кадров для SVP

konstanitinqq
Что-то мне подсказывает, что это уже давно реализовали бы, если бы были соответствующие x64 библиотеки.

Re: Буфер кадров для SVP

konstanitinqq

все уже буферизовано до нас: буферы ависинта, буферы ффд, буферы винды, кеши жеского, буферы рендера, etc...


danil4eg
Что-то мне подсказывает, что это уже давно реализовали бы, если бы были соответствующие x64 библиотеки.

интересно какая связь между разрядностью и буферизацией?  hmm

4 (edited by %username% 18-02-2013 10:49:48)

Re: Буфер кадров для SVP

Где-то вопрос с буферизацией уже поднимался...

____

А, ну да

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

Так шта ноут на Core i3 M 350 + GT335m ничто не спасет

Кстати вопрос на засыпку - отчего кол-во кадров в буфере сравнимо с кол-ом пальцев на руке?  wink

Re: Буфер кадров для SVP

konstanitinqq
Сканирование от 3-х кадров вперед (что как думаю, может привести к добавлению функции уплавлять только зумы\движения камеры)
Увеличение числа кадров для определения зума и панорамирования никак не помогут. Достаточно двух кадров, чтобы построить между ними нужное количество интерполированных. А если панорамирование снято с рук с тряской камеры, то в каждом кадре смещение картинки будет индивидуальным.

2-х проходного уплавления
За предложение спасибо. Пока такой задачи нет. Упор на повышение плавности на лету в один проход.

Использование Ram памяти для хранения видео потока, с целью устранить проседания кадров.
Это уже сделано. Как правильно заметил %username%, во многих местах.
Если хочется именно кадрового буфера, то рекомендую ознакомиться с плеером CrystalPlayer и его кадровым буфером. Обсуждалось в ветке на iXBT.

чтобы подытожить, даю согласие на ожидание перед просмотром уплавленного видео, хоть пол часа  (Чтобы "устаканилось" и было готово к качественному воспроизведению)
Ну так зачем изобретать. Уже все есть: сохранение видео с плавностью (GDSMux, MeGUI). Если не хватает ресурсов, то сначала сохранить видео, а потом посмотреть. wink

6 (edited by %username% 18-02-2013 10:54:29)

Re: Буфер кадров для SVP

MAG79
2-х проходного уплавления
За предложение спасибо. Пока такой задачи нет. Упор на повышение плавности на лету в один проход.

Не, не надо
Реализация вроде несложная, но тянется вагон глюков стороннего софта. К прмиеру 2-х проходное уплавнение только с перекодированием, а у директшоусорс проблемы с точным доставанием кадров из потока, промахивается.

_______

Да и практического смысла не наблюдаю: поиск векторов нужен для текущего кадра, зачем знать про вектора кадра N+1 при расчете и выводе кадра N?  hmm
Когда настанет очередь кадра N+1 про его вектора уж будет известно из кадров N, N-1...

Re: Буфер кадров для SVP

%username%
Да и практического смысла не наблюдаю: поиск векторов нужен для текущего кадра, зачем знать про вектора кадра N+1 при расчете и выводе кадра N?   Когда настанет очередь кадра N+1 про его вектора уж будет известно из кадров N, N-1...

MAG79
Увеличение числа кадров для определения зума и панорамирования никак не помогут. Достаточно двух кадров, чтобы построить между ними нужное количество интерполированных. А если панорамирование снято с рук с тряской камеры, то в каждом кадре смещение картинки будет индивидуальным.

Ничего подобного . Всё относительно . Это сейчас свп пытается уплавнить любое движение любой , сколь угодно большой амплитуды .
Причем просто не в состоянии найти разнонапрвленное движение большой ....даже средней амплитуды .
Если взять движение в нескольких кадрах , то можно обойтись и поиском попроще , и уровень поточнее .  Тогда можно будет найти парашютистов из Трансформеров и т.д. Также значительно снизится вероятность появления площадных артефактов , ибо это следствие согласованности иерархического поиска и "слепости" самых грубых уровней .
Даже изобретать ничего не надо , всё уже изобретено родоначальником фриварного уплавнения : плагин MDepan от Fizick .

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

Re: Буфер кадров для SVP

%username%
интересно какая связь между разрядностью и буферизацией?

Я подразумевал использование более 2х Гб оперативки на процесс (без учета 3Gb патча).

Re: Буфер кадров для SVP

danil4eg
Я подразумевал использование более 2х Гб оперативки на процесс

это ясно-понятно
Но пока не нужно, да
Хотя с видео 4К что-то придется когда-нить делать.

10 (edited by LordMerlin 20-02-2013 05:48:21)

Re: Буфер кадров для SVP

Чтобы быстро было, берите и с качеством 19 кодируйте в 1 проход без сжатия если позволяет место, ну или с лосслесс сжатием, у вас так вся моща пойдет на декод и пересчет и не будет тратиться на сжатие.

Re: Буфер кадров для SVP

LordMerlin
1 поток

проход? hmm

Re: Буфер кадров для SVP

Ой сорри, да, конечно в 1 проход.
Поправил.
Спасибо.