VP8 Codec not working with WebRTC - uses wrong container

Wowza Streaming Engine
1

I’m not having any luck getting the VP8 codec to work with WebRTC, I can replicate the problem with the Wowza WebRTC test client by simply selecting VP8 as the codec. The recording will start up without any errors (including in the browser console), but the end result is an MP4 file with just the audio and no video. I thought that VP8 needed a Webm container, not MP4, so I suspect the issue here is that the wrong container format is being used to save the incoming stream. However, I can find nothing that allows me to configure the container used for the codec, so my asusmption is that the wrong choice is being made at some point.

H264 is working with the same WebRTC set up, but I’m having issues with stream corruption in Firefox if there is a resolution change (something WebRCT seems to do every time in the first 30 seconds), so I want to see if VP8 handles this better.

I see the following in the browser console, which seems to confirm that I’m sending VP8:

v=0
o=mozilla…THIS_IS_SDPARTA-99.0 5187521585237493399 0 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 A4:30:44:7F:1B:42:C9:E1:31:16:B6:CA:6B:D9:1C:49:DD:75:F5:8F:1E:1E:2A:D6:E9:39:0F:A0:5E:F1:EB:8A
a=group:BUNDLE 0 1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 0.0.0.0
b=TIAS:44800
b=AS:64000
b=CT:64000
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=ice-pwd:d3c8c3fc75524e350f772dd6a2e18720
a=ice-ufrag:094b1949
a=mid:0
a=msid:- {0d50371e-79b8-49de-91d0-71fc76ebe0b3}
a=rtcp-mux
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=rtpmap:109 opus/48000/2
a=setup:actpass
a=ssrc:3894789548 cname:{3b9cbe3c-6b73-493c-a66c-97009d305461}
m=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98
c=IN IP4 0.0.0.0
b=TIAS:3309000
b=AS:3500000
b=CT:3500000
a=sendrecv
a=ice-pwd:d3c8c3fc75524e350f772dd6a2e18720
a=ice-ufrag:094b1949
a=mid:1
a=msid:- {3c7e5399-03fc-465a-ab57-83a9e52322b4}
a=rtcp-mux
a=rtcp-rsize
a=fmtp:120 max-fs=12288;max-fr=60
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtpmap:120 VP8/90000
a=setup:actpass
a=ssrc:2289918276 cname:{3b9cbe3c-6b73-493c-a66c-97009d305461}
a=ssrc:2033347002 cname:{3b9cbe3c-6b73-493c-a66c-97009d305461}
a=ssrc-group:FID 2289918276 2033347002

v=0
o=WowzaStreamingEngine-next 702090643 2 IN IP4 127.0.0.1
s=-
t=0 0
a=fingerprint:sha-256
CC:8F:F5:8C:85:C0:9F:F7:9F:66:42:8E:8B:B6:62:DA:7D:84:B0:CB:85:EC:7B:31:99:9F:2C:7B:E7:3D:16:2C
a=group:BUNDLE 0 1
a=ice-options:trickle
a=msid-semantic: WMS *
m=audio 9 UDP/TLS/RTP/SAVPF 109
c=IN IP4 0.0.0.0
b=TIAS:44800
b=AS:64000
b=CT:64000
a=recvonly
a=ice-pwd:52469d111f8b5250d257282af7d24f18
a=ice-ufrag:77dc1da4
a=mid:0
a=msid:- {0d50371e-79b8-49de-91d0-71fc76ebe0b3}
a=rtcp-mux
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=rtpmap:109 opus/48000/2
a=setup:passive
m=video 9 UDP/TLS/RTP/SAVPF 120
c=IN IP4 0.0.0.0
b=TIAS:3309000
b=AS:3500000
b=CT:3500000
a=recvonly
a=ice-pwd:52469d111f8b5250d257282af7d24f18
a=ice-ufrag:77dc1da4
a=mid:1
a=msid:- {3c7e5399-03fc-465a-ab57-83a9e52322b4}
a=rtcp-mux
a=rtcp-rsize
a=fmtp:120 max-fs=12288;max-fr=60
a=rtcp-fb:120 nack
a=rtcp-fb:120 ccm fir
a=rtpmap:120 VP8/90000
a=setup:passive

2

@8c8380506e797f019271 Can you please confirm if the VP8 live playback plays well?

With Wowza recorder, we currently only support H.264 container:
https://www.wowza.com/docs/how-to-record-live-streams-wowza-streaming-engine#supported-file-formats1

I would be happy to add a feature request on your behalf, if you like.

3

I’m only working on recording at the moment, so I’m not in a position to easily test the live capability, sorry! Webm would be a useful addition, but it’s not critical for me right now, this was an experiment to see if VP8 did better than H264 on Firefox.

If Webm isn’t currently supported by Wowza for recording, can I suggest that you remove it from your own WebRTC code example on github ( WowzaMediaSystems/webrtc-example ) or add a note to the docs that come with this example to state that it can’t be used for recording.

Right now, VP8 is the default codec when the test client starts up, so this gave me the impression that it must be fully supported.

4

@8c8380506e797f019271 Thank you for the further details of what you were trying and for feedback regarding a note within the example. I’ll pass this along to our developer documentation team.