On 11/14/23 11:05, Tomas Härdin wrote: > This patchset is missing tests. I know that we for some reason don't > really have tests for protocols, but I feel the issue is worthwhile to > bring up. I've worked a bit with WebRTC recently and it's fiddly, so > it'd be nice to have some automated thing that keeps track of which > WebRTC implementations this works with. Or maybe this is better handled > with an external project, testing which implementations interoperate?
I agree that having automated tests would be useful for stability in the future. I tested the patchset with both SRS and Millicast, and it worked well. For automated testing, we could use FATE, but it needs an extra server with protection and someone to keep it updated. Testing with paid services like Millicast is tricky. Another option is an external project for WebRTC testing, but the challenge is keeping it maintained and compatible with changes in implementations. External services might update their software, causing issues with tests. We would need a plan for dealing with that. For paid services like Millicast, we need to figure out who pays for the tests. Understanding the costs is essential if we want to use paid services for testing. I'd like to hear your thoughts on these points and how you would propose to proceed with adding tests for protocols like WebRTC. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
