I am publishing h264 / AAC via RTMP and Wirecast.
HLS is picking up audio ok. The WebRTC subscriber only gets video and no audio.
I have setup a transcoder with a h264 pass through and chosen opus audio codec. Still no audio in the video player. I tried a combination of VP9 and Opus / Vorbis also. If I choose Vorbis I get an error like
“DOMException: Failed to set remote offer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set remote audio description send parameters…”
As of now browser publishing is not working and neither is audio on the subscriber.
VP8 no good also transcoder provides no stream at all. VP9 produces artifacts. h264 is the only video codec working.
Not much information about transcoder requirements to even get WebRTC publishing working. This is the issue. there is a requirement for HLS fallback also.
Will try a test with ffmpeg somehow.
Lost my entire message because of dodgy captcha per message even when logged in.
Basically no audio with transcoder when using Opus codec. Audio is working with browser based publish.
wsConnection.onmessage: {“status”:200,“statusDescription”:“OK”,“direction”:“play”,“command”:“getOffer”,“streamInfo”:{“applicationName”:“webrtc/definst”,“streamName”:“myStream”,“sessionId”:“160095949”},“sdp”:{“type”:“offer”,“sdp”:“v=0\r\no=WowzaStreamingEngine-next 1535023177 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 F0:4E:97:C5:A5:CE:A6:64:F8:82:2F:49:D4:BD:0A:6D:BA:38:16:29:A0:CE:8F:22:56:B8:E7:D5:94:67:0B:16\r\na=group:BUNDLE video audio\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=video 9 RTP/SAVPF 97\r\na=rtpmap:97 VP8/90000\r\na=framesize:97 640-480\r\na=control:trackID=2\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=ice-pwd:372cde9a0e1d0bb77d40c45bf3a91279\r\na=ice-ufrag:64ebdbf4\r\na=mid:video\r\na=msid:{44ab936b-986e-477d-afa1-14472b590e79} {6c0605dc-fad0-4f44-84da-c0ed4b8fca57}\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtcp-fb:97 ccm fir\r\na=rtcp-mux\r\na=setup:actpass\r\na=ssrc:1380563329 cname:{300af5f8-8cd7-4baf-a4db-5f9bdf010e4f}\r\nm=audio 9 RTP/SAVPF 96\r\na=rtpmap:96 OPUS/48000/2\r\na=control:trackID=1\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=ice-pwd:372cde9a0e1d0bb77d40c45bf3a91279\r\na=ice-ufrag:64ebdbf4\r\na=mid:audio\r\na=msid:{44ab936b-986e-477d-afa1-14472b590e79} {1951490c-89b8-4f69-9a5d-821cd6f1a422}\r\na=rtcp-mux\r\na=setup:actpass\r\na=ssrc:1322356050 cname:{300af5f8-8cd7-4baf-a4db-5f9bdf010e4f}\r\n”}} webrtc.js:146 sdp: {“type”:“offer”,“sdp”:"v=0\r\no=WowzaStreamingEngine-next 1535023177 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 F0:4E:97:C5:A5:CE:A6:64:F8:82:2F:49:D4:BD:0A:6D:BA:38:16:29:A0:CE:8F:22:56:B8:E7:D5:94:67:0B:16\r\na=group:BUNDLE video audio\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=video 9 RTP/SAVPF 97\r\na=rtpmap:97 VP8/90000\r\na=framesize:97 640-480\r\na=control:trackID=2\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=ice-pwd:372cde9a0e1d0bb77d40c45bf3a91279\r\na=ice-ufrag:64ebdbf4\r\na=mid:video\r\na=msid:{44ab936b-986e-477d-afa1-14472b590e79} {6c0605dc-fad0-4f44-84da-c0ed4b8fca57}\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtcp-fb:97 ccm fir\r\na=rtcp-mux\r\na=setup:actpass\r\na=ssrc:1380563329 cname:{300af5f8-8cd7-4baf-a4db-5f9bdf010e4f}\r\nm=audio 9 RTP/SAVPF 96\r\na=rtpmap:96 OPUS/48000/2\r\na=control:trackID=1\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=ice-pwd:372cde9a0e1d0bb77d40c45bf3a91279\r\na=ice-ufrag:64ebdbf4\r\na=mid:audio\r\na=msid:{4
I am seeing this in the log
2017-08-1017:31:53AESTcommentserverERROR500-JNI:AudioEncoderOpus.initialize[defaultVHost:webrtc/definst/livestreamweb:webrtc_opus_audio]: Sample rate is not supported [8KHz, 12KHz, 16KHz, 24KHz, 48KHz]: 44100
I can’t seem to debug this properly. I attempted to use Mpeg Dash to test. It seems I am only able to get audio output with Opus if VP9 is selected as a codec. But the VP9 codec produces artifacts. VP8 produces no video in dash, strange.
“WARNservercomment2017-08-1018:14:32-----2797.977--------TranscoderWorkerVideoDecoder.handlePacket[defaultVHost:webrtc/definst/livestreamweb: decodeIterations:0]: Source stream frame rate is greater sourceStreamMaxFrameRate [80.0]. Using default source stream frame rate: 29.97 WARNservercomment2017-08-1018:17:31-----2977.114--------TranscoderWorkerVideoDecoder.handlePacket[defaultVHost:webrtc/definst/livestreamweb: decodeIterations:0]: Source stream frame rate is greater sourceStreamMaxFrameRate [80.0]. Using default source stream frame rate: 29.97 WARNservercomment2017-08-1018:17:33-----2979.058--------LiveStreamPacketizerPacketHandler.handlePacket[webrtc/definst/livestreamweb_rtc]: Audio and video codecs cannot be packetized together in a single stream: audio:OPUS video:H264”
I am now somehow able to get h264 passthrough and Opus codec working. I have no idea what I did , I think the publisher has to publish at 48k AAC.
Any solution for this issue?
The issue is with AAC. AAC is not supported for Web RTC playback and the transcoder can’t encode Opus or Vorbis audio beyond 48khz. If you set the AAC to 48khz or less, the transcoder should work. Note this is different than bitrate.
Thank you @Taylor Kerby, that is correct. WebRTC playback cannot use AAC.
But, when ingesting WebRTC streams that you want to deliver to many viewers, we recommend that you use the Transcoder feature in Wowza Streaming Engine to transcode the WebRTC stream into any standard output format, such as AAC audio with H.264 video.
Then you can deliver the stream over Apple HLS, Adobe HDS, or MPEG-DASH, which enables you to scale your WebRTC solution without the significant bandwidth that would otherwise be required to deliver your streams to viewers with satisfactory quality.
https://www.wowza.com/docs/webrtc-workflows-in-wowza-streaming-engine
Hello Daniel, Can you say me how did you solve this issue, please? I’m also using the WebRTC demo and I can’t capture the videos with sound. I would greatly appreciate your directions.
1 Like
Actually, I can’t capture the videos with sound too. There are a lot of people dealing with the same problem and those guys on Wowza keep telling us only to transcode the audio to AAC. My point is, no one gets back saying that this approach worked…