[WebRTC] OperationError: Duplicate payload type with conflicting codec name or clock rate., retrying in some seconds on iPad

[xiew]

Which version are you using?

v1.8.3

Which operating system are you using?

• Linux amd64 standard
• Linux amd64 Docker
• Linux arm64 standard
• Linux arm64 Docker
• Linux arm7 standard
• Linux arm7 Docker
• Linux arm6 standard
• Linux arm6 Docker
• Windows amd64 standard
• Windows amd64 Docker (WSL backend)
• macOS amd64 standard
• macOS amd64 Docker
• Other (please describe)

Describe the issue

When I use a UDP MPEG-TS stream (h264 packets with opus encoded audio) into Mediamtx and read via RTSP (VLC) or WebRTC (Chrome) on a desktop everything works fine. However on an iPad, while RTSP (through VLC) works fine, the WebRTC site on both Safari and Chrome display the error:

OperationError: Duplicate payload type with conflicting codec name or clock rate., retrying in some seconds

The stream never loads and I can't get WebRTC through the browser. I am working through a zerotier setup so the tunneling or NAT and all that shouldnt be an issue as they use UDP hole punch. Let me know if you need anything else.
Thanks for your continued work on this project!

Describe how to replicate the issue

1. start the server on a raspberry pi
2. publish with gstreamer the following pipeline: rpicam-vid -t 0 -n --inline -o - | gst-launch-1.0 fdsrc fd=0 ! h264parse config-interval=-1 update-timecode=false ! queue ! mpegtsmux name=mux ! udpsink host=127.0.0.1 port=1234 alsasrc device="plughw:CARD=0" ! audio/x-raw,channels=1 ! opusenc ! queue ! mux.
3. read with iPad with iOS 16.7.8 on chrome via WebRTC

Did you attach the server logs?

no

Did you attach a network dump?

no

[pikachu937]

I have the same problem on one of the iOS and Android mobile platform

[pikachu937]

The strangest thing is that this is not reproduced for everyone and if the Android settings are more open and you can break something yourself, then in the iPhone/iPad it is really problematic to do this

Also, the problematic mobile devices were reset to default settings, but this did not solve the problem

[pikachu937]

I collected a small dump from the test server, there are 131 streams and I am trying to connect from iPhone 15 and iPhone 14
Addresses like XXX.XXX.XXX.XXX belong to iPhone 15
Addresses like YYY.YYY.YYY.YYY belong to iPhone 14
mediamtx_test.log
According to the test results, it is clear that iPhone 14 cannot receive video

Immediately after testing, I rolled back the mediamtx version to 1.8.1 and did not find such an error, both phones (iPhone 14 and iPhone 15) play videos without problems

[clee604]

edit - nevermind clearing cache doesn't work; though it's strange that if a stream page is open while the mediamtx is upgraded, the stream continues fine until the next time i stop it and then the error shows up.

I have the same issue on one of my devices (old cherrytrail tablet) running ChromeOS and using Chrome to view a WebRTC proxy stream. Only this device has issues;

[clee604]

Some additional findings on my end,

• 1.8.2 seems to be the last version that works for this device
• doesn't matter what the stream source is (ie. wyze cam, tapo, eufy) the webrtc proxy shows same error
• clearing cache did not help when upgrading

[pikachu937]

Some additional findings on my end,

• 1.8.2 seems to be the last version that works for this device
• doesn't matter what the stream source is (ie. wyze cam, tapo, eufy) the webrtc proxy shows same error
• clearing cache did not help when upgrading

That's right, everything works in version 1.8.2 and below. So for now I just rebuilt version 1.8.3 and returned the read_index.html file from version 1.8.2 to it.

[clee604]

So if you compile the latest version but with the 1.8.2 version of 'read_index.html' everything works fine?

[pikachu937]

So if you compile the latest version but with the 1.8.2 version of 'read_index.html' everything works fine?

Yes, but it seems to me that this is not entirely correct and this bug needs to be fixed in the original version of the file, so dear @aler9, please fix it.

[github-actions]

This issue is mentioned in release v1.9.0 🚀
Check out the entire changelog by clicking here