Closed thegobot closed 1 year ago
Well it seems a discussion, and it not likely to happen so that we don't need to fix it?
I suggest disabling the default option
time_jitter off #OR zero
I didn't get you, what's the issue? To play RTMP stream? How to replay this issue?
I didn't get you, what's the issue? To play RTMP stream? How to replay this issue?
this is a borderline case. When changing the video resolution, my encoder(android yasea) sends the timestamps that I described at the beginning. Only disabling the jitter helped me
Yes, issue with playing (flv)
Rather than changing the default config value, it's much better to fix the jitter algorithm to fix this borderline case.
Patch welcome. 😄
Alas, I can't make a patch. although with jitter disabled there are audio problems (flvjs) ... ohhh, I dream of switching completely to webrtc, I'm still testing, but it works great. flvjs is still a crutch...
if there is a big difference between the previous timestamp and the current timestamp - playback error
https://github.com/ossrs/srs/blob/b06661539c2d02b35b45e89df1bc23a43cabd0a3/trunk/src/app/srs_app_source.cpp#L73
ffplay [flv @ 0000000000555700] DTS 16925 < 16983 out of order
srs_trace("%d ==> %d, last_pkt_time:%d, delta: %d, %s", msg->timestamp, last_pkt_correct_time, last_pkt_time, delta, msg->is_audio() ? "audio" : "video");
Format: msg->timestam ==> last_pkt_correct_time, last_pkt_time, delta
SRS: 4.0.178