paullouisageneau
Named threads causes performance regression on Windows
I only have access to macOS/Linux so I am not able to reproduce this myself unfortunately.
Windows developers report that with these commits they are seeing significant amount of packet loss. When reverted things work again.
- https://github.com/paullouisageneau/libdatachannel/commit/80d1ae90aabe881332a1ec2f2ab18b5e09db5ba1
- https://github.com/paullouisageneau/libjuice/commit/09ce20fee7cf637b46afd1450e3ff28fe65f09d0
@pkviet Does that match with what you saw?
it's not packet loss; it's a threading issue where the rendering pipeline is blocked for a constant 2 second, so we miss frames (ex: 100 frames at 50 fps). There's no issue on linux, nor with datachannel + mbedtls compiled on MSVC. I haven't checked against openssl. The frames are passed to libdatachannel from what I can see though. So it's unclear to me where it's stalling. I'd need to breakpoint in datachannel but our cross compiled dlls have no pdb.
Thread naming is a no-op on Windows so I don't think it could explain the behavior.
The libjuice update d3938a77697a55a285a26941c24a24e931f1046f introduces the implementation of ICE PAC (RFC 8863), which may result in different ICE nomination timings. I think it could trigger such frame drops as I'm not sure that the WHIP output pipeline properly waits for an open connection: https://github.com/obsproject/obs-studio/pull/7926#discussion_r1199820253
Got a clue. The bug occurs also with msvc builds of libdatachannel if mbedtls is build with multithreading enabled. So the core issue lies with multithreading in mbedtls. If multithreading is disabled, the bug is gone. Points to something in mbedtls support in libdatachannel @Sean-Der