Всех людей можно понять. Необходимо понять и сделать так, что бы у плохих не было причин быть плохими. Поверьте, всегда есть очень конкретная причина почему человек плохой. Конечно, гораздо проще напечатать оружие и пострелять, но лёгкая дорога всегда ведёт вниз… только сложный путь даст нам достижение цели.
но при нехватке пропускной способности момент начала, для того чтобы воспроизвести без лагов, откладывается всё дальше по мере падения пропускной способности если она меньше битрейта видеопотока.
На практике необходимости в такой логике нет. Предзагрузки 0,2% от всего файла достаточно.
При этом ещё и расходуется ресурс встроенной флеш-памяти.
Что поделать. Ещё и оперативная память расходуется. Всё расходуется, не смотреть же на это. Ресурс там огромный. Память сейчас дешёвая… так что не важно.
Вон все современные телефоны имеют 128Гбайт памяти. Это неспроста.
Для мультимедиа это очень пригодиться.
По моим подсчётам для комфортного просмотра 4к. нужно будет 256Гб… Более нет смысла… фильм весит 80Гб… Можно хранить в кеше несколько на всякий случай… но на практике больше одного врятли будут сохранять. А остальная память на личные фотки\игры\видео\музыку.
У него тоже недостатки есть — например произвольный доступ к файлам
Как раз эта скорость меня меньше всего волнует. В прогрессивном стриминге получение данных идёт постоянно. Миллисекунды которые тратятся на произвольный доступ к данным тратятся всего несколько раз и абсолютно не влияют на скорость передачи данных и комфорт. Запрос на получение данных с конкретного байта там один и сразу идут данные. Никаких особых отличий от http по скорости.
А, нужно соединение держать. Но это опять же ни на что не влияет, даже в многопоточном режиме (когда на каждую часть файла свой сокет на коннект ещё). Это всё ерунда, по сравнению с выше перечисленными пунктами.
Передача файлов по http кстати называется WebDAV
WebDAV — инструмент для управления файлами. А я вам говорю, про передачу данных. В отношении http — это прямые ссылки с http сервера.
Если хотите управлять файлами вам нужен ftp — он для этого вообще-то и создан.
В http есть библиотека indexOf — она комфортно отображает дерево файлов в браузере. Но только для чтения. WebDAV — не использовал и пока не вижу практического смысла.
Да, канал у вас 100кБит периодически попускающийся до 10Мбит. Кеширование не поможет
Повторяю: «кеширование мне всегда поможет!». Я закеширую всё что мне надо и буду смотреть 4к из кеша, а не из интернета. При этом закачка данных будет опережать воспроизведение и воспроизведение будет идти непрерывно.
Ну вот же! Как это так может случиться, что кеширование не помогает???
Предположим у вас фильм в интернете 100Гбайт. 4к…
В телефоне 128Гбайт и как раз есть 100Гигов свободных.
Канал у вас 100Мбит.\с. падающий до 5Мбит.\с. с переодичностью в 3 минуты.
Для воспроизведения необходимо 50Мбит.\с…
Вы запускаете:
— стриминг. И у вас через каждую минуту кино фризится и смотреть его невозможно. Кешируется 10-50Мбайт в оперативную память, чего хватает на 2,5 секунд видео. Когда кеш заполнен, получение данных останавливается совсем на эти самые 2,5 секунды. Т.е. получается вы используете полосу в 2 раза меньше, чем у вас, даже есть! + процесс установления связи и поиска нужного байта, с которого вам передавать данные, тоже занимает не мало времени.
+плеер, должен вообще поддерживать адаптивный размер буфера чтения для сокета (Tcp1323Opts), иначе это вообще не будет работать. Эта инновация появилась, когда скорости передачи данных превзошли 100Мбит… Т.е. совсем недавно. Но это сильно влияет на скорость впринципе.
Т.е. если у вас 100Мбит, то вы максимум сможете использовать 50Мбит. из-за всех этих задержек. И выйдет 50Мбит.\с. с падением до 2Мбит.\с… Конечно посмотреть ничего не получится. Я грубо считаю. Можете подсчитать точнее, уверен реальные цифры гораздо хуже.
— стриминг с записью в кеш. Тут не важно фриз у вас или не фриз в плеере, загрузка идёт параллельно и без остановок. Будет освоена вся полоса 50Мб.\с… Если канал реально позволяет вам воспроизвести видео, то вы его посмотрите максимум с одним фризом вначале, когда скорость разгоняется. Да, да скорость увеличивается, если качать непрерывно. Любая остановка при скачивании — это значительное падение скорости передачи данных. Даже на 10 миллисекунд!
И обратите внимание на современные проблемы в ПО для передачи данных. Как вы замеряли скорость? Протокол smb используемый в Windows, слишком перегружен версиями и настройками, так что даже Windows 10 реализация иногда глючит. Т.е. smb я бы не стал использовать для организации передачи больших объёмов данных. Самый быстрый и продвинутый сейчас http. На втором месте (при определённых настройках) идёт ftp. Вот тут сравнение smb и обсуждение его скорости, которую, даже целая компания Google с их NDK клиентом не может поднять до http протокола.
Всё должно прекрасно работать и в однопоточном режиме.
Именно это и очень сложно понять. Однопоточный режим, да ещё и без кеширования:
1) загружается медленно, за счёт постоянных старт-стоп режимов загрузки и не эффективному использованию оперативной памяти при загрузке.
2) может вызвать фризы из-за перебоя связи.
3) может вызывать глюки у плеера из-за зависающих байтов при передаче.
4) может не использовать всю пропускную способность из-за ограничений ОС.
5) в этом режиме невозможно предзагрузить данные, что бы посмотреть, что-то с битрейтом выше, чем скорость сети.
6) невозможно использовать для загрузки с множества источников.
На самом деле достаточно одного из этих аргументов, что бы понять, что старый добрый ютубовский онлайн стриминг устарел и нуждается в замене. Но вот вам 6 причин перейти на новый стриминг и не увеличивать облучение всех людей на планете.
Я проверил мою технологию. Она не просто работает, а работает, как революция. Вы не можете понять, простое описание технологии, не то что её логику и код… может вам и не надо пытаться обсуждать такие вещи? Примите всё, как факт… тут не детский сад для детей.
Многопоточность в плеере… нет, это не что-то новое, это называется торрент.
Ага и многопоточность движения на дороге это тоже торрент))).
это натуральное перетягивание одеяла, у кого больше потоков тот и на коне, остальным достаются остатки пропускной способности
Стереотипное у вас мышление. У меня когда скорости не хватает, потоки наоборот соединяются в один поток. Когда нужно воспроизведение — лучше один поток, когда нужно скачать данные можно плодить потоки.
В общем я вижу вы не читали моё предыдущее сообщение.
То о чём я писал в предыдущем сообщении никто ещё и близко не делал. Кроме меня. А вы и дальше можете рассуждать, пока нужно делать.
Дома у меня 250 м.бит интернет и 900м.бит wifi, но онлайн 4к фильмы из торрентов это не позволяет смотреть. Всё равно тормозит и фризы. Не думаю, что увеличение скорости изменит что-либо.
Я правильно понимаю, что если речь идёт об одном пользователи, то Вы свободно довольствуйтесь 100мбитной шириной, но если мы множимся, то как раз более широкая
Да, вы правильно понимаете. Я не дорос ещё до момента, когда надо передавать контент между пользователями. Как только дорасту, то сделаю это за пару дней.
Плеер ориентирован на музыку. Например 1000 человек захотели послушать один и тот же трек. Ну как захотели… естественно в разное время захотели. Так что бы прямо в одно время — это не реально, треков очень много.
Дальше, кто захотел, тот включил трек и скачал. Повторно они уже из кэша слушают. 600мб размер 3:40 трека. Получаем 600*8=4800Мбит… Допустим исходящая скорость сервера 100 МБит… Один пользователь получит файл за 4800/100 = 48 секунд. Это значит 220 секунд / 48 секунд= 4,5 человека могут одновременно смотреть онлайн 4к клип без фризов.
Вероятность, что из тысячи треков 5 и более пользователей в одни и теже 48 — 3:40 секунд захотят посмотреть один и тот же трек крайне мала. Ну разве что, это будет единственный 4к клип на сервере))) или единственный нормальный исполнитель на весь мир. Причём это будет первое прослушивание.
И да. Мой плеер опередил время. Он уже адаптируется и переходит из многопоточного в однопоточный режим в зависимости от скорости интернета (надо назвать это как-то. Всё же технология) для воспроизведения 4к контента.
Но в то же время, мы ещё не имеем таких девайсов, что бы можно было делиться 4к контентом, например. Для этого нужно минимум 128ГБ памяти в телефонах. А это ещё редкость.
Копирование с NAS всего каких-то жалких 2Тб
Ну хорошо, что у вас храниться в 2ТБ? Что может быть таким большим? Ну и вы понимаете, что такой объём и необходимость передачи его по сети это крайне большая редкость.
п.с. должен заметить, нужно стремиться не к большим объёмам, а к меньшим. Сейчас всё сжимается и фильтруется.
обычное SD-видео подтормаживает по 150Мбит WiFi каналу. А там-то до 3МБит нужно…
То о чём вы говорите я победил. Проблема не в скорости, а в алгоритмах скачивания медиа-контента. Во всех плеерах они сейчас до боли простые — скачать и воспроизвести, скачать и воспроизвести. Отсюда фризы… пока видео воспроизводится — оно не скачивается.
Мой плеер адски многопоточный. Там на каждый чих свой поток. Ну и конечно загрузка медиа-контента происходит в отдельном потоке, который практически не взаимодействует с плеером.
Выходит: для устранения фризов необходимо место на флешке, что бы контент можно было полностью скачать пока смотришь. + хорошо используется оперативная память, так как контент грузится сначала в оперативную память.
А вот скорость передачи данных подойдёт почти любая.
У меня 4k видео в машине в Москве воспроизводится без фризов в телефоне. 4k клипы слушаю пока в пробках стою… через 4g.
Флак так ему вообще что-то около 1,5-2 Мбита нужно…
Так как у меня используется предзагрузка, так что скорость передачи данных может быть, даже, немного ниже битрейта медиа.
40-80 Мбит\с. достаточно для воспроизведения супер тяжёлых 4к blue ray фильмов, весом 40-80Гбайт.
Так что попробуйте мой плеер. Уверен 4к видео через него будет летать.
Из этого всего вывод такой: практическая необходимость высоких скоростей отсутствует. Мы просто будем больше облучать себя. А 100Мбит\с. хватит всем.
Особенно когда я добавлю ещё передачу контента между клиентами, предсказание и кеширование следующих действий.
Вот! в чём будущее, а не в глупых увеличениях скоростей передачи данных.
так я пишу про ширину канала. Где вы нашли несущую частоту? 160Мгц — ширина канала.
Чёрным по белому и всё равно каждый видит своё…
Alexeyslav — один прочитал и понял. Остальные я не знаю о чём пишут.
Но ответа я так и не услышал…
Итого, я думаю:
Если
чем шире полоса тем меньше мощность нужна для вашей обычной вайфай передачи
то 160Мгц 5Гц Wifi примерно равно или чуть больше по облучению 40Мгц 2Гц Wifi.
Кроме этого увеличению ширины канала мешает выдача разрешений на использование частот.
Получается нужны новые алгоритмы для повышения скорости. Так как увеличение ширины канала при той же мощности приведёт уже к облучению пользователей.
Кроме этого практической пользы от повышения скорости (выше 2,4Гбит\с.) нет никакой. Стриминг 4к фильмов работает на 40-50Мбит., а передача больших файлов между ПК не совсем актуальна, есть множество других способов.
Как-то так.
Логичный вопрос: не облучает ли полоса в 160 МГц пользователя? Всё же передачу данных со скоростью 2Гб\с. по воздуху визуально очень страшно представить.
И обратный вопрос: если нет, то почему раньше не ввели 160Мгц? Зачем тянуть? Давайте сразу 1000Мгц и 300Гб.\с… что мешает?
Я думаю, нам всем надо только радоваться, что качество снимков чёрной дыры такое плохое.
И не дай бог нам увидеть её хотя бы в HD. Пускай телескопы размером с землю и дальше не могут её сфотографировать))
Всех с пятницей. Картинки отличные.
Я могу сделать Хабр, самым читаемым и обсуждаемым в мире сайтом, но ни у кого не хватит денег и понимания оплатить мне это.
Так что я и дальше буду делать это на бесплатном уровне ;)
алгоритмы прогрессивного стриминга всё равно не реализованы. Без них про 4к. можно забыть. Только FullHD.
Ну и вообще много вопросов: в каком формате? с какой скоростью? в каком количестве? в каком качестве? почему через браузер нельзя?
Какой-то ньюанс обязательно есть. Нормально позволяющая скачать, контора, даёт прямые ссылки, без лимита скорости, а тут столько ограничений.
возможности технологий таких компаний Эпл, Гугл, Нетфликс и Хулу ограничены авторским правом. Они не могут сохранять контент на диске и даже кэшировать его. Могут сохранять в шифрованном виде, но это увеличит нагрузку. И нет никаких гарантий, что пираты не найдут способ взломать его и наделать скандал из-за утечки защищённого контента. Например, 4к. видео или многоканального звука.
Получается никаких вам торентов, кэшей, прогрессивного стриминга и нате вам фризы, CDN системы, рекламы и деньги по любому чиху.
но у меня дома есть и проводной интернет. Он хоть 8к потянет.
Боюсь из-за не верно выбранного ПО, даже имея 1 Гигабит проводной канал дома можно получить фризы на 4к. картинке. В моём плеере используются уникальные алгоритмы (очень сложные, что бы это мог кто-то повторить), которые помогают освоить имеющуюся скорость интернета.
Кроме фильмов давно уже пора слушать музыку в форматах без потерь. Flac имеет скорость потока около 1 Мбита, а значит должен стримиться практически через любой канал без фризов. В моём плеере это именно так. Думаю, вы долго этого ещё нигде не встретите…
Т.е. если медиа файл весит 100 Мбайт, а его продолжительность 3 минуты, то получаем 3*60=180 секунд
100МБайт/180=0,55555 МБайт\сек. *8 = 4,44 МБит\сек. необходимая скорость интернета для его воспроизведения.
В моём плеере есть предзагрузка. Так что вам понадобиться не 4,44, а 4,3Мбит канал, для качественного воспроизведения этого контента.
Надеюсь, понятно объяснил.
Поставьте мой плеер. Там 4к. через 4G летает без фризов! Откройте для себя мир Hi-Rez.
Там используется прогрессивный стриминг. Поддерживаются http\ftp\samba\nmdc протоколы.
cloud boot, cloud gaming — вы сначала по WiFi это хотя бы сделайте. Какой там 5g. И даже для этого должно хватать скорости 4g (которая в стационаре выдаёт до 1ГБита).
облачные хранилища на более высокой скорости — туда же. Если сериалы смотреть хватает скорости, то и на облачные хранилища хватит.
А самое главное: зачем вам 5g? Когда мы 4g не полностью пользуемся. У кого 4g выдаёт все возможные 100м.\бит. хотя бы?
Скорость видео+аудио потока 4к. от 25МБит до 60Мбит. Т.е. для ещё не освоенного видео 4к. нам с запасом хватит 4G. А скорость выше 100МБит — просто, не существенно сократит время загрузки. Ну как часто вы качаете, через мобильный телефон большие файлы? (больше 500МБайт). А мелкие файлы (меньше 500МБайт) будут грузиться меньше минуты. Т.е. увеличение скорости даст сокращение времени на несколько минут максимум и в очень редких случаях.
Выходит нет практического применения сетей 5G.
п.с.: По моим подсчётам нужно больше оптимизировать софт. Например разные файловые менеджеры показывают кардинально (например 6МБит и 60Мбит) разную скорость закачки одного и того же файла, через одно устройство и одну сеть. Многие разработчики не знают, что есть новые алгоритмы загрузки данных, оптимизированные под высокие скорости. Для скоростей от 50МБит (для файлов примерно от 10Мбайт) нельзя применять обычный алгоритм: получаем-сохраняем. И потенциал развития алгоритмов в этой области ещё есть. Вот это надо развивать, а не сети 5G.
На практике необходимости в такой логике нет. Предзагрузки 0,2% от всего файла достаточно.
Что поделать. Ещё и оперативная память расходуется. Всё расходуется, не смотреть же на это. Ресурс там огромный. Память сейчас дешёвая… так что не важно.
Вон все современные телефоны имеют 128Гбайт памяти. Это неспроста.
Для мультимедиа это очень пригодиться.
По моим подсчётам для комфортного просмотра 4к. нужно будет 256Гб… Более нет смысла… фильм весит 80Гб… Можно хранить в кеше несколько на всякий случай… но на практике больше одного врятли будут сохранять. А остальная память на личные фотки\игры\видео\музыку.
Как раз эта скорость меня меньше всего волнует. В прогрессивном стриминге получение данных идёт постоянно. Миллисекунды которые тратятся на произвольный доступ к данным тратятся всего несколько раз и абсолютно не влияют на скорость передачи данных и комфорт. Запрос на получение данных с конкретного байта там один и сразу идут данные. Никаких особых отличий от http по скорости.
А, нужно соединение держать. Но это опять же ни на что не влияет, даже в многопоточном режиме (когда на каждую часть файла свой сокет на коннект ещё). Это всё ерунда, по сравнению с выше перечисленными пунктами.
WebDAV — инструмент для управления файлами. А я вам говорю, про передачу данных. В отношении http — это прямые ссылки с http сервера.
Если хотите управлять файлами вам нужен ftp — он для этого вообще-то и создан.
В http есть библиотека indexOf — она комфортно отображает дерево файлов в браузере. Но только для чтения. WebDAV — не использовал и пока не вижу практического смысла.
Повторяю: «кеширование мне всегда поможет!». Я закеширую всё что мне надо и буду смотреть 4к из кеша, а не из интернета. При этом закачка данных будет опережать воспроизведение и воспроизведение будет идти непрерывно.
Ну вот же! Как это так может случиться, что кеширование не помогает???
Предположим у вас фильм в интернете 100Гбайт. 4к…
В телефоне 128Гбайт и как раз есть 100Гигов свободных.
Канал у вас 100Мбит.\с. падающий до 5Мбит.\с. с переодичностью в 3 минуты.
Для воспроизведения необходимо 50Мбит.\с…
Вы запускаете:
— стриминг. И у вас через каждую минуту кино фризится и смотреть его невозможно. Кешируется 10-50Мбайт в оперативную память, чего хватает на 2,5 секунд видео. Когда кеш заполнен, получение данных останавливается совсем на эти самые 2,5 секунды. Т.е. получается вы используете полосу в 2 раза меньше, чем у вас, даже есть! + процесс установления связи и поиска нужного байта, с которого вам передавать данные, тоже занимает не мало времени.
+плеер, должен вообще поддерживать адаптивный размер буфера чтения для сокета (Tcp1323Opts), иначе это вообще не будет работать. Эта инновация появилась, когда скорости передачи данных превзошли 100Мбит… Т.е. совсем недавно. Но это сильно влияет на скорость впринципе.
Т.е. если у вас 100Мбит, то вы максимум сможете использовать 50Мбит. из-за всех этих задержек. И выйдет 50Мбит.\с. с падением до 2Мбит.\с… Конечно посмотреть ничего не получится. Я грубо считаю. Можете подсчитать точнее, уверен реальные цифры гораздо хуже.
— стриминг с записью в кеш. Тут не важно фриз у вас или не фриз в плеере, загрузка идёт параллельно и без остановок. Будет освоена вся полоса 50Мб.\с… Если канал реально позволяет вам воспроизвести видео, то вы его посмотрите максимум с одним фризом вначале, когда скорость разгоняется. Да, да скорость увеличивается, если качать непрерывно. Любая остановка при скачивании — это значительное падение скорости передачи данных. Даже на 10 миллисекунд!
И обратите внимание на современные проблемы в ПО для передачи данных. Как вы замеряли скорость? Протокол smb используемый в Windows, слишком перегружен версиями и настройками, так что даже Windows 10 реализация иногда глючит. Т.е. smb я бы не стал использовать для организации передачи больших объёмов данных. Самый быстрый и продвинутый сейчас http. На втором месте (при определённых настройках) идёт ftp.
Вот тут сравнение smb и обсуждение его скорости, которую, даже целая компания Google с их NDK клиентом не может поднять до http протокола.
Именно это и очень сложно понять. Однопоточный режим, да ещё и без кеширования:
1) загружается медленно, за счёт постоянных старт-стоп режимов загрузки и не эффективному использованию оперативной памяти при загрузке.
2) может вызвать фризы из-за перебоя связи.
3) может вызывать глюки у плеера из-за зависающих байтов при передаче.
4) может не использовать всю пропускную способность из-за ограничений ОС.
5) в этом режиме невозможно предзагрузить данные, что бы посмотреть, что-то с битрейтом выше, чем скорость сети.
6) невозможно использовать для загрузки с множества источников.
На самом деле достаточно одного из этих аргументов, что бы понять, что старый добрый ютубовский онлайн стриминг устарел и нуждается в замене. Но вот вам 6 причин перейти на новый стриминг и не увеличивать облучение всех людей на планете.
Я проверил мою технологию. Она не просто работает, а работает, как революция. Вы не можете понять, простое описание технологии, не то что её логику и код… может вам и не надо пытаться обсуждать такие вещи? Примите всё, как факт… тут не детский сад для детей.
Ага и многопоточность движения на дороге это тоже торрент))).
Стереотипное у вас мышление. У меня когда скорости не хватает, потоки наоборот соединяются в один поток. Когда нужно воспроизведение — лучше один поток, когда нужно скачать данные можно плодить потоки.
В общем я вижу вы не читали моё предыдущее сообщение.
То о чём я писал в предыдущем сообщении никто ещё и близко не делал. Кроме меня. А вы и дальше можете рассуждать, пока нужно делать.
Дома у меня 250 м.бит интернет и 900м.бит wifi, но онлайн 4к фильмы из торрентов это не позволяет смотреть. Всё равно тормозит и фризы. Не думаю, что увеличение скорости изменит что-либо.
Да, вы правильно понимаете. Я не дорос ещё до момента, когда надо передавать контент между пользователями. Как только дорасту, то сделаю это за пару дней.
Плеер ориентирован на музыку. Например 1000 человек захотели послушать один и тот же трек. Ну как захотели… естественно в разное время захотели. Так что бы прямо в одно время — это не реально, треков очень много.
Дальше, кто захотел, тот включил трек и скачал. Повторно они уже из кэша слушают. 600мб размер 3:40 трека. Получаем 600*8=4800Мбит… Допустим исходящая скорость сервера 100 МБит… Один пользователь получит файл за 4800/100 = 48 секунд. Это значит 220 секунд / 48 секунд= 4,5 человека могут одновременно смотреть онлайн 4к клип без фризов.
Вероятность, что из тысячи треков 5 и более пользователей в одни и теже 48 — 3:40 секунд захотят посмотреть один и тот же трек крайне мала. Ну разве что, это будет единственный 4к клип на сервере))) или единственный нормальный исполнитель на весь мир. Причём это будет первое прослушивание.
И да. Мой плеер опередил время. Он уже адаптируется и переходит из многопоточного в однопоточный режим в зависимости от скорости интернета (надо назвать это как-то. Всё же технология) для воспроизведения 4к контента.
Но в то же время, мы ещё не имеем таких девайсов, что бы можно было делиться 4к контентом, например. Для этого нужно минимум 128ГБ памяти в телефонах. А это ещё редкость.
Ну хорошо, что у вас храниться в 2ТБ? Что может быть таким большим? Ну и вы понимаете, что такой объём и необходимость передачи его по сети это крайне большая редкость.
п.с. должен заметить, нужно стремиться не к большим объёмам, а к меньшим. Сейчас всё сжимается и фильтруется.
То о чём вы говорите я победил. Проблема не в скорости, а в алгоритмах скачивания медиа-контента. Во всех плеерах они сейчас до боли простые — скачать и воспроизвести, скачать и воспроизвести. Отсюда фризы… пока видео воспроизводится — оно не скачивается.
Мой плеер адски многопоточный. Там на каждый чих свой поток. Ну и конечно загрузка медиа-контента происходит в отдельном потоке, который практически не взаимодействует с плеером.
Выходит: для устранения фризов необходимо место на флешке, что бы контент можно было полностью скачать пока смотришь. + хорошо используется оперативная память, так как контент грузится сначала в оперативную память.
А вот скорость передачи данных подойдёт почти любая.
У меня 4k видео в машине в Москве воспроизводится без фризов в телефоне. 4k клипы слушаю пока в пробках стою… через 4g.
Флак так ему вообще что-то около 1,5-2 Мбита нужно…
Так как у меня используется предзагрузка, так что скорость передачи данных может быть, даже, немного ниже битрейта медиа.
40-80 Мбит\с. достаточно для воспроизведения супер тяжёлых 4к blue ray фильмов, весом 40-80Гбайт.
Так что попробуйте мой плеер. Уверен 4к видео через него будет летать.
Из этого всего вывод такой: практическая необходимость высоких скоростей отсутствует. Мы просто будем больше облучать себя. А 100Мбит\с. хватит всем.
Особенно когда я добавлю ещё передачу контента между клиентами, предсказание и кеширование следующих действий.
Вот! в чём будущее, а не в глупых увеличениях скоростей передачи данных.
Чёрным по белому и всё равно каждый видит своё…
Alexeyslav — один прочитал и понял. Остальные я не знаю о чём пишут.
Но ответа я так и не услышал…
Итого, я думаю:
Если
то 160Мгц 5Гц Wifi примерно равно или чуть больше по облучению 40Мгц 2Гц Wifi.
Кроме этого увеличению ширины канала мешает выдача разрешений на использование частот.
Получается нужны новые алгоритмы для повышения скорости. Так как увеличение ширины канала при той же мощности приведёт уже к облучению пользователей.
Кроме этого практической пользы от повышения скорости (выше 2,4Гбит\с.) нет никакой. Стриминг 4к фильмов работает на 40-50Мбит., а передача больших файлов между ПК не совсем актуальна, есть множество других способов.
Как-то так.
И обратный вопрос: если нет, то почему раньше не ввели 160Мгц? Зачем тянуть? Давайте сразу 1000Мгц и 300Гб.\с… что мешает?
И не дай бог нам увидеть её хотя бы в HD. Пускай телескопы размером с землю и дальше не могут её сфотографировать))
Всех с пятницей. Картинки отличные.
Так что я и дальше буду делать это на бесплатном уровне ;)
Ну и вообще много вопросов: в каком формате? с какой скоростью? в каком количестве? в каком качестве? почему через браузер нельзя?
Какой-то ньюанс обязательно есть. Нормально позволяющая скачать, контора, даёт прямые ссылки, без лимита скорости, а тут столько ограничений.
Получается никаких вам торентов, кэшей, прогрессивного стриминга и нате вам фризы, CDN системы, рекламы и деньги по любому чиху.
Боюсь из-за не верно выбранного ПО, даже имея 1 Гигабит проводной канал дома можно получить фризы на 4к. картинке. В моём плеере используются уникальные алгоритмы (очень сложные, что бы это мог кто-то повторить), которые помогают освоить имеющуюся скорость интернета.
Кроме фильмов давно уже пора слушать музыку в форматах без потерь. Flac имеет скорость потока около 1 Мбита, а значит должен стримиться практически через любой канал без фризов. В моём плеере это именно так. Думаю, вы долго этого ещё нигде не встретите…
Т.е. если медиа файл весит 100 Мбайт, а его продолжительность 3 минуты, то получаем 3*60=180 секунд
100МБайт/180=0,55555 МБайт\сек. *8 = 4,44 МБит\сек. необходимая скорость интернета для его воспроизведения.
В моём плеере есть предзагрузка. Так что вам понадобиться не 4,44, а 4,3Мбит канал, для качественного воспроизведения этого контента.
Надеюсь, понятно объяснил.
Там используется прогрессивный стриминг. Поддерживаются http\ftp\samba\nmdc протоколы.
облачные хранилища на более высокой скорости — туда же. Если сериалы смотреть хватает скорости, то и на облачные хранилища хватит.
п.с. ответа не ждите.
Скорость видео+аудио потока 4к. от 25МБит до 60Мбит. Т.е. для ещё не освоенного видео 4к. нам с запасом хватит 4G. А скорость выше 100МБит — просто, не существенно сократит время загрузки. Ну как часто вы качаете, через мобильный телефон большие файлы? (больше 500МБайт). А мелкие файлы (меньше 500МБайт) будут грузиться меньше минуты. Т.е. увеличение скорости даст сокращение времени на несколько минут максимум и в очень редких случаях.
Выходит нет практического применения сетей 5G.
п.с.: По моим подсчётам нужно больше оптимизировать софт. Например разные файловые менеджеры показывают кардинально (например 6МБит и 60Мбит) разную скорость закачки одного и того же файла, через одно устройство и одну сеть. Многие разработчики не знают, что есть новые алгоритмы загрузки данных, оптимизированные под высокие скорости. Для скоростей от 50МБит (для файлов примерно от 10Мбайт) нельзя применять обычный алгоритм: получаем-сохраняем. И потенциал развития алгоритмов в этой области ещё есть. Вот это надо развивать, а не сети 5G.