LINUX.ORG.RU
ФорумTalks

Полноархивное сжатие (не сказать еще хужей)

 , ,


0

3

Мысля тут пришла, что бывает редко. Все мне известные методы сжатия видео/аудио сжимают один файл, но ведь в хранилище может быть 130Тб архив с повторениями данных в значительном числе файлов, есть ли алгоритмы сжатия хранилищ медиа целиком с произвольным доступом к содержимому? Что бы учесть момент повторимости некоторых кадров или элементов потока.

Ты ещё предложи при добавлении нового видео каждый раз пережимать весь архив :)

true_admin ★★★★★
()

Видимо, это слишком ресурсоемкая операция.

pi11 ★★★★★
()

Подозреваю, чтобы это нормально без тормозов работало объём RAM должен быть хотя бы 256 Гб, а лучше терабайт. Архивы при этом храниться на SSD.

anonymous_incognito ★★★★★
()
Последнее исправление: anonymous_incognito (всего исправлений: 1)

Прочитал как «Порноархивное сжатие», подумал что места уже не хватает.

uin ★★★
()

про непрерывное сжатие слышал?

Harald ★★★★★
()

h.2225, который при сжатии одного из фильмов будет учитывать все остальные фильмы в коллеции?

greenman ★★★★★
()

А если фильмец в коллекции грохнуть, все опять пережаться должно ?

vasya_pupkin ★★★★★
()

Максимум в пределах одного видео. Так что в лучшем случае пришлось бы собирать и конвертировать 130ТБ в один файл с дополнительной потерей качества, и то не уверен, что такая опция есть, с ходу в H264 не нашёл.

Sadler ★★★
()
Ответ на: комментарий от stave

Самый разумный вариант выходит, но все равно очень трудоемкий

sehellion ★★★★★
()

Были уже солид-архивы раровские. Где-нить в начале файла блок не прочитался и калпец всему архиву. А при пофайловом сжатии не извлекались только затронутые сбоем файлы.

imul ★★★★★
()
Ответ на: комментарий от i3draven

Сами твои знания состоят из 4.2. Все достойные упоминания в контексте сабжа методы сжатия сжимают промежутки между кейфреймами, а не целые файлы, причем кейфреймы бывают как синтетическими, так и естественными. Файлы им нужны только чтобы хранить сигнатуру и метаданные, т.к. зная кодек, можно его натравить на любое смещение и он сам пересинхронизируется о ближайший кейфрейм. В этом свете вся сабжевая идея сам понимаешь.

arturpub ★★
()

Готового решения вроде бы нет, но своё накостылять теоретически можно. Видеопотоки разжимаем, ищем одинаковые чанки, записываем чексуммы, чанки жмём, записываем, какое видео какие чанки содержит, и при открытии этого видео, соответственно, разжимаем только нужные чанки. Сжиматься будет долго, и чем больше коллекция, тем дольше каждое новое добавленное видео, потому что одинаковые части могут начинаться не только на границах каких-нибудь блоков по N килобайт, но и где-то посередине, но разжиматься будет довольно быстро.

Psych218 ★★★★★
()
Ответ на: комментарий от arturpub

А вообще странно, что никто не упомянул о tar.gz, который непрерывен по определению.

Может потому что отвечающие наконец научились осиливать хотя бы первый пост:

с произвольным доступом к содержимому?

Psych218 ★★★★★
()

в хранилище может быть 130Тб архив с повторениями данных в значительном числе файлов

Честно говоря, не придумал реального юзкейса. Что это за хранилище видео такое, что там в разных файлах одинаковые куски? Можно залить два раза один и тот же файл, это да. А вот чтобы кусками…

Psych218 ★★★★★
()
Ответ на: комментарий от Psych218

Что это за хранилище видео такое, что там в разных файлах одинаковые куски?

Сериальчики/аниме с опенингами/ендингами и флешбеками.

Andrew ★★★
()
Последнее исправление: Andrew (всего исправлений: 1)
Ответ на: комментарий от Andrew

Сериальчики/аниме с опенингами/ендингами и флешбеками.

Уверен, они отличаются не только побайтово (это точно), но и попиксельно, даже если на глаз и не отличить. Или у тебя lossless-мастер?

Если нет, то это уже надо нечёткое сравнение делать. В общем, очень медленно в сжатии (не говоря о том, что сложно в реализации). А вообще, можно сжимать супербыстро любые данные во много-много раз. Берём файл, считаем от него sha256… всё. Можно ещё размер файла записать. Плюсы: очень эффективное сжатие, на несколько порядков; очень быстрое сжатие, быстрее всех алгоритмов. Минысы: разжатие — методом брутфорса, занимает несколько вечностей.

Psych218 ★★★★★
()
Последнее исправление: Psych218 (всего исправлений: 2)

Мдя. Вот если бы я весь свой тупняк на ЛОР выкладывал, у меня было бы уже пять звезд.

Sociopsih ★☆
()
Ответ на: комментарий от anonymous_incognito

так это недорого получается.
всего то один шкаф, размером с холодильник.

в первом посте речь шла о 130ТБ данных.
что несколько усложняет задачу в плане ОЗУ.

насколько я понимаю с долговременным хранением на hdd проблем уже нет, хранить, резервировать и обрабатывать такие объемы в объемах всё того же «шкафа, размером с холодильник».

Deleted
()

FS с дедупликацией?

Harliff ★★★★★
()
Ответ на: комментарий от Psych218

Честно говоря, не придумал реального юзкейс

Самый простой вариант - записи систем видеонаблюдения

Uter
()

Для музыки вполне можно. Я вообще считаю, что нужно создать миди для дабстепа, Циммер-музыки, грайндкора и всего такого, что звучит одинаково.

Klogg
()
Ответ на: комментарий от Uter

Не подходит. Почти все системы пишут только по движению или по датчикам, то есть одинаковых кадров крайне мало.

stave ★★★★★
()
Ответ на: комментарий от Psych218

Теперь я представляю ТС бородатым админом с десятихардовым рейдом, забитым аниме в raw.xz.

t184256 ★★★★★
()
Ответ на: комментарий от Uter

Зачем писать неизменную картинку? Она выводится на экран дежурного, но, как правило, запись не идет. Вмё по опыту используемых сетей, последняя камер около 60.

stave ★★★★★
()
Ответ на: комментарий от Uter

Кстати, про видео с дорожных камер - запись будет постоянной, но и одинаковых кадров не будет )

stave ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.