Android stream to device

How to Connect Your Android Phone to Your TV

You can stream your Android phone or tablet screen to a TV through screen mirroring, Google Cast, a third-party app, or linking it with a cable.

There are times when you’re watching something on your phone and you want to share it with the room or just see it on a bigger display. Those with Android devices have a few options, including built-in features, third-party apps, and cable hookups. Let’s break down your choices, from the simplest solution to the most complex.

Cast With Chromecast

If you have a Chromecast dongle or a smart TV with built-in Chromecast support, your best bet is to see if the app you want to watch on TV supports casting. If so, you can send content from your phone to the TV with a few taps.

Supported apps include Netflix, Hulu, HBO Now, and Google Photos, though many of them already live on your Android TV or Chromecast with Google TV.

Make sure your device is on the same Wi-Fi network as your Chromecast or smart TV and tap the square cast icon in the app. Choose the compatible device to which you’d like to cast. Casting is the ideal option for apps with copyrighted content, since apps like Netflix will black out the video if you try screen mirroring.

Chromecast With Google TV Review

Android Screen Mirroring

Screen mirroring is best for apps that don’t contain protected content or officially support casting. You will still need a Chromecast or compatible smart TV in order to use this feature, which can then be connected to the Google Home app.

Once the target device is added to your Google Home, Open the app and tap the plus (+) icon in the top-left corner to add a device, if needed. Otherwise, tap the device to which you want to cast and tap Cast my screen at the bottom to place your phone screen on the TV. When you’re done, tap Stop mirroring in the app.

Some Fire TV and Roku streaming devices also support with screen mirroring, though check with Amazon and Roku, respectively, to ensure compatibility for your specific devices.

Support for screen mirroring has varied by manufacturer since the feature was introduced with Android version 5.0 Lollipop. Many phones have a Cast button built into the phone’s settings or in the pulldown settings shade. Samsung’s phones have something called Smart View to connect and share to and from your mobile device.

Connect With an Adapter or Cable

If you don’t have a Chromecast-compatible device, use an HDMI cable and adapter to connect your phone to your TV and mirror what’s on your screen. You have a few different options here, and which one you choose will depend on the type of display you’re connecting to, how long, and—most importantly—whether or not you’ll need to charge your phone while doing it.

The simplest option is a USB-C to HDMI adapter. If your phone has a USB-C port, you can plug this adapter into your phone, and then plug an HDMI cable into the adapter to connect to the TV. Your phone will need to support HDMI Alt Mode, which allows mobile devices to output video. This method will take up your charging port, unless your adapter has a charging port.

If you have an older Micro USB-style port, you will need a micro USB to HDMI adapter. With this method, your phone will need to support a different protocol called MHL. If you have a supported phone, hook it up to the adapter, then attach an HDMI cable and connect it to a TV.

Stream With DLNA

If the previous options don’t work for you, most internet-connected TVs support a streaming protocol called DLNA, which will let you stream your own music and videos to your TV. Be warned, though, that Netflix (and any DRM content) won’t be supported here. Fortunately, this still covers most things you might want to send from your phone to your TV.

LocalCast is a simple and free app that lets you stream your own music, photos, or videos to a DLNA device like a smart TV or console. It also supports streaming to Chromecast targets, which is handy if you want to share your own files on a TV without mirroring your entire screen. The app even allows you to stream from Google Drive, Dropbox, and web pages. AllCast is similar to LocalCast, but you must upgrade to the premium version to remove ads.

The popular media management app Plex also works as a DLNA streamer, though in a less direct way. A Plex server running on your computer can host music, photos, or videos, and stream them to your TV. You can use the mobile app to browse your library, pick which media to stream, and send it to the television via Chromecast or DLNA.

The downside to using the Plex app is that the computer where you set up your server will need to be on and connected to the internet any time you want to stream your files. However, Plex does allow you to host media files far larger than the ones that would fit on your phone.

Like What You’re Reading?

Sign up for Race to 5G newsletter to get our top mobile tech stories delivered right to your inbox.

This newsletter may contain advertising, deals, or affiliate links. Subscribing to a newsletter indicates your consent to our Terms of Use and Privacy Policy. You may unsubscribe from the newsletters at any time.

