Comments 15
Картинки немножечко мертвы.
можете перелить картинки на https://habrastorage.org/?
Спасибо за статью, по мне — качественный подход!
WebRTC в Chrome не поддерживает кодек H.264 на мобильных устройствах, там используется кодек VP8.
Chrome для Android поддерживает программное кодирование в H.264 для WebRTC, начиная с версии 52 — https://www.chromestatus.com/features/6417796455989248.
Аппаратное кодирование в H.264 для WebRTC в Chrome для Android включается с помощью флага chrome://flags/#enable-webrtc-hw-h264-encoding.
Спасибо за флаг. Не знал про него. Будем надеяться, что включат из-коробки в следующих версиях Chrome.
Так уже. :) Если аппаратное кодирование доступно, то используется аппаратное, иначе – программное.
Думаю, пункт
WebRTC в Chrome не поддерживает кодек H.264 на мобильных устройствах
нужно удалить из статьи, так как
- это не так. :)
- из текущей формулировки не понятно, идёт речь о поддержке кодирования или декодирования.
это не так. :)
На самом деле это так. Если вы пройдете дальше по ссылке на багтрекер, то увидите сообщение от 2 февраля 2017.
It seems there is still no H.264 support in WebRTC on Android. Is there any resource where I can find more about a timeline when this will happen?
Вот у меня тот же самый вопрос. Когда я тестирую в Google Chrome 55 под Android, я вижу следующее SDP, в котором нет H.264 кодека. Очевидно, что если второй Chrome ответит с таким же SDP, никакого H.264 между ними не будет. Твикать не пытался.
SDP
o=- 9063232133596571010 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:qmdk
a=ice-pwd:ad9UlErZKSOq/2AB+IkLgkxe
a=fingerprint:sha-256 1E:C8:60:92:B4:08:AD:F8:A9:37:F3:AB:B5:BE:E5:EA:F2:58:7F:5D:92:18:FD:45:59:B8:15:2F:60:6F:9C:CC
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=ssrc:1952196695 cname:LaqE6Dv+aYG4IrKv
a=ssrc:1952196695 msid:XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a b6a5ead2-f257-4d84-b1cd-ea7a0fa4cd76
a=ssrc:1952196695 mslabel:XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a
a=ssrc:1952196695 label:b6a5ead2-f257-4d84-b1cd-ea7a0fa4cd76
m=video 9 UDP/TLS/RTP/SAVPF 100 101 116 117 96 97 98
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:qmdk
a=ice-pwd:ad9UlErZKSOq/2AB+IkLgkxe
a=fingerprint:sha-256 1E:C8:60:92:B4:08:AD:F8:A9:37:F3:AB:B5:BE:E5:EA:F2:58:7F:5D:92:18:FD:45:59:B8:15:2F:60:6F:9C:CC
a=setup:actpass
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=sendonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtpmap:101 VP9/90000
a=rtcp-fb:101 ccm fir
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=rtcp-fb:101 transport-cc
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=101
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=116
a=ssrc-group:FID 4154262720 1317438163
a=ssrc:4154262720 cname:LaqE6Dv+aYG4IrKv
a=ssrc:4154262720 msid:XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a 83568038-95c9-486b-ad09-d39ba4cac12f
a=ssrc:4154262720 mslabel:XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a
a=ssrc:4154262720 label:83568038-95c9-486b-ad09-d39ba4cac12f
a=ssrc:1317438163 cname:LaqE6Dv+aYG4IrKv
a=ssrc:1317438163 msid:XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a 83568038-95c9-486b-ad09-d39ba4cac12f
a=ssrc:1317438163 mslabel:XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a
a=ssrc:1317438163 label:83568038-95c9-486b-ad09-d39ba4cac12f
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:qmdk
a=ice-pwd:ad9UlErZKSOq/2AB+IkLgkxe
a=fingerprint:sha-256 1E:C8:60:92:B4:08:AD:F8:A9:37:F3:AB:B5:BE:E5:EA:F2:58:7F:5D:92:18:FD:45:59:B8:15:2F:60:6F:9C:CC
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=ssrc:1952196695 cname:LaqE6Dv+aYG4IrKv
a=ssrc:1952196695 msid:XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a b6a5ead2-f257-4d84-b1cd-ea7a0fa4cd76
a=ssrc:1952196695 mslabel:XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a
a=ssrc:1952196695 label:b6a5ead2-f257-4d84-b1cd-ea7a0fa4cd76
m=video 9 UDP/TLS/RTP/SAVPF 100 101 116 117 96 97 98
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:qmdk
a=ice-pwd:ad9UlErZKSOq/2AB+IkLgkxe
a=fingerprint:sha-256 1E:C8:60:92:B4:08:AD:F8:A9:37:F3:AB:B5:BE:E5:EA:F2:58:7F:5D:92:18:FD:45:59:B8:15:2F:60:6F:9C:CC
a=setup:actpass
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=sendonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtpmap:101 VP9/90000
a=rtcp-fb:101 ccm fir
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=rtcp-fb:101 transport-cc
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=101
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=116
a=ssrc-group:FID 4154262720 1317438163
a=ssrc:4154262720 cname:LaqE6Dv+aYG4IrKv
a=ssrc:4154262720 msid:XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a 83568038-95c9-486b-ad09-d39ba4cac12f
a=ssrc:4154262720 mslabel:XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a
a=ssrc:4154262720 label:83568038-95c9-486b-ad09-d39ba4cac12f
a=ssrc:1317438163 cname:LaqE6Dv+aYG4IrKv
a=ssrc:1317438163 msid:XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a 83568038-95c9-486b-ad09-d39ba4cac12f
a=ssrc:1317438163 mslabel:XHcMIPInydl69XrCnuDdwVomvPfeDsOnLK4a
a=ssrc:1317438163 label:83568038-95c9-486b-ad09-d39ba4cac12f
Поэтому, возможно они это заимплементили, но это не работает, по крайней мере для нескольких устройств с которыми я проводил тесты.
нужно удалить из статьи
Пожалуй, удалю кода заработает из коробки без доп.флагов в Google Chrome, хотябы на моих планшете и телефоне (Android 4.2.2, Android 5.1.1).
из текущей формулировки не понятно, идёт речь о поддержке кодирования или декодирования.
В контексте статьи это кодирование. Перечитаю. Если действительно неточно — поправлю. Но как я показывал выше на SDP, декодинг тоже из него не проглядывается.
Open Broadcaster и ffmpeg стоило упомянуть. Условно бесплатный vMix еще есть. Бесплатные мультиплатформенные и прекрасно умеют rtmp. Правда насчет WebRTC не уверен.
Да, ffmpeg хотел упомянуть. Но сборка его из исходников затянулась неприлично долго.
Не так давно только собрал ffmpeg с поддержкой:
— libx264
— librtmp
Должно хватить для кодирования.
Не так давно только собрал ffmpeg с поддержкой:
— libx264
— librtmp
Должно хватить для кодирования.
Не обязательно собирать самому. ) На официальном сайте есть ссылки на сторонние ресурсы, с которых можно загрузить скомпилированный FFMPEG для различных платформ.
А почему был выбран RTMP?
Судя по документации, YouTube Live Streaming API поддерживает также DASH, который помимо кодеков H.264 и AAC в контейнере ISO BMFF также поддерживает кодеки VP8/VP9 и Vorbis/Opus в контейнере WebM.
Т.е. используя DASH, на сервере-посреднике можно не перекодировать видео и аудио из одного кодека в другой, а лишь разбивать их на сегменты, что требует значительно меньших ресурсов.
Спасибо за статью.
По логике вещей youtube должен сделать прием live по webrtc. Это было бы логичным продолжением политики google.
По логике вещей youtube должен сделать прием live по webrtc. Это было бы логичным продолжением политики google.
Статей по WebRTC мало и этой как раз не хватало, спасибо!
Но, подскажите, есть ли open-source альтернативы flashphoner'у в данном случае, которые работают с WebRTC?
Но, подскажите, есть ли open-source альтернативы flashphoner'у в данном случае, которые работают с WebRTC?
Sign up to leave a comment.
Трансляция WebRTC-видеопотока из браузера на YouTube Live в 65 строк JavaScript/HTML-кода