Russian Qt Forum

Добрый день

Приложение "A" занимается анимацией 3D объектов, создает файлы данных и посылает их приложению "B" которое занимается только рендером кадров. Пользователь решает сколько кадров будет послано, возможно он захочет сохранить каждый в свой файл чтобы разослать их по сети всем нодам где стоит "B". Но чаще пользователь не располагает такими ресурсами и хочет просто отрендерить напр 1000 кадров на той же локальной машине. Ну вся 1000 в один файл и сливается.

3D объектов может быть много, поэтому прямолинейная запись "каждый кадр с нуля" быстро приводит к файликам 20, 30, а там и 50Gb. Необходимость "логической упаковки" очевидна, ведь анимирована лишь небольшая часть данных (обычно неск % и меньше). Грубо говоря в 99% случаев 1000 раз пишется одно и то же.

Как же сделать более умное сохранение?

Спасибо

На примере гифа?
Записываются только изменения в кадре, остальная часть берётся с предыдущего кадра и так далее. Примитивная, но действенная оптимизация.

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

Сравнение 2 кадров уже сложно? Я не специалист, но в курсе, что любое видео это просто совокупность изображений, сменяющих друг друга с определённой скоростью. Сравнить предыдущий кадр с текущим, изменения записать. Готовый механизм уже есть и он описан в формате gif и есть десятки библиотек его реализующий.

PS проблемы не вижу, хотя мб не вижу всей картины, так раскройте мне глаза.

Приложению "B" посылаются не пиксели, а сериализованные объекты/структуры из которых оно уже делает то самое "видео"

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

Если же со структурами - хз. Не представляю себе механизмов рендеринга и сами структуры. Потому и совета дать не смогу.

А Вам и не нужно их представлять, это просто структуры для которых определены методы записи в поток. Псевдокод

C++ (Qt)
struct CObjectExample {
  Point GetPosition( int frameIndex );
  Color GetColor( int frameIndex );
  ....
  void Send2Render( int frameIndex, Stream & stream )
  {
    stream << GetPosition(frameIndex) << GetColor(frameIndex) << .....
  }
};
 

Имеется пусть 100 экземпляров такого типа. Создаем файл на 1000 кадров анимации. Положили frameIndex = 1. Записали все 100 экземпляров. Потом frameIndex = 2, опять записали все 100. И так до frameIndex = 1000. В рез-те 99% записанного - повторы. Да, Position и Color могут быть разными для разных frameIndex, но это бывает редко (относительно общего числа данных и объектов)

Тут надо именно знать структуру, её наполненность информацией. В принципе самый простой выход архивирование - оно само определит повторы и если сможет сожмёт их.
Если же разницы незначительные, но непоследовательны, то вполне возможно вывести свой формат сериализации.

К примеру 100 структур с начальными параметрами записываются в начало файла. Далее следуют блоки кадров, в которых указаны изменяемые параметры для каждой структуры.

Но опять надо знать структуру, чтобы оценить и выбрать правильный подход.

Практически не жмет, так часто бывает когда данные float/double. Видимо шаг между повторами слишком велик. С др стороны архивирование лишает читающего возможности seek'ать по файлу. На этой затее можно смело ставить крест.

Ну а что изменится если вместо 2 параметров я приведу неск сотен как оно есть на самом деле? Только то что я устану писать? :)

Число объектов для рендера может меняться от кадра к кадру. Как в общем виде идентифицировать какой структуре соответствует изменение? И вообще как такой файл будет читаться?

[OFF]
Часто приходится слышать, мол,  "вот надо знать все детали/подробности", только тогда, "после тщательного обдумывния" можно спроектировать хорошую архитектуру. На мой взгляд, это имеет больше минусов чем плюсов, "слишком долгое обдумывание" обычно, как ни странно, завершается решениями "от фонаря". Это просто неумение абстрагироваться и желание схватиться за соломинку той или иной детали  :) 
[/OFF]

Я вам привел 3 способа. Мелочи реализации не затрагивались, но вы акцентируете на них внимание.

И напоследок всё же отвечу на ваши вопросы:
Сикать по файлу со своим "архивированием" будет можно, приведя блоки кадров к фиксированной величине. Хотя то, что стандартный архиватор не подходит - это плохо.
Расшифровка данных займёт минимальное количество времени.(~1-14мс на кадр, если не меньше)
Идентификация по номеру структуры.

[OFF]Когда идёшь по непроложенному пути, надо пробовать. Предложили идею - попробовал. Ещё идея - попробовал. И лишь потом делать вывод, исходя из результатов. А забивать идею, указывая на мелочи реализации (которые даже студент 4 курса может самостоятельно написать), это лицемерие. [/OFF]

PS ваши "этого вам знать не надо" лишает человека полного видения картины. А когда высказывается предложение, вы, видя полную картину, видите и недостатки. Хотя для частичного решения проблемы решение идеально.

PPS устраняюсь из диалога, спорьте с самим собой.

О боже, "непроложенный путь", идеи, выводы... :) Смотрите "шкурным" взглядом (ну или "профессиональным", это то же самое). Сколько стоит эта задача? Сколько на ней можно заработать? Очень немного - см первый пост. Во-первых есть вариант где создание больших объемов все же неизбежно, а во-вторых, это всего лишь экономия места на диске - не бог весть что.  Неделя для такой задачки слишком много, это нужно сделать за 3-4 дня максимум. Недавно видел где-то типа
Тогда за 2 дня - и без всяких вопросов. Тоже мне, "ребята"  :)

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

Верно  :) Если хотите расскажу как я сделал

Было бы интересно узнать :)

Ход мысли
Это не годится - и не только потому что число данных может меняться от кадра к кадру. Никто не обещал что данные константны для "B" - оно будет их активно менять. Отсюда вывод: "B" должно читать все данные заново на каждом кадре. Поэтому, если мы не хотим раздувать файл, надо дать "B" возможность сделать seek в файле и оттуда считать.

С точки зрения "B" (читающего) перед чтением каждой структуры сначала считывается "magic" число по которому однозначно определяется где данные в файле. Если надо - делаем seek туда, читаем и возвращаемся взад. Существующий код записи/чтения меняется мало. Не могу понять почему никто не предложил этот простой способ - ну может есть лучший?  :)

Дальше по существу все сводится к оптимизации - как эффективно кешировать и уменьшить число seek'ов которые изрядно тормозят чтение. Просто QCache здесь ничего не дает