Your subscription has been confirmed. Keep an eye on your inbox!

Источник

Стрим видео с Android устройства по UDP в JAVA приложение

Итак, выходим на финишную прямую. Стримить видео с андроида на VLC плеер мы уже научились, теперь осталось только интегрировать окошко с видео в JAVA приложение и начать рулить роботелегой.

В этом нам очень сильно поможет проект с открытым исходным кодом VLCJ CAPRICA.

The vlcj project provides a Java framework to allow an instance of a native VLC media player to be embedded in a Java application.

Идея у ребят простая, но гениальная (реально перцовая). Вместо мучений с библиотеками FFmpeg и прочим, надо сразу вызывать специалиста ядро нормального, функционального и профессионального медиаплеера VLC. И вызвать его прямо из JAVA приложения.

Кому интересно, просим под кат.

Поскольку, в этом вояже хватает подводных камней, то начнём, как водится, с очень простого и лишь затем перейдём к тривиальному.

Инсталляция пакета VLCJ

Первым делом проверьте установленную у вас версию медиапроигрывателя VLC. Свежая версия нам не нужна, там выпилено то, что требуется для udp стрима. Об этом уже говорилось в предыдущем посту. Поэтому качаем версию 2.2.6 Umbrella и заодно тщательно проверяем свой JAVA пакет. Они должны совпадать по разрядности. Если плеер использует 64-разрядную архитектуру, то и JDK обязан быть таким же. А то не взлетит.

После этого уже можно скачать сам пакет библиотек VLCJ

Обратите внимание, что нам нужен пакет vlcj-3.12.1 distribution (zip). Именно он работает с плеерами версий VLC 2.2.x. Разархивировать его можно куда угодно, главное, что не в папку самого VLC, ибо там по именам совпадают два файла. И если вы их перезапишите, кончится всё это полным провалом.

Далее, создаем проект в IDE IntelliJ IDEA (если у вас другое IDE, то ничем помочь не могу) и прописываем необходимые зависимости для интеграции библиотек VLCJ.

Делаем именно так для файлов:

Затем создаем единственный класс и пишем в нём следующую малюсенькую программку.

Да, пока мы пытаемся проигрывать просто файл (как видно из кода). С udp лучше не начинать — не заработает. А файл проигрывается вполне, если вы, конечно, не забыли его с соответствующим именем разместить заранее там, где надо. Думаю, что даже для самого начинающего джависта не составит труда разобраться в вышеприведенном коде.

и создание самого инстанса медиаплеера

А потом мы просто его добавляем в нужную графическую панель:

И всё, файл будет проигрываться именно в этом окошке.

А теперь попробуйте заменить

как мы спокойно делали в прошлом посте для стриминга видео через udp соединение.
Здесь такой номер не пройдёт. Окошко, конечно откроется, но покажет фигу, в смысле темный экран. Хотя никаких логов с ошибкой не будет. Просто не будет ничего.

Надо разобраться

Может быть не хватает кодека H264, который мы выбрали в настройках? Стоп, а как тогда только что проигрывался файл ttt.mp4? Он же не может проигрываться при такой настройке, он же — mp4.

Немедленно приходит понимание того, что библиотека VLCJ запускает только само ядро плеера. А какие там были предварительные настройки она не знает и знать не хочет. То есть, нам надо каким-то образом при запуске JAVA приложения, как-то передать VLC плееру, что мы хотим явно использовать кодек H264 или, допустим, хотим повернуть изображение или что-то ещё.

Оказывается, сделать это можно, используя класс MediaPlayerFactory. Только мы его запускали без аргументов, а можно даже с ними. На stackoverflow.com я тут же нашел простой пример, связанный с поворачиванием изображения:

То есть, чего-то там передаем строчным массивом в медиафабрику и оно там сохраняется для используемого медиаресурса.

Я попробовал этот способ для проигрывания файла и как водится, ничего не заработало. Оказывается, забыли две черточки добавить и разнесли по всему интернету. Пришлось догадываться, используя похожий метод transform.

Короче говоря, должно быть:

Теперь наш эталонный файл перекривило как надо!

Дальше будет уже совсем просто:

