Идея про сжатие видео
Каково по твоему "обычное" расстояние между ключевыми кадрами?
В DIVX по умолчанию стоит 300 кадров + по смене картинки. Т.е. твои плавные переходы должны длиться 12 сек.
Обычно ключевые кадры разные "до неузнаваемости". Т.е. рассчитать среднее между ними не представляется возможным.
В DIVX по умолчанию стоит 300 кадров + по смене картинки. Т.е. твои плавные переходы должны длиться 12 сек.
Обычно ключевые кадры разные "до неузнаваемости". Т.е. рассчитать среднее между ними не представляется возможным.
Не обычное, а выбирать как-нибудь оптимальнее, т.е. расстояние не фиксированное!
Конечно, сжиматься, наверное, будет, сверхдолго, но резыльтат будет стоить того?
Конечно, сжиматься, наверное, будет, сверхдолго, но резыльтат будет стоить того?
B-фреймы уже придумали, да
А это что? 
То есть, я изобрела баян? 
То есть, я изобрела баян?
Сколько ты предлагаешь кадров хранить в памяти? ИМХО, очень много
Только целиком промежуток между двумя ключевыми кадрами - не больше 1000 кадров.
Из твоего описания получается немного не так.
Лучше так: сначала разбиваем наинтервалы с маленьким изменением, потом "начальные кадры" сравниваем и, возможно, некоторые окажутся похожими. в итоге получаем несколько стартовых кадров, несколько масок-отличий для других стартовых, и другие уже по-обычному.
Лучше так: сначала разбиваем наинтервалы с маленьким изменением, потом "начальные кадры" сравниваем и, возможно, некоторые окажутся похожими. в итоге получаем несколько стартовых кадров, несколько масок-отличий для других стартовых, и другие уже по-обычному.
Угу, I, P и B - фреймы.
Ну никто же не говорит, что надо останавливаться на достигнутом 
Лучше так:
сперва разбиваем на кадры, потом - на подкадры. Затем подкадры сортируем, кластеризуем, от каждого берём хэш-функцию и записываем;
ключевые кадры надо хранить в виде стека списков очередей; а фреймы придётся записать в базу данных.
Да, придётся ещё организовать синхронизацию между потоками. И животноводство!
Вот тогда будет хорошо.
сперва разбиваем на кадры, потом - на подкадры. Затем подкадры сортируем, кластеризуем, от каждого берём хэш-функцию и записываем;
ключевые кадры надо хранить в виде стека списков очередей; а фреймы придётся записать в базу данных.
Да, придётся ещё организовать синхронизацию между потоками. И животноводство!
Вот тогда будет хорошо.
Ты мастику для кукольных головок изобретать ещё не пробовала? 
Нет
Тут мне в голову пришла ещё одна совсем извращённая идея, правда, это наверное нереализуемо
Из чего состоит фильм? Есть некоторые блоки пикселей, которые меняются следующим образом:
1) Перемещение
2) Уменьшение/увеличение
3) Плавный переход к другому виду
Ну и комбинации всякие, конечно. Тогда, если научиться всё это выделять из видео, можно вообще всё сжать очень сильно. Например, для человека, который очень часто появляется на экране, мы не будем хранить кучу информации, а только прорисовку его рук/ног/итд, и как они движутся/удаляются/переходят в что-то другое (для спецэффектов)
Тут мне в голову пришла ещё одна совсем извращённая идея, правда, это наверное нереализуемо
Из чего состоит фильм? Есть некоторые блоки пикселей, которые меняются следующим образом:
1) Перемещение
2) Уменьшение/увеличение
3) Плавный переход к другому виду
Ну и комбинации всякие, конечно. Тогда, если научиться всё это выделять из видео, можно вообще всё сжать очень сильно. Например, для человека, который очень часто появляется на экране, мы не будем хранить кучу информации, а только прорисовку его рук/ног/итд, и как они движутся/удаляются/переходят в что-то другое (для спецэффектов)
Приблизительно так уже и делается. При не очень большом битрейте вокруг движущихся относительно неподвижного фона частей можно заметить "обводку".
Оставить комментарий
stksa
Возможно, глупая, а возможно, вообще боянКак обычно всё хранится - через некоторые промежутки натыканы ключевые кадры, а для тех, которые посередине - только отличия от предыдущего. Почему бы не делать так (конечно, не для вещания, но для локального просмотра подойдет(:
Выбираем некоторые кадры - "ключевые нулевой степени", которые будут храниться полностью. Затем, между ними - "ключевые кадры первой степени", для которых будет храниться отличие от СРЕДНЕГО АРИФМЕТИЧЕСКОГО между двумя соседними ключевыми. Затем, в полученныхпромежутках - "ключевые второй степени", для которых будет храниться опять же отличие от среднего арифметического между двумя соседними ключевыми кадрами степени 1 или выше, и т.д... Ну или брать не среднее арифметическое, а с теми коэффициентами, на каком расстоянии текущий кадр от тех двух, по которым мы его строим (для ещё большего уменьшения объёма).
По-моему, это должно очень сильно уменьшить объём при том же качестве, на конкретных задачах - например, если есть плавный переход от одного состояния к другому, при использовании обычных методов будет храниться первый кадр + куча отличий каждого следующего от предыдущего. А при моём способе - только первый и последний!
Что думаете?