firefox video player problem

[demirveriyaz]

we are testing pion sfu-ws example.

chrome -> chrome = works well
chrome -> firefox = not working
firefox -> chrome = works well
firefox -> firefox = not working

when subscirber is on firefox ontrack event firing and stream receiving successfully but when bind this stream html5 video player srcObject, video not playing

we research on google but nothing we tried was successful

---

this.peerConnection.ontrack = function (event) {
var player = $("#videoplayer")[0];
player.srcObject = event.streams[0];
player.autoplay = true;
player.controls = true;
}

---

local description:

v=0

o=mozilla...THIS_IS_SDPARTA-71.0 6064412144079911900 0 IN IP4 0.0.0.0

s=-

t=0 0

a=sendrecv

a=fingerprint:sha-256 AC:45:07:E2:B9:21:31:30:54:00:B9:20:40:33:29:81:BF:3D:66:06:F0:8F:61:1E:88:7C:84:53:26:F5:94:2F

a=group:BUNDLE 0

a=ice-options:trickle

a=msid-semantic:WMS *

m=video 48011 UDP/TLS/RTP/SAVPF 120 121 126 97

c=IN IP4 192.168.1.61

a=candidate:0 1 UDP 2122252543 192.168.1.201 60878 typ host

a=candidate:4 1 TCP 2105524479 192.168.1.201 9 typ host tcptype active

a=candidate:0 2 UDP 2122252542 192.168.1.201 60879 typ host

a=candidate:4 2 TCP 2105524478 192.168.1.201 9 typ host tcptype active

a=candidate:1 1 UDP 1686052863 78.40.226.197 62994 typ srflx raddr 192.168.1.201 rport 60878

a=candidate:1 2 UDP 1686052862 78.40.226.197 62997 typ srflx raddr 192.168.1.201 rport 60879

a=candidate:3 1 UDP 92217087 192.168.1.61 48011 typ relay raddr 192.168.1.61 rport 48011

a=candidate:3 2 UDP 92217086 192.168.1.61 27364 typ relay raddr 192.168.1.61 rport 27364

a=recvonly

a=end-of-candidates

a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid

a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

a=extmap:5 urn:ietf:params:rtp-hdrext:toffset

a=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay

a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1

a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1

a=fmtp:120 max-fs=12288;max-fr=60

a=fmtp:121 max-fs=12288;max-fr=60

a=ice-pwd:139edb2955e43accb16c5c552924ac68

a=ice-ufrag:2eb4c719

a=mid:0

a=rtcp:27364 IN IP4 192.168.1.61

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:121 nack

a=rtcp-fb:121 nack pli

a=rtcp-fb:121 ccm fir

a=rtcp-fb:121 goog-remb

a=rtcp-fb:126 nack

a=rtcp-fb:126 nack pli

a=rtcp-fb:126 ccm fir

a=rtcp-fb:126 goog-remb

a=rtcp-fb:97 nack

a=rtcp-fb:97 nack pli

a=rtcp-fb:97 ccm fir

a=rtcp-fb:97 goog-remb

a=rtcp-mux

a=rtpmap:120 VP8/90000

a=rtpmap:121 VP9/90000

a=rtpmap:126 H264/90000

a=rtpmap:97 H264/90000

a=setup:actpass

a=ssrc:1848870725 cname:{fd43f735-5a8e-4807-8ba3-db9c981514ff}

---

remote description:

v=0

o=- 41669618 1575535433 IN IP4 0.0.0.0

s=-

t=0 0

a=fingerprint:sha-256 21:9F:05:EE:FA:72:9E:D2:D5:16:46:A4:33:79:81:A9:3D:3E:C9:36:F0:AB:F1:1F:4C:3A:5E:A9:FA:20:A6:02

a=group:BUNDLE 0

m=video 9 UDP/TLS/RTP/SAVPF 96

c=IN IP4 0.0.0.0

a=setup:passive

a=mid:0

a=ice-ufrag:KvRiTNiAuhGEtGfr

a=ice-pwd:FgNjacpyobjxhfIXAyDVirIqrChDWitH

a=rtcp-mux

a=rtcp-rsize

a=rtpmap:96 VP8/90000

