Сегодня никого не удивить скоростью интернета 100 Мбитс., но существует проблема, как её использовать. Все основные операции загружают сеть не полностью. Одновременно с этим более высокую популярность получают тяжёлые форматы аудио и видео 4k-8k, которые хочется смотреть онлайн. И глядя на высокие скорости интернета, возникает логичный вопрос — а почему этого нет? Как освоить всю скорость предоставляемую провайдером? Как со стороны клиента, так и со стороны сервиса. Рассмотрим все эти вопросы в статье.
Я сделал действительно хороший программный продукт и хочу рассказать подробнее, как там всё устроено. Там много новых технологий. Возможно, потому что в этой отрасли давно уже никто ничего не изобретал, а время пришло. Статья эта не только для разработчиков, но и для обычных людей. Я постарался объяснить всё, как можно проще.
1. Начнём с базовых основ сегодняшних технологий передачи данных.
Существует большой пробел в знаниях многих людей по алгоритмам передачи данных на высоких скоростях — более 10 МБитсек… Давайте восполним эти пробелы:
Пробел №1. Проблема в том, что совокупность технологий радиопередачи сейчас ориентирована на непрерывную передачу данных, как наиболее лучший сценарий.
Всё что передаётся по wi-fi3G4G и даже по проводам будет быстрее всего передаваться, если передача будет постоянная, пусть даже с меньшей скоростью, чем максимальная. Это будет на много быстрее, чем передавать с перерывами, но на максимальной скорости.
Причины:
- для возобновления связи в трафик добавляется больше служебной информации;
- при возобновлении связи сервер может понизить клиентский рейтинг и отдавать данные с меньшей скоростью (возможно из-за появления других клиентов), либо вообще не отдавать. Даже в домашней wi-fi сети роутер может понизить рейтинг, например, из-за wi-fi пылесоса. Т.е. это относится ко всем сетям где есть больше 2х клиентов. В общем-то почти ко всем :-)
Пробел №2. При копировании данных любая программа пользуется неким «ковшом», который черпает данные в источнике и переносит их в место назначения. Так вот этот ковш в зависимости от скорости передачи данных должен быть разных размеров. Это просто понять: если черпать чайной ложкой ведро воды, то это займёт на много больше времени, чем черпать кружкой.
Пробел №3. Для повышения скорости загрузки данных по сети, должна использоваться оперативная память. Любые малейшие миллисекунды задержки, при записи поступающих данных выливаются потом в секунды, минуты и часы. Что бы этого не происходило нужно писать данные сначала в оперативную память, а затем более объёмным «ковшом» на постоянный носитель (жёсткий диск). Иначе скорость передачи данных будет драматически падать.
Этого достаточно, что бы просто копировать файл.
2. Эти пробелы, лишь верхушка айсберга. При обычной передаче файлов этого достаточно, но что, если наш файл мультимедийный, и мы должны запустить его воспроизведение онлайн. Современный мультимедийный файл не может полностью помещаться в оперативную память, поэтому необходимо предусмотреть сохранение его на диск.
Самая лучшая стратегия строится из выше сказанного о пробелах:
- загрузка данных должна происходить независимо от воспроизведения, непрерывно;
- для обеспечения перемотки, необходимо создавать ещё один поток загрузки данных;
- для преодоления фриза при старте, из-за получения технических данных (кодеках и.т.п.), необходима предзагрузка. Опытным путём я нашёл формулу: размер всего файла * 0.002 или 0,2%.
Этого достаточно для воспроизведения Flac файлов.
3. Получается для онлайн-стриминга, который будет рационально и полноценно использовать наш канал связи, нужна оперативная память и место на диске. Без этого канал будет использован не полностью.
И тут начинается ветвление алгоритмов загрузки данных! Без технических подробностей приведу их в примерном объёме:
- для того что бы данные два раза не скачивались необходимо сделать столкновение потоков. Т.е. если мы запустили трек и быстро перемотали в середину, то первый поток, дойдя до середины, должен прервать свою работу.
- для того что бы данные два раза не скачивались, поток не должен создаваться, если данные уже загружены.
- для нормального воспроизведения необходима сложная логика взаимодействия потока плеера и потоков, закачивающих данные.
Я всё это сделал и немного больше. Получилось совершенно сказочно. Данные летают и воспроизведение не прерывается. Flac файлы закачивались полностью на 1-3 секунде воспроизведения. И этого стало достаточно для воспроизведения Full HD видео.
4. Проблема в том, что медиа файлы у нас сильно отличаются в размерах. И с 4k Blu-Ray фильмами, которые весят около 80-120 Гбайт, ничего не получилось. Плеер создавал 15 потоков на старте, и они все делили между собой скорость, которой, конечно, не хватало для главного потока, которого ждал плеер. Данные грузились на максимальной скорости, да… загружали полностью канал, но 4k видео висело и воспроизводилось медленнее, чем слайдшоу. Получается много потоков это вред для 4k видео, но где та граница, после которой польза в Full HD переходила во вред в 4k?!
В итоге всё упёрлось в скорость канала. Для того что бы оптимизировать работу потоков необходимо знать две вещи:
а) Необходимую скорость для воспроизведения, которая вычисляется: (размер файла / его длительность в секундах) * 8.
б) Скорость загрузки данных главным потоком, с которым работает плеер в данный момент.
Если мы управляем загрузкой данных, то у нас обязательно есть возможность измерить скорость загрузки. Теперь каждый поток знал свою скорость (в Мбитсек.) и это не накладывает дополнительных расходов на производительность. Обязательно нужно обозначить с каким потоком в данный момент работает плеер. Всё начинается в обычном, многопоточном режиме. Но как только плеер вычисляет длительность медиа-файла в секундах и передаёт эти данные, то все потоки получают фиксированную, необходимую скорость для воспроизведения. Сразу после этого все потоки (кроме главного) сравнивают необходимую скорость со скоростью главного потока и если его скорость ниже, то становятся на паузу. Далее, главный поток медленно наращивает свою скорость, и как только, он превышает в два раза (так сделал я) необходимую скорость, то он снимает с паузы все второстепенные потоки.
По наблюдениям, далее, через некоторое время, скорость основного потока снова падает и все второстепенные потоки опять переходят в паузу, и так пока не докачаются данные или воспроизведение не завершиться. Такая гибкая стратегия, когда загрузка данных параллелится и при необходимости сжимается в один поток, полностью загружает канал связи и одновременно обеспечивает максимально быструю загрузку, именно, необходимых для воспроизведения данных. Эта стратегия одинаково хорошо работает на файлах и 10 Мбайт и 100 Гбайт. Для воспроизведения по сети без потерь, невозможно придумать ничего лучше. Если есть предложения буду рад обсудить их в комментариях.
Подходит для воспроизведения медиа файлов любых объёмов 4k-8k.
Прогрессивный стриминг — самый быстрый вид стриминга, при передаче данных в исходном качестве. Для повышения скорости передачи данных он задействует оперативную память и мультипоточность. Данные загружаются асинхронно потоку воспроизведения, но при активном взаимодействии с ним. Во время воспроизведения измеряется скорость получения данных, и количество активных потоков адаптируется под доступный канал передачи данных.
Именно сейчас в мире идёт большая тенденция к увеличению количества видео в высоком разрешении, и рост популярности устройств для его воспроизведения.
Источник www.vox.com
Битрейт 4k видео большой, но не заоблачный. Самый эффективный кодек VP9 на сегодня сжимает 4k видео в 25 Мбитсек. с аудио выходит около 30. Blu-Ray фильм в 100 Гбайт имеет битрейт около 60 Мбитсек… Эти скорости интернета есть у любого в мире, желающего посмотреть 4k видео. Это значит 4k видео можно смотреть онлайн уже сейчас!
Не смотря на простоту описанного выше алгоритма, реализация выглядит очень сложно. Технологии стриминга с ухудшением качества видео и аудио, вынуждены портить контент из-за отсутствия реализации правильного алгоритма передачи данных. Я предполагаю, что у многих людей и компаний есть (вышеописанные) пробелы в знаниях и, конечно же, трудности в реализации данного алгоритма. Поэтому и написал статью, что бы упростить понимание этого способа стриминга.
Будет немного сложнее сделать этот алгоритм с использованием авторских прав, но в целом тоже возможно. При сохранении на диск, и чтении, необходимо шифровать данные. Выглядит это, как вражеские действия против пользователя, но что поделать. Некоторые компании этим занимаются.
А теперь посмотрим на недостатки обычного стриминга, по сравнению с прогрессивным:
- невозможно предзагрузить следующий файлпредугадать и подготовить следующее действие;
- даже, при временном отключении интернетаперебоях в скорости появится заметный фриз звукаизображения;
- канал связи не используется полностью, и половину времени воспроизведения простаивает, в то время, когда данных надо грузить ещё много;
- невозможность воспроизводить 4k-8k видео, даже по wi-fi без фризов. Постоянные порывы связи и скачки скорости до максимума не выдержит, даже домашний wi-fi на протяжении всего фильма — это 2 часа и более;
- это накладывает ещё большую нагрузку при воспроизведении 4k контента, так как плееру нужно держать в оперативной памяти от 200-300 Мбайт данных видео (при необходимой скорости 60 Мбитсек.). При воспроизведении через прогрессивный алгоритм стриминга эта необходимость отпадает, так как воспроизведение идёт с диска, а не по сети.
По этим пунктам понятно, что стримить, как раньше уже нельзя. Конечно можно нарастить скоростипамятькеш в десятки раз, но зачем, если сегодняшних скоростей уже достаточно и проблема кроется в алгоритмах. Плохие алгоритмы рано или поздно заходят в тупик. На сегодня прогрессивный стриминг — единственная технология позволяющая стабильно и комфортно смотреть 4k 100 Гигабайтные фильмы онлайн.
Как пример работы технологии, я написал мультимедийное приложение Media Library. Оно может использоваться, как прослойка для других плееров, так как открывает http прямые ссылки и может использовать внешний плеер для их воспроизведения. Возможно потребуется оптимизация под некоторые плееры, но, например, MxPlayer работает точно.
Сценарий использования:
- Вы открываете прямую ссылку из стороннего приложения (пример: HDVideoBox, Es Проводник) с помощью плеера.
- При открытии, в плейлист добавляется элемент с этой ссылкой и начинается воспроизведение. Его необходимо остановить, либо можно сразу перейти к следующему пункту.
- Свайп в право нового элемента откроет меню в котором необходимо выбрать «Открыть с помощью...» и далее выбрать, например MxPlayer.
В таком сценарии будут использованы все вышеописанные алгоритмы получения данных и MxPlayer. Моё приложение поддерживает следующие протоколы: nmdchttpftpsamba, следовательно все эти протоколы поддерживает и внешний плеер.
Видео файлы 4k весом 100 Гбайт воспроизводятся с минимальными задержками и скачиваются в память на максимально возможной скорости. Можно предзагрузить больше данных, просто нажав паузу, но, как правило это не требуется. Воспроизведение всегда стабильное, если не стабильная скорость канала находится около необходимой скорости для воспроизведения.
Из-за вышеописанных пробелов политика самых крупных компаний складывается не совсем правильным образом, что замедляет прогресс и часто не даёт пользоваться имеющимися устройствами и каналами связи в полном объёме.
В приложении предусмотрено сохранение кеша на внешний носитель, но из-за странного усложнения доступа к внешним носителям компании Google, в данный момент поддерживается в основном устройствами фирмы Samsung и версией Android 5.0+. В дальнейшем появится полная поддержка внешних usb носителей.
В целом, алгоритм существенно повышает качество и скорость загрузки данных при стриминге, как небольших файлов 30-50 Мбайт, так и больших 50-120 Гбайт.
В перспективе может использоваться:
- для качественного воспроизведения 4k-8k медиа контента на мобильных телефонах, телевизорах и других устройствах;
- в виртуальной реальности для отображения объёмных сцен в высоком разрешении;
- в сочетании с торрент подобными, пиринговыми протоколами;
- для качественного воспроизведения музыки в высоком разрешении на любых устройствах. Опытное тестирование показало, что для этого достаточно 5 Мбит не стабильного канала связи.
Автор: Master255
