Ну так это и не сервер для одновременной работы 50-ти человек, двуядерного atomа должно с головой хватить на обслуживание софт-raid в пределах домашних нужд, а нормальный RAID-контроллер влетит в копеечку.
Вот ссылочка показывающая как просто администрировать описанный в статье RAID. Я конечно не спорю, что в ZFS возможностей больше, но они вряд ли нужны в масштабах домашнего применения.
Статья адресована тем, кто мало знаком с linux, опытным линуксоидам она, конечно, будет малополезна. Хотел поделиться с общественностью еще один вариант организации домашнего NAS, тем более что не нашел на хабре подобной статьи.
Очень не хватает мониторов с таким разрешением, а то блин в айпаде третьем разрешение больше, чем в десктопе, при меньших размерах, при этом в обычных мониторах в основном full hd, если нужно больше — то обычно и диагональ здоровая и стоимость нехилая.
Где же тут противоречие? 2000 Тбайт — это ёмкость жёсткого диска 3,5'' при хранении 1бит в 1 атоме (при условии что технология остаётся той же, данные хранятся так же в плоскости магнитного диска 1 ТБайт * 2000, где 2000 — кол-во атомов которые используются сейчас для хранения бита, цифра указана в статье).
682121 ТБайт — это ёмкость 1 г воды исходя из молярной массы при хранении одного бита в 100000 атомов (6*1023 / (18 * 100000) бит).
Про то что «легко» хранить это вы загнули, легко представить да не легко реализовать. Не очень понял, что вы будете использовать в качестве носителя информации? Изотопы? Кварки?
Хранить то получилось, но на очень короткое время… К тому же любое даже небольшое взаимодействие может изменить состояние атома (прощай мобильность). Надёжность хранения тут очень небольшая, придётся очень постараться чтобы её повысить и тем самым вывести на промышленный уровень. Но пройдёт лет 50 и ёмкости в 2000 ТБайт на жёстком диске уже будет мало. Тут мы снова упираемся в фундаментальное ограничение, но на этот раз ещё более жёсткое — как хранить более бита в одном атоме?
Вот пример: сейчас нужно около 1000-2000 атомов, чтобы закодировать один бит. По закону Мура через 10 лет потребуется всего один атом для кодирования такого же объёма информации.
Мне кажется что до хранения бита информации в одном атоме — ещё очень далеко. Сейчас необходимость уменьшения размера бита продиктована в основном тем, что сейчас почти все носители информации хранят данные в 2D (на диске HDD/CD, в плоскости подложки микросхемы). Мне кажется человечество сначала научится хранить данные в 3D, ведь даже если предположить, например, что для кодирования бита нам требуется 100000 атомов, то максимальное кол-во информации которое можно сохранить в 1 грамме воды — 682121 Тбайт (исходя из молярной массы).
Ну хорошо, задача немного отличается в деталях. Но суть всё равно остаётся — если вам нужно контролировать итоговый битрейт/размер, то тогда нужно два прохода, если же вас интересует только итоговое постоянное качество — то однопроходный (--crf).
Если ставить задачу гарантированного прохождения потока через ограниченный канал, то тут надо задавать --vbr-max равным ширине канала, правда это достигается за счёт ухудшения качества итогового видео, по сравнению с чистым двухпроходным алгоритмом, т. к. вы ограничиваете диапазон переменного битрейта (статичный сцены получат больший битрейт (что не особо то и нужно), а динамические меньший).
Ширина диапазона в котором будет прыгать битрейт будет зависеть от разности ширины канала и целевого битрейта, и в худшем случае, когда они равны, вы получите постоянный битрейт (правда тут не учитывается наличие буфера на стороне клиента).
Как раз таки задача одинаковая, просто с немного различными данными. Например, в случае если вам нужно уместить 1.5 часовой фильм на 700 Мб, получаем:
700*8/(1.5*3600) = 1.037 Мбит/с
Получили вашу задачу с необходимостью обеспечить нужный битрейт.
Двухпроходный алгоритм нужен в первую очередь тогда, когда нужно иметь файл определённого размера. Если же вас интересует именно постоянное качество, не зависящее от того что на ролике (глупо тратить на ролик состоящий из статичной сцены столько же битрейта, сколько и на сверх-динамичный, где практически в каждом пятом кадре фактически новое изображение).
Сейчас h264 уже наверное поддерживается большим количеством устройств, чем xvid/divx. По крайней мере современные устройства затачивают на воспроизведение именно этого формата. Другое дело не все параметры поддерживаются разными устройствами. Например некоторые поддерживают только baseline-профиль, другие имеют ограничение на кол-во референсных кадров (-ref), например Asus O Play! — не более 9 ReFrame.
Мои много «НО»:
1) Для чего автор рекомендует VLC media player и K-Lite Codec Pack? Какое они имеют отношение к сжатию, если автор использует MeGUI?
2) Последние версии x264 содержит в себе библиотеку libavcodec и вполне себе может открывать любые файлы без AviSynth, не знаю как MeGUI, но консольная утилита это может точно.
3) Непонятно вообще, что за настройки рекомендует автор??? Вообще разработчики x264 не дураки и специально придумали:
а) профили кодирования для регулирования скорости сжатия (--preset от ultrafast до placebo)
б) параметр учитывающий тип сжимаемого материала (--tune)
в) параметр для ограничения формата для воспроизведения на различных устройствах (--profile).
г) параметры для регулирования степени сжатия (--crf и др.)
Остальные настройки крутить без знания для чего они конкретно нужны — не стоит.
4) > Для 1080p нужно немного под редактировать конфиг
> Меняем значение Number of Reference Frames с 9 на 4
Автор даёт советы, при этом не понимает для чего. Это стоит ограничивать только, если планируется воспроизведение на каком-нибудь железном плеере, или мобильном телефоне. Дело в том что контроллер устройства может не поддерживать количество референсных кадров >9 при разрешении FullHD. Или например аппаратное ускорение DXVA не может работать при --ref>11
ASUS AT5NM10T-I — 2700руб.
Thermaltake Element Q VL52021N2E — 2200 руб.
Память не помню какая, но взять сегодня можно за ~850 руб
682121 ТБайт — это ёмкость 1 г воды исходя из молярной массы при хранении одного бита в 100000 атомов (6*1023 / (18 * 100000) бит).
Про то что «легко» хранить это вы загнули, легко представить да не легко реализовать. Не очень понял, что вы будете использовать в качестве носителя информации? Изотопы? Кварки?
Мне кажется что до хранения бита информации в одном атоме — ещё очень далеко. Сейчас необходимость уменьшения размера бита продиктована в основном тем, что сейчас почти все носители информации хранят данные в 2D (на диске HDD/CD, в плоскости подложки микросхемы). Мне кажется человечество сначала научится хранить данные в 3D, ведь даже если предположить, например, что для кодирования бита нам требуется 100000 атомов, то максимальное кол-во информации которое можно сохранить в 1 грамме воды — 682121 Тбайт (исходя из молярной массы).
Из --help:
Если ставить задачу гарантированного прохождения потока через ограниченный канал, то тут надо задавать --vbr-max равным ширине канала, правда это достигается за счёт ухудшения качества итогового видео, по сравнению с чистым двухпроходным алгоритмом, т. к. вы ограничиваете диапазон переменного битрейта (статичный сцены получат больший битрейт (что не особо то и нужно), а динамические меньший).
Ширина диапазона в котором будет прыгать битрейт будет зависеть от разности ширины канала и целевого битрейта, и в худшем случае, когда они равны, вы получите постоянный битрейт (правда тут не учитывается наличие буфера на стороне клиента).
700*8/(1.5*3600) = 1.037 Мбит/с
Получили вашу задачу с необходимостью обеспечить нужный битрейт.
1) Для чего автор рекомендует VLC media player и K-Lite Codec Pack? Какое они имеют отношение к сжатию, если автор использует MeGUI?
2) Последние версии x264 содержит в себе библиотеку libavcodec и вполне себе может открывать любые файлы без AviSynth, не знаю как MeGUI, но консольная утилита это может точно.
3) Непонятно вообще, что за настройки рекомендует автор??? Вообще разработчики x264 не дураки и специально придумали:
а) профили кодирования для регулирования скорости сжатия (--preset от ultrafast до placebo)
б) параметр учитывающий тип сжимаемого материала (--tune)
в) параметр для ограничения формата для воспроизведения на различных устройствах (--profile).
г) параметры для регулирования степени сжатия (--crf и др.)
Остальные настройки крутить без знания для чего они конкретно нужны — не стоит.
4) > Для 1080p нужно немного под редактировать конфиг
> Меняем значение Number of Reference Frames с 9 на 4
Автор даёт советы, при этом не понимает для чего. Это стоит ограничивать только, если планируется воспроизведение на каком-нибудь железном плеере, или мобильном телефоне. Дело в том что контроллер устройства может не поддерживать количество референсных кадров >9 при разрешении FullHD. Или например аппаратное ускорение DXVA не может работать при --ref>11