a=ssrc:899444349 cname:pion

a=ssrc:899444349 msid:pion video

a=ssrc:899444349 mslabel:pion

a=ssrc:899444349 label:video

a=sendonly

a=candidate:foundation 1 udp 2130706431 93.187.206.39 56707 typ host generation 0

a=candidate:foundation 2 udp 2130706431 93.187.206.39 56707 typ host generation 0

a=candidate:foundation 1 udp 2130706431 192.168.1.61 35784 typ host generation 0

a=candidate:foundation 2 udp 2130706431 192.168.1.61 35784 typ host generation 0

a=candidate:foundation 1 udp 1694498815 93.187.206.39 21303 typ srflx raddr 0.0.0.0 rport 21303 generation 0

a=candidate:foundation 2 udp 1694498815 93.187.206.39 21303 typ srflx raddr 0.0.0.0 rport 21303 generation 0

a=candidate:foundation 1 udp 16777215 192.168.1.61 21817 typ relay raddr 0.0.0.0 rport 11963 generation 0

a=candidate:foundation 2 udp 16777215 192.168.1.61 21817 typ relay raddr 0.0.0.0 rport 11963 generation 0

a=end-of-candidates

[Sean-Der]

Hey @demirveriyaz! Thanks for using Pion.

Does sfu-minimal have the same issues? I don't actively the other repo (I encourage people to share little projects they wrote their)

If sfu-minimal works I can probably update sfu-ws quickly though.

[demirveriyaz]

on sfu-minimal project

go build

getting this error

use of internal package github.com/pion/webrtc/v2/examples/internal/signal not allowed

[demirveriyaz]

when we use

mediaEngine.RegisterCodec(webrtc.NewRTPOpusCodec(webrtc.DefaultPayloadTypeOpus, 48000))

so

111 opus/48000

chrome -> chrome = works well
firefox-> chrome = works well
chrome -> firefox= fail
firefox-> firefox= fail

when use that codec (0 PCMU/8000), which is included chrme and firefox

mediaEngine.RegisterCodec(webrtc.NewRTPPCMUCodec(webrtc.DefaultPayloadTypePCMU, 8000))

chrome -> chrome = works well
firefox-> chrome = works well
chrome -> firefox= works well
firefox-> firefox= works well

---

firefox audio

a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000/1

---

chrome audio

a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
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:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000

---

but both chrome and firefox also have the same payload a codec

list is here:

firefox vide codecs:

a=rtpmap:120 VP8/90000
a=rtpmap:121 VP9/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000

---

chrome video codecs:

a=rtpmap:96 VP8/90000
a=rtpmap:97 rtx/90000
a=rtpmap:98 VP9/90000
a=rtpmap:99 rtx/90000
a=rtpmap:100 VP9/90000
a=rtpmap:101 rtx/90000
a=rtpmap:102 H264/90000
a=rtpmap:122 rtx/90000
a=rtpmap:127 H264/90000
a=rtpmap:121 rtx/90000
a=rtpmap:125 H264/90000
a=rtpmap:107 rtx/90000
a=rtpmap:108 H264/90000
a=rtpmap:109 rtx/90000
a=rtpmap:124 H264/90000
a=rtpmap:120 rtx/90000
a=rtpmap:123 H264/90000
a=rtpmap:119 rtx/90000
a=rtpmap:114 red/90000
a=rtpmap:115 rtx/90000
a=rtpmap:116 ulpfec/90000

---

how to solve this codec problem. is there a solution i can use to control html5 video in this stream? otherwise it can be used as an alternative. Does javascirpt vp8 decoder work?

[Sean-Der]

hey @demirveriyaz I did some sleuthing and I remember this has always been broken :/

Right now I think the best way to implement this is to have a unique Track for each PeerConnection (so you can have the write PayloadType for each one)

There was an attempt to fix this https://github.com/pion/webrtc/pull/782/files but it didn't get merged. I will work on fixing this for /v3 wasn't even aware of the issue unfortunately. Sorry about that!

[iansweeneysg]

Hi @Sean-Der @demirveriyaz , I think we seeing something similar.

We only using audio tracks and unable to perform AudioContext createAnalyser() in chrome or firefox. Audio plays in chrome but does not in firefox.

