Где же тут противоречие? 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
> Нету понимания всего объема информации
В том посте (лень искать) который был недавно на хабре предложили варианты, как это показать
> Бо́льшая нагрузка на интерфейс браузера
Лишние данные можно убирать, оставив только окно, например, в 100 записей.
> Т.к нету деления на условные элементы информации, т.е страницы
Это не минус, а просто пока не реализовано (опять же см. тот пост) в наших соц. сетях. Технически это можно сделать.
> Подгружается только нужный контент, следовательно меньше нагрузки на сервер
Спорно, часто как раз прокручивают всё до конца, лишь бы уйти вниз страницы, тогда как на циферки страниц кликают осознано. К тому же не вижу особой нагрузки, чтобы выдать закэшированные данные разметки…
> Быстрее грузится дополнительный контент, чем бы перезагружалась новая страница
Так скажем пользователь быстрее воспринимает эти данные, т. к. человеку не приходится переводить куда-нибудь взгляд, пока страничка обновляется, всё идёт единой лентой и подгружается в «область взгляда».
Извиняюсь, про form я погорячился, сейчас посмотрел — да, действительно вложенные form режутся везде. Просто однажды был такой баг, вызванный вложенным form, что везде работало, кроме chrome.
Не вопрос что-то сделать одной компании, посмотрите на тот же flash, который вырос из обычный анимации, до сложных приложений. С HTML вышла просто печальная история, что пока на рынке в 200x доминировал IE, никто HTML особо не развивал. Но в последнее время тенденция поменялась, в качестве доказательства посмотрите как быстро за последние годы выросли очки у браузеров в html5test.com
Ну так внутри inline-блока, нельзя встраивать блочные, нужно использовать inline-block. Кроме того у HTML в браузерах есть некоторые особенности, например нельзя делать абзац в абзаце <p> — парсер браузера х просто вычистит. А например Chrome запрещает вложенные <form>, и вычищает их, тогда как другие браузеры — нет.
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
> Нету понимания всего объема информации
В том посте (лень искать) который был недавно на хабре предложили варианты, как это показать
> Бо́льшая нагрузка на интерфейс браузера
Лишние данные можно убирать, оставив только окно, например, в 100 записей.
> Т.к нету деления на условные элементы информации, т.е страницы
Это не минус, а просто пока не реализовано (опять же см. тот пост) в наших соц. сетях. Технически это можно сделать.
> Подгружается только нужный контент, следовательно меньше нагрузки на сервер
Спорно, часто как раз прокручивают всё до конца, лишь бы уйти вниз страницы, тогда как на циферки страниц кликают осознано. К тому же не вижу особой нагрузки, чтобы выдать закэшированные данные разметки…
> Быстрее грузится дополнительный контент, чем бы перезагружалась новая страница
Так скажем пользователь быстрее воспринимает эти данные, т. к. человеку не приходится переводить куда-нибудь взгляд, пока страничка обновляется, всё идёт единой лентой и подгружается в «область взгляда».