Привет All!
Есть некий фреймворк
class File
{
virtual void Read(...);
virtual void Write(...);
virtual void Seek(...);
}
//------------------------
class Bz2File : public File
{
virtual void Read(...);
virtual void Write(...);
virtual void Seek(...);
}
//--------------------------
Если c Read Write всё понятно, то как быть с Seek?
Неужели самый тупой метод — расшифровывать с начала до заданой места или полная разархивировация в память?
Может кто-нить сталкивался ...
С уважением
Роман
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Здравствуйте, Kapone, Вы писали:
K>Если c Read Write всё понятно, то как быть с Seek?
K>Неужели самый тупой метод — расшифровывать с начала до заданой места или полная разархивировация в память?
В libbz2 функции Seek нет.
Только руками разбирать формат сжатого потока.
Может быть, он нарезан на кадры? Тогда можно найти ближайший кадр и разжимать последовательно от того места.
Если же нет — то смотри, что удобнее в глобальном масштабе: каждый раз последовательно бегать от начала или один раз разжать в память.
Может быть, достаточно запомнить окно из, скажем, 1024 последних прочтённых байтов (если вызовы Seek, как правило, носят локальный характер — отмотать чуть-чуть назад, перемотать чуть-чуть вперёд, — то будет выигрыш).
... << RSDN@Home 1.2.0 alpha rev. 655>>
Спасибо за советы!
Решил дело юзанием политик. Создал 3 политики:
1) FastSeeker. Когда надо много раз прыгать и файл разумных разимеров (до 500 кб) , то его можно разжать в память и ходить там.
2) SlowSeeker. Когда прыгать нужно редко и время перемещения не критично. Вхолостую перебираю до нужного смещения.
2) AdaptiveSeeker. Оконный режим. С подсчетом точек выброса на окно в 4К. Кстати самый, как теперь оказалось, редко ипользуемый вариант, так как не всегда предсказуем в плане быстродействия. Нужен анализ, а него нету времени.
Всем удачи в решении задач!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Перекуём баги на фичи!