When creating a peerConnection.ontrack eventhandler, initially we seeing the event.streams[0].id = 'OTVlungShKKfXMHN', but after making a second publish request, event.streams[0].id becomes 'pion1' and our analyser works in chrome.

It looks like the problem is cause by
Serverside publishing stream id as 'pion1'
clientside expecting stream id as 'OTVlungShKKfXMHN'

[chrbsg]

Just following up to @iansweeneysg above - the Chrome stream ID issue was caused by #989 and the "no audio in Firefox " issue was #1030.

[jeremija]

I believe I ran into a similar issue with Firefox, but I'm only streaming video.

The video streams when the server creates the initial offer and receives the video from the browser, and then sends back a copy of the track. However, when initial offer is created client-side and I send a copy of the track back to the client, the video does not play in Firefox, but does in Chrome.

It appears Firefox is using different IDs for streams:

Server-side (Pion) generated offer (video works in Firefox and Chrome)

a=rtpmap:120 VP8/90000
a=rtpmap:121 VP9/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000

Browser (user agent) answer:

a=rtpmap:96 VP8/90000
a=rtpmap:98 VP9/90000

Firefox's Offer (no video in Firefox)

a=rtpmap:120 VP8/90000
a=rtpmap:121 VP9/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000

Server-side answer

a=rtpmap:96 VP8/90000
a=rtpmap:98 VP9/90000
a=rtpmap:102 H264/90000

Chrome's Offer (video works in Chrome)

a=rtpmap:96 VP8/90000
a=rtpmap:97 rtx/90000
a=rtpmap:98 VP9/90000
a=rtpmap:99 rtx/90000
a=rtpmap:100 VP9/90000
a=rtpmap:101 rtx/90000
a=rtpmap:102 H264/90000
a=rtpmap:122 rtx/90000
a=rtpmap:127 H264/90000
a=rtpmap:121 rtx/90000
a=rtpmap:125 H264/90000
a=rtpmap:107 rtx/90000
a=rtpmap:108 H264/90000
a=rtpmap:109 rtx/90000
a=rtpmap:124 H264/90000
a=rtpmap:120 rtx/90000
a=rtpmap:123 H264/90000
a=rtpmap:119 rtx/90000
a=rtpmap:114 red/90000
a=rtpmap:115 rtx/90000
a=rtpmap:116 ulpfec/90000

Server-side answer:

a=rtpmap:96 VP8/90000
a=rtpmap:98 VP9/90000
a=rtpmap:102 H264/90000

The problem in Firefox is fixed when I register the VP8 codec (again) with a payload ID of 120 (Pion's default for VP8/90000 is 96):

mediaEngine.RegisterDefaultCodecs()
mediaEngine.RegisterCodec(webrtc.NewRTPVP8Codec(120, 90000))

I'd love to use mediaEngine.PopulateFromSDP as suggested in one of the related issues. However, this does not work when peers connect first without any video and then later renegotiate, because mediaEngine is passed by value to WithMediaEngine(webrtc.MediaEngine) - any subsequent changes to media engine won't be visible to the peer connection.

Is there any particular reason for this design decision?

[Sean-Der]

Covered by https://github.com/pion/webrtc/projects/17

Having users juggle PayloadTypes/SSRCs was a bad design, and we are working on fixing it! I have included the roadmap that covers this. The /v3 will remove the user having to worry about this.

[MichealReed]

@Sean-Der any workarounds until v3 is ready to go? Currently experiencing this.

[jeremija]

@MichealReed my workaround was to only initiate peer connections/renegotiations from the server side. That way you can control the payload types.

If you initiate the first connection from Pion, I think you should be able to renegotiate from the browser and it should keep the original Payload Type IDs.

[MichealReed]

@jeremija I'm using ion as an SFU, which I assume should already function this way. I'm currently using STUN only, could spinning up a TURN server cause the events to be initiated through the server only?

[jeremija]

@MichealReed sorry - I'm not that familiar with Ion. A TURN server won't help you with Payload Type IDs, since it's only function is to help establish a relay in case a direct connection is not possible.

I think some people on Slack channel have had success by manually modifying Payload Type IDs in the RTP packets, but I've never done it myself.