2010-02-01 2 views
2

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

Я использую C и winapi методы OpenFile/ReadFile.

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

+0

DICOM действительно сложный формат ... в зависимости от того, какие варианты разрешения и сжатия, Вы не можете быть в состоянии читать достаточно быстро, с компакт-диска, чтобы играть в реальном масштабе время. В этом случае вам следует выбирать между замедленным воспроизведением и рывком. DVD-диски не должны вызывать проблемы - см. Таблицу относительно относительной скорости и битрейта. – BobMcGee

ответ

4

Две методики:

  1. большой буфер или кэш, как и в нескольких МБ. CD/DVD имеет разумный последовательный ввод-вывод, но очень медленные скорости поиска/доступа (как вы отметили), поэтому быстро пополнить буфер. Вам просто нужно, чтобы буфер был достаточно большим, чтобы он закрывал несколько секунд, чтобы позволить дискам вращаться, если это необходимо, и искать, если он уже развернулся.

  2. Многопоточность: постоянное чтение одной нити и отдельная анимация декодирования нитей. Читательский поток должен блокироваться, если он слишком сильно опережает декодирование.

Эти методы применимы к любому языку программирования и могут быть объединены для лучшего эффекта. Один буфер чтения и один буфер декодированного кадра защищают вас дважды, а также от времени декодирования и времени доступа.

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

  • Скорость чтения для 1 CD-ROM: 150 KiB/с (абсолютный минимум скорости)
  • Скорость чтения 4x CD-ROM: 600 KiB/с (стандартный минимальный диск)
  • Скорость чтения CD-16x ROM: 1600 kiB/s (максимальный доступный, обычно только до 8x)
  • Скорость чтения 1x DVD-привод: ~ 1,3 MiB/s
  • Видео стандартной четкости, сжатое в MPEG2 при качестве DVD: ~ 600 kiB/s
  • Видео стандартной четкости, сжатое в MPEG4 при качестве DVD: ~ 100 kiB/s
  • видео несжатого стандартной четкости: ~ 30 МБ/с
  • Стандартных 1000x1000 (1 Мп) изображение в 24-битного цвета: 3 МБ
  • Стандарт 1 Мп изображение в 8-битном цвете (оттенки серого): 1 МБ

Edit2: дополнительная информация

  • Обратите внимание, что DVD-диски обычно можно прочитать на 8х или так, если ваш привод поддерживает его (большинство из них в настоящее время).
  • Анимация начинает казаться гладкой на 24 кадра в секунду. Ниже они будут казаться отрывистыми для зрителя.
  • Без потерь компрессия обычно хороша примерно на 50% для уменьшения фотографических изображений. Однако ваш пробег может измениться.
  • Плавное воспроизведение анимаций будет частично зависеть от того, как вы разговариваете с видеооборудованием. Некоторые методы будут давать лучшие результаты, чем другие. Я ВЕРНУЮ предлагаю вам посмотреть на код для MPlayer в этом случае.
+0

Должны ли данные считываться в некоторых определенных фрагментах данных или перекрываться io - это лучшая идея? – bartek

+0

@bartek: перекрытие IO будет обходить системный кеш, поэтому он (вероятно) будет _smoother_, но не обязательно быстрее. –

+0

Спасибо большое, я действительно полезен. Я не уверен, что понимаю, что это значит «постоянно читает», если это имеет значение, если я неоднократно вызываю ReadFile с меньшим read_buffer или меньше раз с более крупным буфером? Я обнаружил, что использование std :: fstream, по-видимому, использует диск более плавный, может ли это быть правдой? – bartek

2

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

+0

Это хороший совет (и относится также и к жестким дискам), но если я правильно прочитаю, у него нет большого контроля над размещением данных на диске или в формате анимации. Я думаю, что неплохо было бы говорить о скорости чтения для оптических дисков и стандартных битрейтов для сжатых видеоформатов. – BobMcGee

+0

точнее, я читал файлы формата dicom (формат медицинского изображения), данные в многокадровых изображениях всегда хранятся по очереди в одном сегменте данных, иногда он кодируется без потерь. – bartek

+0

Можете ли вы закодировать его с потерей зрения? Можете ли вы разместить его там, где хотите на диске? – Goz

Смежные вопросы