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

Kirill

Member
Хочу - кодировать поток в нужные для 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

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

Kirill

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

Max

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

Max

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

Kirill

Member
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

Administrator
Staff member
А можем транскодировать на стороне 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

Member
Если расшарить поток по 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 ?
 
Last edited:

Max

Administrator
Staff member
Только если вашим источником потока является 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

Member
Только если вашим источником потока является 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.
Планирую такую схему:
  1. IP Camera (h264 + aac)
  2. FFmpeg (transcoding to h264\G711 + chromakey)
  3. FFserver (pack to rtp (for webcallserver))
  4. WebCallServer (WebRTC)
FFMPEG и ffserver позволяют отправлять RTP поток по UDP .
Вот хотелось бы узнать , можно ли обойтись без п.3 , сейчас пытаюсь все вместе собрать, пока не получается ( с п.2 на п.3. отправить ).
Где-то ранее вы писали, что планируете заворачивать webrtc через HTTP.
- Да, все верно.
 

Kirill

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

Max

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

Kirill

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

Max

Administrator
Staff member
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

Member
Это проблема скорее не 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

Administrator
Staff member
Как отдать поток на ваш сервер из 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
иначе могут быть проблемы при воспроизведении.
 

Max

Administrator
Staff member
Что в поле stream писать на странице примера ?
Имя потока из RTMP адреса: rtmp://wcs5-eu.flashphoner.com/live/stream123
stream123
 
Top