3 ms·

Sorry you hit these issues :( Instead of restart/renegotiation can you re-timestamp the packets? The example swap-tracks[0] shows a good way to do that. The re

Sorry you hit these issues :( Instead of restart/renegotiation can you re-timestamp the packets? The example swap-tracks[0] shows a good way to do that. The renegotiation (especially multiple times with no real changes) is gonna be a PITA :) Also you should share in https://pion.ly/discord https://pion.ly/discord other people would love to see this. Super cool project. [0] https://github.com/pion/webrtc/blob/master/examples/swap-tracks/main.go#L186-L202 https://github.com/pion/webrtc/blob/master/examples/swap-tra...

frudas24 9mo ago
Thanks, that’s a great suggestion :) You’re right that re-timestamping is the proper way to avoid renegotiation, and the swap-tracks example is exactly the direction to take. In our case, monitor/crop changes usually required restarting ffmpeg, which often reset more than just timestamps (SSRC, sequence continuity, SPS/PPS timing), so renegotiation became the brute-force fallback. That said, I’m definitely going to try your recommendation and experiment with re-timestamping / track swapping to see how far we can get without renegotiation, especially on mobile browsers. Thanks as well for the Discord link, I’ll share the project there. Appreciate the concrete pointers.
- frudas24 9mo ago
  fixed :)