Не получается воспроизвести поток с ffmpeg в плеере на сервере WS

Kirill · Jun 28, 2017

Хочу - кодировать поток в нужные для webrtc кодеки ( VP8 , opus ). Наложить хромакей, отправить в flashphoner, получить поток в WebRTC.
Подготавливаю поток в ffmpeg и отправляю в WS вот таким образом.

Code:

./ffmpeg \
-i \
bg.jpg \
-thread_queue_size 512 \
-rtsp_transport tcp -i rtsp://ip_camera:port/main \
-codec:v libvpx -quality realtime -r 25 -crf 30 \
-b:v 2M -qmin 10 -qmax 50 -maxrate 2.5M -bufsize 5M \
-speed 1 \
-b:v 2M \
-cpu-used 0 -threads 4 \
-auto-alt-ref 0 \
-c:a libopus -b:a 96k \
-filter_complex "[1:v]chromakey=0x70de77:0.1:0.0[ckout];[0:v][ckout]overlay[out]" \
-map "[out]" \
-f webm rtmp://ip_server:1935/live/test1

В WS в разделе WebRTC as RTMP re-publishing в поле stream ввожу название своего потока - test1, вижу статус connect и картинку прелоад.... Потока не вижу.
В логах сервера вижу такие сообщения

Code:

