Setting the time_base of the stream to the same of the incoming video tracks fixes errors some receive when recording incoming video tracks.
Original problem:
The problem can be reproduced by sending a video stream with more than 30 FPS and attempt to record it via MediaRecorder.
Typical error messages start with "non-strictly-monotonic PTS error" or " Application provided invalid, non monotonically increasing dts to muxer in stream ..." related to issues #580 and probably #520
I suspect the root cause is that AV might default to a time base of 1/30 (if rate is set to 30). If the stream is received at 60FPS then two frames will share a timestamp once converted into the new time base. Many WebRTC based senders also do not enforce a fixed framerate so even 30FPS can randomly have two frames too close together and causing this issue.
I tested this with both png and libx264 with no problems discovered so far.
Setting the time_base of the stream to the same of the incoming video tracks fixes errors some receive when recording incoming video tracks.
Original problem: The problem can be reproduced by sending a video stream with more than 30 FPS and attempt to record it via MediaRecorder. Typical error messages start with "non-strictly-monotonic PTS error" or " Application provided invalid, non monotonically increasing dts to muxer in stream ..." related to issues #580 and probably #520
I suspect the root cause is that AV might default to a time base of 1/30 (if rate is set to 30). If the stream is received at 60FPS then two frames will share a timestamp once converted into the new time base. Many WebRTC based senders also do not enforce a fixed framerate so even 30FPS can randomly have two frames too close together and causing this issue.
I tested this with both png and libx264 with no problems discovered so far.