Содержание
Прошу совета у лиги айтишников, по всей видимости.
Часто смотрю обучающие видосы на ютубчике и иже с ними. Долгое время страдал по поводу того, что видос длинный но блин сцуко автор выдает всю инфу необходимую за 5мин в середине видео.
В какой-то момент один хороший человек подсказал расширение для хрома Video Speed Controller, которое позволяет в разы ускорить видео.
Теперь потраченное на нудятину время сокращается в двое минимум. (Со временем голова привыкает и даже ценную инфу можно воспринимать на большой скорости хорошо. Черт побери, похоже это суперспособность "скоровидение". Если такой фигни еще нет, то я ввожу. =))
Уважаемые знатоки, внимание вопрос. Есть ли аналог или что-то похожее для андроида?
Хочу лежать вечерком на диванчике и смотреть обучалки с планшета, ибо за день сидение за компом уже запаривает.
Может есть специальные плееры или дополнения к плеерам, да что угодно.
Из возможных костылей придумал пока только просмотр через тимвьюевр, но это мягко говоря убожество. Попробовал погуглить, попадаются только приложение для создания этого самого видео, а просто для ускоренного просмотра не находится.
Может есть какой то потоковый плеер нестандартный с такими доп функциями?
Выражаясь манагерским наречием, планшет — это средство потребления контента.
А если по-человечески, то это миниатюрный кастрированный ноутбук, смартфон-переросток без телефонной части, называйте как хотите, оптимизированный для удобного хождения по сети, просмотра цветных документов, от книг и статей до журналов, просмотра видео и прослушивания музыки (более видео, конечно же) в самых разных местах. А также запуска разного рода софта.
Google — компания сервисная, и потому они не только заботливо выпилили из планшета слот для SD карт, но и поставили немного флэш-памяти. Собственно , флэш-памяти всегда мало, ибо всё равно нельзя держать там пачку фильмов и сборники альбомов с музыкой. Да и заливать по usb/wifi -замучаешься.
"Смотрите с you-туп" , говорит нам Гугль.
Но для того ли тут стоит прекрасный экран с самым высоким в мире , среди планшетов (на сегодняшний день) разрешением 2560×1600, чтобы мы смотрели убогие клипы с youtube ?
Да, там есть 720р и даже 1080р, попадаются интересные, но мало, да и не фильмы, а именно что клипы и небольшие любительские съемки.
Естественное желание — смотреть качественное видео, причём по сети. И вот тут начинается трэш.
Допустим, аудио и видео у нас лежат на компе или сетевом хранилище, доступ по Самбе (smb, cifs) или ftp. NFS я тут не рассматриваю по понятным причинам.
Но. стоковое ядро не умеет маунтить smb шары ! FTP тоже не умеет.
Манагеры Гугла говорят нам "а пошли вы на . you-туп"
Что, разумеется, неинтересно.
Так что или ++модули (рут), или другое ядро (тоже рут), или плеер должен уметь лезть на smb/ftp шару сам, или прокси.
Проксировать видео и аудио умеют некоторые файл-коммандеры, например, ES.
Но, во-первых, скорость работы по Самбе у последнего ES в разы меньше, чем по ftp (не знаю, как это они так криво написали), а во-вторых, не все плеера нормально воспринимают трансляцию со 127.0.0.1. Некоторые при перемотке ругаются.
Сами лазить по сетевым smb шарам умеют dice, BS player.
Очень приличный MX player не умеет. Также он не умеет играть dts звук, это ограничения лицензии на dts, что может быть исправлено подсовыванием сторонней ffmpeg либы ему для декодирования звука.
BS player — умеет smb.
Сетевого eth адаптера нету (маньяки заставили работать с usb-net адаптером, но это извращение) , что логично, только wifi.
Формально скорость wifi, при условии хорошего соотношения сигнал-шум, огромна, и может достигать 300Мбит/c , что примерно на порядок перекрывает полосу, необходимую для самых тяжелых fullHD bluray-rip. И даже сами блюреи не бывают с битрейтом более, чем 50-60 Мбит/c.
Правда, на практике теоретические 300 оборачиваются в лучшем случае 150-180 практических Мбит/с. Казалось бы, это тоже в 5 раз больше, чем надо для тяжелого рипа.
Но на практике всё иначе: не только в предельно загаженном в любом городском районе с плотной застройкой диапазоне 2.4 ггц, но и 5 ггц, где помех пока что минимум, никаких стабильных, постоянных, гарантированных полос не то, что в 100-150, но даже и в 20-50 Мбит нету.
Ни с какими wifi точками доступа и адаптерами (как минимум, мне такие неизвестны), никакие антенны не могут решить эту проблему полностью.
У вас может быть _в_среднем_ и 50, и 80, и даже 150 реальных Мбит — но временами будут провалы если не до нуля, то до нескольких мегабит. В случае отличного С/Ш и хорошего железа у вас будет выше скорость и меньше провалов, но они гарантированно будут.
На видео с малым битрейтом, 1...4 Мбита, это несущественно, все работает практически без проблем.
Тяжелые фильмы, с высоким битрейтом, 10. 20 Мбит (а в пиках все 30-35), при таком раскладе не идут — плеера начинают разбивать картинку в мусор, а потом уже начинает задыхаться от нерегулярного потока данных программно-аппаратный декодер. Всё, все свободны, это у вас играть не будет.
Вам просто нечем кормить экран с огромным разрешением и процессор, для видеодекодера которого заявлено 1080p 60 fps / h264.
Способ решения этой проблемы известен очень давно, он прост как по сути, так и в реализации. Это буферизация потока данных. Пусть у нас постоянно случаются пропадания и прыгает скорость, но , загнав в буфер Х (или даже ХХ) секунд видео , мы без проблем обеспечим стабильный поток данных для декодера.
И тогда для нас снова будет критичной средняя скорость передачи данных, а не минимально-гарантированная. Вторая очень мала, близка к нулю при любом варианте wifi, а первая — более чем достаточна не только в случае 5ггц и 2х mimo /40 мгц полосе, но даже при простом 2.4 ггц /20 мгц.
Итак, смотрим плеера под Андроид. Системный — это просто шутка какая-то, а не плеер.
VLC beta — глючный, зато играет почти всё, как и его десктопный родственник. Нет, про нормальную буферизацию его авторы не слышали (если кто скажет, где она тут включается — будут рад проверить).
Dice — про нормальную буферизацию его авторы тоже не слышали. И ещё многого не слышали.
MX player — то же самое, буферизация но практически никакая.
BS player — приятное исключение. И сам плейер хорош, всеяден и с кучей настроек, и работа по сети продумана (умеет самостоятельно лазить по smb шарам и играть аудио-видео оттуда), и, главное,
отлично сделана буферизация потока данных.
Включение нескольких опций в настройках (максимально использовать возможности аппаратного декодирования для всех кодеков, wifi производительный режим, большие буфера) приводит к тому, что практически без проблем по сети играется очень тяжелый рип со средним битрейтом в 18-20 Мбит и пиками в 30.
При перемотке — корректно отрабатывает. Скорость — 40+ Мбит по smb/cifs выдаёт.
У меня очень простые вопросы к авторам остальных видеоплееров : вы вообще задумывались, что и как будут играть с помощью ваших программных продуктов ?
Вы в курсе, что единственный скоростной сетевой интерфейс в планшетах (и смартфонах) — wifi ?
В курсе, как он работает ? (И как будет работать, какие бы вы точки доступа и адаптеры не ставили.)
И что переписывание любого видео сначала на внутренний флэш (или даже на съемную карточку), до просмотра, не является самым удобным режимом для большинства пользователей ?
По факту, авторы большинства плееров — не в курсе. Им это безразлично.
Талантливые инженеры создают чудо-процессоры, с высокой степенью интеграции всего и вся на чипе , с прекрасными ядрами центрального процессора, 2D & 3D ускорителей, мощными кодерами jpeg, видео кодерами & декодерами, способными обрабатывать чудовищные потоки 1080p/60 fps, системные программисты пишут под них драйвера, и они даже работают,
а потом 90% прикладных программеров пускают это всё коту под хвост.
Смотрите на вашем прекрасном железе vga ролики с "you-туп".
А вот для того, чтобы взять много музыки и видео с собой, в случае Nexus 10 вам понадобятся usb otg кабель, root права и настройка автомаунта usb катрочек и флэшек.
Благо Nexus 10 это умеет, хлоп ! и у вас уже поключён внешний накопитель.
update. Программный декодер MX плеера для dvd/mpeg2 с ресайзом таки хорош, ощутимо лучше BS player. Чуть лучше цвет, некоторое уменьшение шума (работа декодера в итоге выглядит как мягкий качественный шумодав, детали не съедаются), и аккуратный ресайз до размера экрана планшета.
В этой заметке я хочу рассказать о некоторых подводных камнях, с которыми можно столкнуться при работе с потоковым видео в Android приложениях. Конкретно, речь пойдёт о конвертации видео и протоколах доставки/воспроизведения видео.
Сразу оговорюсь, что экспертом я в данной области не являюсь, а лишь хочу поделится недавно полученным опытом.
Представим, что перед вами стоит задача реализовать Android приложение, способное проигрывать множество файлов, заливаемых пользователями на ваш сервер. Написать свой youtube, с блекджеком и кодеками. Для этого вам придётся решить как минимум две задачи: конвертации видео к поддерживаемому на Android формате, воспроизведение видео с удалённого источника. Рассмотрим обе эти задачи более подробней.
Конвертация видео
И так, прежде чем воспроизвести какое-то видео нашем Android устройстве, надо это видео перекодировать в поддерживаемый формат. В документации к Android чётко обозначен список этих самых форматов.
Для того, что бы перекодировать файлы, заливаемые пользователями на ваш сервис, или же записать поток с TV-тюнера, вам потребуется помощь специальной утилиты ffmpeg, являющейся де-факто стандартом в отрасли. Подробную инструкцию по её установке можно найти на сайте одноимённого проекта.
Наиболее распространённым сейчас (на мой взгляд) способом хранения видео является контейнер MP4 с использованием кодека H.264 AVC. Их мы, собственно, и рассмотрим.
Первым делом обратите внимание, что Android поддерживает не все возможности кодека H.264, а только определённый набор — профиль, именуемый Baseline Profile (BP). Так, например, в BP не входят такие полезные фичи H.264 как CABAC или B-Frames.
Для нас это значит, что если мы будем использовать эти фичи при кодировании видео, то Android проигрывать это видео будет не обязан. Хотя и может, если ваш телефон достаточно мощный и вендор позаботился об установке и поддержке дополнительных кодеков. Так, например, видео в Main Profile без проблем проигрывается на Samsung Galaxy SII. На телефонах же обычного класса (например, Samsung Galaxy Ace) мы получим сообщение о невозможности воспроизведения видео и ошибку с кодом неверного кодека в logcat'е.
Но перейдём от теории к практике. Для того, что бы пережать видео, необходимо выполнить следующую команду:
ffmpeg -i in.3gp -f mp4
-vcodec libx264 -vprofile baseline -b:v 1500K
-acodec libfaac -b:a 128k -ar 44100 -ac 2
-y out.mp4
Рассмотрим подробнее каждый из параметров:
- -i src входной (перекодируемый) файл;
- -f mp4 используемый видеоконтейнер;
- -vcodec libx264 используемый видеокодек;
- -vprofile baseline используемый профиль;
- -b:v 1500K bitrate;
- -acodec libfaac используемый аудиокодек;
- -b:a 128k аудио bitrate;
- -ar 44100 частота звука;
- -ac 2 количество аудиопотоков;
- -y флаг перезаписи выходного файла;
Так же стоит отметить, что можно обойтись и без указания профиля, а явно включить/отключить нужные опции кодека H.264 через параметр -x264opts, так что бы они удовлетворяли условиям BP. Но это же занятие для любителей.
Раздача видео
Самый простой способ воспроизвести видео с удалённого сервера — это скачать его во временное хранилище и воспроизвести локально. Однако, думаю всем понятно, что в виду размеров современных видеозаписей — это не вариант.
Как же быть? Платформа Android предлагает нам нативную поддержку следующих технологий/протоколов:
- HTTP/HTTPS progressive streaming;
- HTTP/HTTPS live streaming;
- RTSP (RTP, SDP);
Рассмотрим их по порядку.
Progressive streaming
Наиболее простой способ раздачи видео с помощью обычного web-сервера, сводящийся по сути к скачиванию заранее подготовленного файла по HTTP (S) протоколу. Вся соль в данном случае заключается в том, что воспроизведение файла начинается не по окончанию загрузки, а как только будет скачано достаточно данных (наполнен некоторый буфер).
Тут стоит уточнить, что при использовании контейнера MP4, необходимо сформировать файл так, что бы метаданные о видео потоке (moov atoms) располагались в начале файла (после атома ftyp), перед видеоданными (mdat atoms). Сделать это можно с помощью обработки файла утилитой qt-faststart:
Основной проблемой progressive streaming'а является невозможность перемотки видео к нескачанному моменту, наличие достаточного количества свободного места на устройстве и необходимость поддержки большого числа «толстых» клиентов, скачивающих видео, на web-сервере.
Воспроизведение с помощью данной технологии поддерживается платформой Android нативно. Вы без проблем (если не считать канал связи, мощность девайса и наличие свободного места) сможете проиграть удалённый файл с помощью стандартного класса MediaPlayer.
Pseudo streaming
Данная технология является логическим расширением progressive streaming'a и позволяет решить одну из его главных проблем — перемотки к ещё не скачанному фрагменту. Применима для контейнеров MP4/FLV с кодеком H.264/AAC.
Единственным отличием от progressive streaming'a в данным случае является, тот факт, что вам потребуется специальный web-сервер, который с учётом временной метки в GET-запросе будет отдавать нужный вам фрагмент видео файла. Примером такого web-сервера естественно может служить православный NGINX с его ngx_http_mp4_module.
Мне не удалось найти какой-либо официальной информации относительно поддержки данного стандарта в Android. Однако, эмперическим путём было установлено, что она присутствует как минимум на устройствах HTC Desire и Samsung Galaxy SII. Однако, хочу обратить внимание, что да же в случае отсутствия нативной поддержки на вашем устройстве всегда можно воспользоваться сторонними плеерами типа MX Player, которые самостоятельно реализуют логику скачки и воспроизведения фрагментов видео с нужной временной меткой, что позволяет организовать перемотку.
Live streaming
Довольно нестандартный протокол передачи данных от компании Apple. Суть его сводится к тому, что раздаваемый файл «пилится» на множество небольших частей, объединяемых спецтальным файлом-playlist'ом формата M3U8. Передача данных происходит по протоколу HTTP (S).
Ни каких проблем с перемоткой и свободным местом на устройстве в данном случае не возникает. Более того, при некоторых условиях у вас появляется возможность выбирать качество проигрываемого видео.
Однако, появляются и проблемы. Для «распила» файла и создания playlist'а потребуется ресурсы процессора, время и место на сервере. Для вещания файла в сеть, как и в предыдущих примерах, потребуется HTTP сервер (без каких-либо дополнительных модулей).
«Распилить» видео файл можно использовать VLC:
vlc -I dummy /path/to/pornofilm.mpg vlc://quit --sout '#transcode
Воспроизвести такой файл можно по URL localhost/pornofilm.m3u8.
Поддержка HTTP Live Streaming на нативном уровне в Android присутствует начиная с версии 3.0. С помощью сторонних плееров (DicePlayer, MX Player), судя по wiki, можно добиться поддержки с версии 2.2.
Real Time Streaming Protocol (RTSP)
Протокол прикладного уровня с поддержкой состояния, разработанный специально для передачи видео. Формат команд очень напоминает HTTP. Сами же команды напоминают кнопки на обычном кассетном магнитофоне: PLAY, PAUSE, RECORD и т.д.
В отличие от HTTP Live Streaming RTSP не требует разбиения фалов на мелкие части и составления playlist'ов. Нужные части файла будут генерироваться и отдаваться клиенту налету. В качестве RTSP сервера можно использовать VLC.
Стоит заметить, что сам протокол RTSP не определяет способ передачи данных, а делегирует это другим протоколам. Например, RTP. Для вещания файла по протоколу RTP нужно будет запустить VLC со следующими параметрами:
Однако, поднимать для каждого файла свой процесс с отдельным портом вне зависимости от наличия пользователей, желающих его просмотреть, было бы глупо.
Поэтому вернёмся к протоколу RTSP и воспроизведению видео по требованию (Vidoe On Demand). Для того, что бы использовать VLC в качестве RTSP сервера для проигрывания VOD необходимо прежде всего запустить VLC, указав атрибуты RTSP сервера и Telnet интерфейса:
vlc -vvv -I telnet --telnet-password 123 --rtsp-host 127.0.0.1 --rtsp-port 5554
После этого как сервер запущен, необходимо произвести его настройку. Делать это удобнее всего с помощью telnet'a, так как такой подход даёт возможность настройки налету:
setup porno input /path/to/pornofilm.mpg
Для воспроизведения видео (в том числе и на платформе Android) необходимо запросить его по URL rtsp://localhost:5554/pornofilm.
Из недостатков можно отметить тот факт, что HTTP открыт зачастую на всех firewall'ах и проксях… с RTSP в случае политики Deny,Allow всё иначе.
Кроме того, при использовании RTSP-сервера для добавления/удаления файлов на сервере придётся обновлять его конфигурацию (список vod'ов). Да, для этого есть telnet, но это всё равно сложнее, чем просто заливать или удалять файлы из каталогов web-сервера.
Воспроизведение с помощью данной технологии поддерживается платформой Android нативно. Например, с помощью всё того же стандартного класса MediaPlayer.
Multicast
Многие считают, что multicast не работает в Android. Это не совсем так.
Во первых, в большинстве случаев он просто отключен по умлочанию, что бы не грузить ресурсы девайса лишней работой. Его можно просто включить.
Во вторых, да — на довольно внушительном количестве устройств он отключен во все или работает некорректно. В интернетах, поэтому поводу можно найти много слёз и даже некоторые решения.
Однако, как показывает практика, проигрывать multicast видео на Android всё можно. В моём случае с этой задачей удачно справился недавно вышедший VLC Beta для Android.
Кроме того с помощью VLC-сервера всегда можно свести воспроизведение multicast'a к HLS:
vlc -I dummy udp://@192.168.20.1:1234 vlc://quit --sout '#transcode
new multicast-porno vod enabled
setup multicast-porno input udp://@192.168.20.1:1234
Попытать удачу с проигрыванием multicast'a на вашем устройстве вы можете, передав плееру URL вида udp://@192.168.20.1:1234.
Что выбрать
Если с форматом видео всё ясно (H.264 BP / MP4), то со спобом дистрибуции вопрос открыт. У каждого их них есть свои достоинства и недостатки.
Первым делом из рассмотрения я бы убрал обычный progressive streaming. Да он работает всегда и везде, но отсутствие перемотки и загрузка всего файла целиком — это уже слишком.
Следующим кандидатом на вылет является live streaming. Главным его недостатком является нативная поддержка в Android начиная с версии 3.0. А игнорирование более 80% пользователей c версией 2.x — не вариант. Хотя тут можно посмотреть на сторонний плеер, или заняться собственной реализацией (свободных наработок для поддержки HLS я, увы, не нашёл).
И последним я бы вычеркнул RTSP. Да, это протокол, разработанный специально для видео. Да, его использование идейно верно. Но есть два момента. Во первых — необходимо постоянно обновлять конфигурацию сервера. Во вторых, HTTP открыт всегда и везде, чего нельзя сказать о RTSP/RTP.
Лично я бы остановился на pseudo streaming. Он позволяет осуществлять перемотку и при этом не скачивать весь файл полностью. От нас требуется только немного донастроить web-сервер.