G - RTMP-pool-3-thread-1 received not used message: [1 COMMAND_AMF0 c3 #0 t0 (0) s34] name: releaseStream, transactionId: 2, object: null, args: [test1]
G - RTMP-pool-3-thread-1 received not used message: [1 COMMAND_AMF0 c3 #0 t0 (0) s30] name: FCPublish, transactionId: 3, object: null, args: [test1]
G - RTMP-pool-3-thread-1 [0 COMMAND_AMF0 c4 #1 t0 (0) s35] name: publish, transactionId: 5, object: null, args: [test1, live]
G - RTMP-pool-3-thread-1 publish, stream name: test1, type: live
B - RTMP-pool-3-thread-1 Created ServerStream [name: 'test1 publisher: null subscribers: {}]
MediaHandler - RTMP-pool-3-thread-1 publishStream arguments - Stream{mediaSessionId='428166ad-7d58-4cc9-96dc-d46df61a203c'name='test1', status='NEW', sdp='v=0
G - RTMP-pool-3-thread-1 created publish stream: [name: 'test1 publisher: [id: 0x10e7ef32, /ip:56716 => /172.31.1.100:1935] subscribers: {}]
MediaHandler - WSS-pool-9-thread-4 playStream - Stream{mediaSessionId='ef21dfe0-5c16-11e7-b6f3-7bd25992ebdf'name='test1', status='PENDING', sdp='v=0
C - RTMP-pool-3-thread-1 unpublish name: test1
Streams - Thread-37 unpublish name: test1
C - Thread-37 unpublish name: test1

Собственно прошу помочь с отправкой потока из ffmpeg и воспроизведением потока в формате webrtc в WS .

Max · Jun 28, 2017

RTMP протокол не умеет / не расчитан из коробки нести VP8 и Opus.
Возможно такое и можно сделать с помощью ffmpeg, но это хак, который может потребовать адаптации под это сервера и реализации приема VP8 и Opus по RTMP.
Мы тестировали H.264 + AAC с ffmpeg.
Для совместимости с WebRTC, можете отправить поток H.264+G.711 (ulaw или alaw) с ffmpeg.
И удалить opus из серверных настроек codecs= в файле flashphoner.properties

Kirill · Jun 29, 2017

А если отправить поток по udp ?
т.е. поддержка VP8-VP9 - есть , а получить эти кодеки на сервере возможности нет или есть какие-то другие варианты ?

Max · Jun 29, 2017

Если расшарить поток по RTSP (VP8+Opus), то WCS сервер к нему сможет подключиться и забрать.
А принять поток на прямую может только по RTMP, RTMFP (H.264 + AAC | G.711 | Speex) или по WebRTC (H.264 | VP8 + Opus | G.711).
По хорошему, да. Нужно принимать еще напрямую через UDP или RTSP ANNOUNCE.
Посмотрим, можем ли мы быстро добавить такой способ трансляции.

Kirill · Jul 5, 2017

Я могу отправить с ffserver по http ( http://ip:port.webm ) , такой вариант тоже не скушает flashphoner ?

Max · Jul 5, 2017

Нет, такой стрим не примет.
Пока из нормальных вариантов видим только RTSP ANNOUNCE.
Реализация может занять несколько дней. Поэтому пока ждем окно, когда появится возможность это добавить.

Kirill · Jul 10, 2017

Max said:
RTMP протокол не умеет / не расчитан из коробки нести VP8 и Opus.
Возможно такое и можно сделать с помощью ffmpeg, но это хак, который может потребовать адаптации под это сервера и реализации приема VP8 и Opus по RTMP.
Мы тестировали H.264 + AAC с ffmpeg.
Для совместимости с WebRTC, можете отправить поток H.264+G.711 (ulaw или alaw) с ffmpeg.
И удалить opus из серверных настроек codecs= в файле flashphoner.properties

А можем транскодировать на стороне WebCallServer в нужные кодеки (VP8+Opus) , после отправки ffmpeg (H.264+G.711) ?

Как вы считаете, стоит ли вообще стремиться транскодировать стрим в современные кодеки VP8+Opus или оставить (H.264+G.711) ?

Max · Jul 10, 2017

А можем транскодировать на стороне WebCallServer в нужные кодеки (VP8+Opus) , после отправки ffmpeg (H.264+G.711) ?

Да, можете.
Точнее, транскодинг H.264 + G.711 > VP8 + Opus будет выполнен автоматически, если на сервере задан приоритет кодеков в настройке flashphoner.properties:

Code:

codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,h264,flv,mpv

Здесь Opus имеет приоритет над G.711.
VP8 имеет приоритет над H.264.
Поэтому, при попытке проиграть поток ffmpeg в Chrome с такими настройками сервера будет транскодинг.

Code:

Как вы считаете, стоит ли вообще стремиться транскодировать стрим в современные кодеки VP8+Opus или оставить (H.264+G.711) ?

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

в современные кодеки VP8+Opus или оставить (H.264+G.711) ?

Для WebRTC современный кодек - это H.264. Его внедрили последним, для совместимости с многими другими устройствами.
Поэтому, если есть возможность использовать H.264, лучше использовать его для трансляции и воспроизведения.
Для двухсторонних видеочатов и сжатия на стороне браузера сейчас лучше работает VP8. В Chrome он жмет с более стабильным битрейтом.

Kirill · Jul 13, 2017

Max said:
Если расшарить поток по RTSP (VP8+Opus), то WCS сервер к нему сможет подключиться и забрать.
А принять поток на прямую может только по RTMP, RTMFP (H.264 + AAC | G.711 | Speex) или по WebRTC (H.264 | VP8 + Opus | G.711).
По хорошему, да. Нужно принимать еще напрямую через UDP или RTSP ANNOUNCE.
Посмотрим, можем ли мы быстро добавить такой способ трансляции.

Как правильно отправить поток по udp (h264 + a-law) в webcallserver, чтобы потом можно было воспроизвести через webrtc ?

Max · Jul 13, 2017

Только если вашим источником потока является RTSP камера или сервер, поддерживающая отправку по UDP.
WCS подключится к ней по rtsp:// адресу и запросит UDP поток.
Камера / сервер вышлет UDP (RTP) H.264 + G.711.
По другому WCS не примет UDP.

Где-то ранее вы писали, что планируете заворачивать webrtc через HTTP.
Если так, то лучше использовать Media Source Extensions
С ffmpeg публикуете H.264 + AAC.
На MSE плеере играете H.264 + AAC.
WebRTC не требуется, весь видеотрафик идет через TCP/Websockets.
Демо пример есть здесь:
https://wcs5-eu.flashphoner.com/demo2/embed_player
Можно выставить приоритет для Media Source Extensions (MSE) над WebRTC

Kirill · Jul 13, 2017

Max said:
Только если вашим источником потока является RTSP камера или сервер, поддерживающая отправку по UDP.
WCS подключится к ней по rtsp:// адресу и запросит UDP поток.
Камера / сервер вышлет UDP (RTP) H.264 + G.711.
По другому WCS не примет UDP.

Где-то ранее вы писали, что планируете заворачивать webrtc через HTTP.
Если так, то лучше использовать Media Source Extensions
С ffmpeg публикуете H.264 + AAC.
На MSE плеере играете H.264 + AAC.
WebRTC не требуется, весь видеотрафик идет через TCP/Websockets.
Демо пример есть здесь:
https://wcs5-eu.flashphoner.com/demo2/embed_player
Можно выставить приоритет для Media Source Extensions (MSE) над WebRTC

MSE тестировал, на базе этого решения https://erlyvideo.ru/doc/play/mse-low-delay . Крайне проблемная вещь (недавно вышла из беты, видимо еще недоработана) ... В отличие от webrtc , тестировал через tcp на базе wowza , но wowza постоянно падала, тех. поддержка долго пыталась , но не смогла помочь.
В любом случае, нужен chroma key, так что нужен транскодинг.
Поэтому все же хочется webrtc.
Планирую такую схему:

IP Camera (h264 + aac)
FFmpeg (transcoding to h264\G711 + chromakey)
FFserver (pack to rtp (for webcallserver))
WebCallServer (WebRTC)

FFMPEG и ffserver позволяют отправлять RTP поток по UDP .
Вот хотелось бы узнать , можно ли обойтись без п.3 , сейчас пытаюсь все вместе собрать, пока не получается ( с п.2 на п.3. отправить ).

Max said:
Где-то ранее вы писали, что планируете заворачивать webrtc через HTTP.

- Да, все верно.

Kirill · Jul 17, 2017

Добрый день!
Возникла проблема при отправке(запаковка поток в rtp) потока с ffmpeg->ffserver->WS . Возможно вы сможете чем-нибудь помочь, проблема описана тут .

Max · Jul 17, 2017

Такую связку тестировать не приходилось.
Лучше исключить из не WCS и для начала добиться нормального воспроизведения, например на VLC плеере.

Kirill · Jul 17, 2017

Max said:
Такую связку тестировать не приходилось.
Лучше исключить из не WCS и для начала добиться нормального воспроизведения, например на VLC плеере.

Да, на текущий момент до WCS дело не дошло , ошибка на этапе запаковки потока в rtsp (передача на ffserver) .
Будем думу думать.
Благодарю за ответ.

Max · Jul 28, 2017

MSE тестировал, на базе этого решения. Крайне проблемная вещь.

Это проблема скорее не MSE, а проблема того конкретного решения, которое вы тестировали.
Попробуйте с последними версиями WCS, начиная с версии 2364.
https://wcs5-eu.flashphoner.com/client2/examples/demo/streaming/player/player.html?mediaProvider=MSE
Нам все же удалось добиться нормального воспроизведения в Media Source Extensions.
По крайней мере, тесты показывают вполне хорошие результаты.
Преимущества технологии:

Стриминг по Websockets или Secure Websockets на одном порту, можно 443.
Нативная поддержка кодеков H.264 и AAC (отсутствие транскодинга на стороне сервера)
Работает в браузерах: IE11(начиная с Windows 8), Edge, Safari Mac OS, Chrome, Firefox.

Т.е. формально подходит под ваши требования: стриминг по HTTP (Websocket), без транскодинга.
Стрим H.264+AAC можно публиковать с ffmpeg.

Kirill · Jul 28, 2017

Благодарю , попробуем.

Kirill · Jul 28, 2017

Max said:
Это проблема скорее не MSE, а проблема того конкретного решения, которое вы тестировали.
Попробуйте с последними версиями WCS, начиная с версии 2364.
https://wcs5-eu.flashphoner.com/client2/examples/demo/streaming/player/player.html?mediaProvider=MSE
Нам все же удалось добиться нормального воспроизведения в Media Source Extensions.
По крайней мере, тесты показывают вполне хорошие результаты.
Преимущества технологии:

Стриминг по Websockets или Secure Websockets на одном порту, можно 443.

Нативная поддержка кодеков H.264 и AAC (отсутствие транскодинга на стороне сервера)

Работает в браузерах: IE11(начиная с Windows 8), Edge, Safari Mac OS, Chrome, Firefox.

Т.е. формально подходит под ваши требования: стриминг по HTTP (Websocket), без транскодинга.
Стрим H.264+AAC можно публиковать с ffmpeg.

Нам еще нужно накладывать chroma key.
Как отдать поток на ваш сервер из ffmpeg - решения еще не нашли ( с ffserver проблема ).

Max · Jul 28, 2017

Как отдать поток на ваш сервер из ffmpeg

Публиковать из ffmpeg напрямую по RTMP:

Code:

ffmpeg -re -i /tmp/sample.mp4 -preset ultrafast -acodec aac -strict -2 -vcodec libx264 -f flv rtmp://wcs5-eu.flashphoner.com/live/stream

Далее играть в MSE
https://wcs5-eu.flashphoner.com/client2/examples/demo/streaming/player/player.html?mediaProvider=MSE
И там и там кодеки H.264+AAC
Есть известная проблема. Обязательно выставлять опцию -preset ultrafast
иначе могут быть проблемы при воспроизведении.

Kirill · Jul 28, 2017

Max said:
Публиковать из ffmpeg напрямую по RTMP:

Что в поле stream писать на странице примера ?

Max · Jul 28, 2017

Что в поле stream писать на странице примера ?

Имя потока из RTMP адреса: rtmp://wcs5-eu.flashphoner.com/live/stream123
stream123

Не получается воспроизвести поток с ffmpeg в плеере на сервере WS

Member

Administrator

Member

Administrator

Member

Administrator

Member

Administrator

Member

Administrator

Member

Member

Administrator

Member

Administrator

Member

Member

Administrator

Member

Administrator