kolserdav
commented
1 year ago I tried to figure out how rtp.payload becomes null. This line https://github.com/shinyoshiaki/werift-webrtc/blob/39c9756f27151f3db773e6edb5fd49c3f84343a8/packages/webrtc/src/media/rtpReceiver.ts#L331 is referenced by the fourth element from the top of the error stack, if it is logged there, then the payload is never null. The second error stack entry from the top refers to this line https://github.com/shinyoshiaki/werift-webrtc/blob/39c9756f27151f3db773e6edb5fd49c3f84343a8/packages/webrtc/src/media/rtpSender.ts#L196 , if it is logged there, then the payload is indeed null before an error is thrown.
The conclusion suggests itself that the payload when recording a stream, when this stream needs to connect to another client, sometime becomes null somewhere inside rx.mini.
Roughly handling these exceptions does nothing, even if the error does not pop up, then such a stream is never played or recorded.
@shinyoshiaki , I need your help to find the reason for the RTP of stream packets crossing while recording and sending to clients at the same time.
Once again, note that this problem only occurs when trying to connect to a stream that is in the recording. But if we start recording streams of already connected clients, then everything works fine.
shinyoshiaki
When recording a stream of one client through MediaRecorder, the second client cannot connect to it, as an error occurs when sending RTP packets
The top element of the error stack refers to this line https://github.com/shinyoshiaki/werift-webrtc/blob/39c9756f27151f3db773e6edb5fd49c3f84343a8/packages/webrtc/src/media/rtpSender.ts#L368
Between adjacent cycles of outputs of these errors, something like the following occurs:
The recording is made by the client thread under id 1, the client connects under a different id. As can be seen from the logs, the error occurs not on the connection where the second client sends its media tracks to the server, but on the connection where it tries to receive incoming media tracks from client 1.