Для определения кодека, согласно командной строке VLC мы добавляем в строковый массив строку:

Снова пробуем udp канал

И в этот раз всё работает, обозначая победу человеческого разума. Теперь это окошко с видео или несколько таких окошек вы сможете беспрепятственно портировать в графический интерфейс вашего JAVA приложения.

Казалось бы победа?

Не совсем. Легкое недоумение у меня вызвали временные задержки или по научному, лаги. Сначала они более менее приёмлимые, но если у вас хватит терпения просмотреть видео до конца, то вы увидите, что лаг к концу первой минуты трансляции достигает аж пяти секунд. У меня терпения хватило на 10 минут съемки, но, как ни странно, задержка больше не увеличивалась, а так и осталась в тех же пределах.

Конечно, для просмотра видео с камеры такое сгодится, но для управления роботележкой едва ли. Даже луноход реагировал быстрее в два раза!

Подозрения сразу пали на процессы кэширования и они (подозрения )оказались верными.

Самым наглым оказался:

Он как раз и отжирает по умолчанию практически всё, если ему вовремя не дать по рукам.
Может устроить лаг и:

Поэтому во избежание многосекундных задержек рекомендуется добавить во всё тот же строковый массив через запятую следующие строчки:

Параметры там задаются в миллисекундах и поэтому каждый желающий может подобрать их под себя.

Ещё можно использовать ключ:

Тогда медиаплеер будет стараться оптимизировать джитер — подергивание экрана. Но там, чем больше установлено время, тем лучше оптимизируется и это понятно почему. Так что здесь остается лишь искать консенсус и видеть иногда в логах такое безобразие:

Вот хотел он, понимаешь, джиттер исправить, а ты временной промежуток слишком маленький поставил. Теперь сам виноват.

Теперь вроде бы все как надо. Задержку удалось сократить меньше, чем до одной секунды (правда, чуть-чуть меньше).

В итоге, получился совсем крохотный рабочий код

Теперь можно интегрировать видео трансляцию в мою программулину по управлению роботележкой, где раньше я передавал видео по кускам. И надо сказать код весьма упростился, а качество на порядок улучшилось. Плюс ко всему к видео потоку мы можем передать показания

акселерометров
гироскопов
уровня освещения
давления воздуха
показаний компаса
температуры
и даже влажности

При условии, конечно, что все эти сенсоры у вашего смартфона имеются.

И даже включить фару! Автоматически! Если уровень освещения упадёт.

Вряд ли кому особо интересно, но на случай ссылки на гитхаб:

Источник

Android Camera2 API от чайника, часть 3. Media Codec и стрим видео по UDP

Итак, со съемками фоточек и записью видео при помощи Camera2 API мы вроде бы, разобрались. Осталось только научиться передавать видеопоток c Android устройства страждущим получателям извне. Конечной целью, как уже неоднократно ранее говорилось, является интеллектуализация роботелеги — ставим на неё смартфон и так сказать, превращаем обезьяну в человека. В этом нам поможет Media Codec. И конечно, новое Camera2 API.

Кому интересно, прошу под кат.

Детали о проекте с роботележкой можно найти здесь, а мы пока займемся непосредственно стримингом видео с неё (вернее с прицепленного к ней Android смартфона) на персональную электронно-вычислительную машину.

Что нам для этого нужно?

Для того чтобы передать видео поток с экрана смартфона куда-либо ещё, как известно, его (поток) сначала необходимо преобразовать в подходящий ужатый формат (передавать покадрово выйдет слишком толсто), поставить time-stamps (временные метки) и отправить в бинарном виде получателю. Который произведёт обратную операцию декодирования.

Как раз этими низкоуровневыми чёрными делами и занимается класс Media Codec с 2013 года, с даты выхода Аndroid 4.3.

Другое дело, что раньше подступиться к кодированию видео, в отличие от сегодняшнего дня было не так-то просто. Чтобы вытащить картинку с камеры надо было использовать тонны загадочного кода в котором, как в заклинаниях якутских шаманов, единственная неточность могла привести к полному краху приложения. Добавьте к этому ещё предыдущее Camera API, где вместо готовых коллбэков приходилось ручками самостоятельно писать разные synchronized, а это занятие, скажем так, не для слабых духом.

