video streaming

привет
нужен совет/консультация, по вопросу как лучше стриммить видео с камеры на клиент. я понимаю, что идеального подхода нет, но решение должно охватывать максимальное к-тво устройств(web+mobile)

поднят rtsp на сервере. вариант ли рестрим в rtmp для flash(web)?
или поднимать smooth streaming(+silverlight для веба, hls для iphone/ipad/safari)?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

лучше не пробовать, если кратко.

Ну, я тоже от нее был не в восторге. Но она работала, и делала что просили.

rtmp для flash
ацтой
HLS
більш-менш.
Поки що нема єдиновірного рішення

1) HLS — Flash/Android 4+/iPhone/iPad/iMac
2) rtsp — Android 4-

Из софта — vlc/ffmpeg/flussonic/erlyvideo/nginx-rtmp на выбор. Можно комбинировать по вкусу.

Мы gstreamer’ом прямо в mpeg2ts или h.264 снимаем с вебкамер и передаём видео с объектов.

Можете заранее приготовить тапки.
Например надо раздать скринкаст клиентам (с камерой похожая ситуация),
ffmpeg умеет это делать так:
ffmpeg -f x11grab -r 5 -s 1280x1024 -i :0.0 -q:v 0 -vcodec mpeg4 -r 5 -f mpegts udp://192.168.0.181:1234
(То же можно делать с помощью ffmpeg api)
Сервер поднимается, и каждый новый входящий клиент сообщает ему ip и порт, на который
он готов принимать видео, сервер запускает поток видео на этот адрес и порт,
порядочный клиент сообщает о том что он уходит, или время от времени сообщает
о своем присутствии, на основе этой информации сервер решает прекратить ли рассылку

поднят rtsp на сервере. вариант ли рестрим в rtmp для flash(web)?
Вариант. Можно так делать: ffmpeg перегоняет из rtsp в rtmp (с ключом -vcodec copy это будет не слишком напряжно для сервера; но это если с камеры идет H.264; звук, скорее всего, придется транскодить, потому что rtmp поддерживает только определенные частоты дискретизации); а nginx-mod-rtmp раздает клиентам rtmp-поток.

Еще можно посмотреть в сторону «прогрессивных» технологий — HLS (Apple HTTP Live Streaming; уже советовали), MPEG-DASH,... (что не требует флэша у клиента). См., например habrahabr.ru/post/204666

Еще лучше — p2p, чтобы не нагружать сервер, тут надо смотреть в сторону WebRTC (habrahabr.ru/...ix/blog/206200 ).

за линк на хабр о MPEG-DASH — жирная благодарочка

про него можете забыть пока, поддерживается только в Хроме на данный день и то, недавно. Сыро еще. HLS в приоритете до сих пор.

Для яблокодевайсов бы сильно посоветовал раздавать по HTTP Live Streaming в h.264. Т.к. оно сейчас самое стандартное и потенциально принимается всем что шевелится.
developer.apple.com/streaming

С другими протоколами немеряно нюансов.

если я правильно разобрался, то это для peer-2-peer
да?

да, peer-2-peer, а... вам же в одну сторону надо, может можно настроить и его, но просто стрим это rtmp->erlyvideo->flash(web), тот же erlyvideo в модификации hls flussonic, был foss раньше. rtmp на ios был запрещен, может уже разбанили. есть еще видео-библиотеки на основе ffmpeg для ios, где rtmp играть можно.

rtmp на IOS не то, чтобы запрещено, но не поддерживается стандартными плеерами и API. Т.е. придется объяснять пользователям, что им нужно будет скачать, скажем, VLC. А он небезглючен. Либо писать своего клиента, что деньги и время.
За приличного клиента для mms/mmsc на елансе давали трешку навскидку. И это без дизайна и исходников — чисто базовый интерфейс и либа в бинарном виде с описанием.

вот нашел:
www.binpress.com/...dk-for-ios/1322 — 300$
времени столько же, сколько opentok подключать. конечно если ничего не будет глючить, им надо было здорово пофиксить ffmpeg, наверно за что и назначили цену
тут из задачи исходить надо, может hls подойдет лучше, а может rtmp

Как вариант. Я не крутил конкретно эту либу, т.к. не дают демку.

Другие были шлаком по большому счету — ffmpeg старый (даже не 2.0) с отключенной оптимизацией под neon, плеер играет «как успел декодировать» и рвет и аудио и видео, о синхроне a/v можно и не вспоминать.

В rtmp хреново то, что его нельзя скормить хардварному декодеру, даже если там православный h.264 main profile или mpeg4 т.к. эпл с библиотекой перемудрил. Т.е. что-то с разрешением ближе к HD уже с большим скрипом пойдет (если вообще пойдет) на ipad 2 (а их дохрена еще реально) и iphone4 и ниже.

А у бродкастеров одним из основных требований была тру синхронизация аудио/видео на разных потоках, что не очень тривиально по причине рассинхрона еще на энкодере камеры (не успевает видео кодировать вовремя, однако таймстампы все же правильные ставит).
Ну Вам проще, т.к. есть возможность подстроить поток и хар-ки контента.

Підписатись на коментарі