И главное, издалека смотришь на рабочий код, вроде бы в общих чертах всё ясно. Начинаешь переносить по частям в свой проект — сыпется непонятно почему. А скорректировать не получается, потому что в деталях уже разобраться тяжело.

Да и от сплошных deprecated как-то не по себе. Короче говоря, непорядок

К счастью, для непонятливых гуглостроители ввели волшебную концепцию поверхности Surface, работая с которой, можно избежать низкоуровневых деталей. Какой ценой и что при этом теряет разработчик, мне как неспециалисту понять сложно, но зато теперь мы чуть ли не буквально можем сказать: «Android, возьми эту Surface на которую отображается видео с камеры и ничего там не меняя, ну вот как есть, закодируй и отправь дальше». И самое удивительное, что это работает. А с новым Camera2 API программа и сама знает, когда данные отправлять, коллбэки ж новые появились!

Так что теперь закодировать видео — раз плюнуть. Чем мы сейчас и займёмся.
Берём код из первой статьи и как обычно выкидываем из него всё кроме кнопочек и инициализации камеры.

И закончим прицеплением Media Codec

В прошлом посте мы выводили на Surface изображение с камеры и с него же писали видео при помощи MediaRecorder. Для этого мы просто указывали оба компонента в списке Surface.

Здесь то же самое, только вместо mMediaRecorder указываем:

Получается, что-то типа:

Что такое mEncoderSurface? А это та самая Surface, с которой будет работать Media Codec. Только для начала надо их обоих инициализировать примерно таким образом.

Теперь остается прописать единственный коллбэк. Когда Media Codec вдруг ощутит, что очередные данные для дальнейшей трансляции готовы, он нас об этом известит именно через него:

Байтовый массив outDate — это настоящее сокровище. В нём уже готовые кусочки закодированного в формате H264 видеопотока, с которым мы теперь можем делать всё, что захотим.

Некоторые кусочки может быть великоваты для передачи по сети, ну да ничего, система, если надо их порубит ещё сама и отправит дальше получателю.
Но если сильно страшно, то покромсать можно самому, впихнув такой фрагмент

Но нам пока надо убедиться воочию, что данные в буфере это действительно видеопоток в формате H264. Поэтому, давайте мы их отправим в файл:

Пропишем в сетапе:

А в коллбэке где буфер:

Открываем приложение, жмем кнопку: «ВКЛЮЧИТЬ КАМЕРУ И СТРИМ». Начинается автоматически запись. Ждем немного и давим кнопку остановки.

Сохраненный файл штатно скорее всего не проиграется, поскольку формат не MP4, но если открыть его VLC плеером или сконвертить онлайн каким нибудь ONLINE CONVERT, то мы убедимся, что находимся на правильном пути. Правда изображение лежит на боку, но это поправимо.

Вообще, для каждого события записи, фотографирования или стрима, лучше, конечно, открывать каждый раз новую сессию, а старую закрывать. То есть, сначала мы включаем камеру и запускаем голое превью. Потом, если надо сделать снимок, превью закрываем и открываем превью, но уже с пристегнутым Image Reader. Если переходим на запись видео, то закрываем текущую сессию и запускаем сессию с превью и прицепленным к нему Media Recorder. Я этого не делал, чтобы не страдала наглядность кода, а вам решать, как удобнее самим.

А вот и сам код целиком.

И не забудьте про разрешения в манифесте.

Итак, мы убедились, что Media Codec работает. Но использовать его для записи видео в файл как-то бездуховно. С такой задачей гораздо лучше справится Media Recorder, да ещё и звук добавит. Поэтому файловую часть мы снова выкинем и добавим блок кода для стриминга видео в сеть по udp протоколу. Это тоже очень просто.

Сначала инициализируем UDP практически сервер.

А в том же коллбэке, где мы отправляли данные по готовности в поток для файла, отправим их теперь в виде дэйтаграмм в нашу домашнюю сеть (надеюсь она есть у всех?)

Казалось бы, но нет. Приложение при запуске скрашится. Видите-ли, системе не нравится, что в главном потоке мы отправляем всякие дэйтаграмм пакеты. Но для паники нет оснований. Во-первых мы хоть и в главном потоке, но работаем все равно асинхронно, то есть по срабатыванию коллбэка. Во-вторых отправка udp пакетов, такой же асинхронный процесс. Мы только говорим операционной системе, что неплохо было бы отправить пакетик, но, что мы всецело в этом деле полагаемся на неё. Поэтому, чтобы Android не бунтовал, то в начале программы добавим две строчки:

В общем и целом, получится следующая маленькая элегантная демонстрационная программка:

Не знаю, как у других, но на моем Red Note 7 даже видно, как скачут килобайты по нужному адресу

И таких udp сокетов можно наплодить множество, на сколько хватит пропускной способности сети. Главное, чтобы были адреса куда. Будет у вас широкоадресная рассылка.

Теперь пойдём искать нужный адрес на компьютере

Надо сказать, что не каждая компьютерная программа способна всосать и переварить видео поток формата H264 по единственному udp каналу без какой-либо дополнительной информации. Но некоторые могут. Это например крайне широко известный медиаплеер VLC. Это настолько крутая штука, что если начать описывать её возможности, то из статьи получится целая книга. Наверняка у вас она есть. Если нет, поставьте.

И судя по описанию команд для него, udp пакеты переварить этот плеер может.

Причём все эти source address и bind address, по идее и не нужны. Нужен только прослушиваемый порт.

И ещё, конечно, нужно не забыть про разрешение этот порт слушать (малварь же)

А вы знали, что Винда не дает сделать принтскрин с монитора ресурсов?

Или можно вообще брандмауэр отключить (не рекомендую)

Итак, преодолев эти тернии, запускаем VLC плеер с нашим адресом и наслаждаемся пустым экраном. Видео нет.

Как же так?

А вот так. У вас, наверно, стоит последняя версия VLC 3.08 Vetinari? Вот как раз, в этой версии udp объявлен deprecated и мало того выпилен нахрен.

Так-то логика разработчиков плеера понятна. Мало кому нужно использовать голый udp канал в наше время потому-что:

• Нормально работает только в домашней неперегруженной сети. Стоит вам выйти во внешний мир и ненумерованные дэйтаграммы начнут теряться и приходить не в том порядке, в котором их послали. А для видео декодера это очень неприятно.
• Незашифрован и легко компрометируется

Поэтому нормальные люди, конечно, используют протоколы более высокого уровня RTP и другие. То есть на пальцах — вы пишете сервер, который всё равно на низком уровне использует udp (для скорости), но параллельно обменивается управляющей информацией с клиентом кому он стримит видео. Какая там у него пропускная способность, не надо ли увеличить-уменьшить кэш для данных, какая детализация изображения оптимальна сейчас и так далее и тому подобное. Опять же звук тоже иногда нужен. А ему требуется, сами понимаете, синхронизация с видео.

Вон ребятам из Одноклассников даже пришлось свой протокол запилить для стриминга. Но у них задачи-то, конечно, гораздо более важные — рассылать видео с котиками десяткам миллионов домохозяек по всему миру. Там одним udp каналом не обойдёшься.
Но нам-то писать свой RTP сервер на андроиде как-то грустно. Наверное, можно найти даже готовый и даже бесплатный, но попробуем пока не усложнять сущностей. Просто возьмем версию VLC плеера, где udp стриминг ещё работал.

Устанавливаем вместо или рядом со старым (то есть новым VLC), как вам заблагорассудится.

Запускаем и снова видим пустой экран.

А все это потому, что мы явно не настроили использование кодека H264. Так-то VLC смог бы выбрать кодек автоматически, если бы имел дело с файлом (в настройках изначально, как раз и указан автоматический выбор). Но ему-то кидают байтовый поток по единственному каналу, а кодеков, которые VLC поддерживает десятки. Как ему разобраться, какой применить?

Поэтому устанавливаем кодек силой.

И вот теперь наслаждаемся трансляцией «живого» видео. Единственное, оно зачем-то лежит на боку, но это уже легко поправить в настройках видеоплеера.

А ещё можно просто запускать плеер из командной строки по такому ключу:

Источник