> You can set correct_ts_overflow ffmpeg parameter on the client to fix this. One important note: you should set this parameter 0.
ср, 15 февр. 2023 г. в 23:04, Yurii Monakov <[email protected]>: > Hello > > If you are using ffmpeg on the client too, this is a strange feature of > core demuxer. RTP timestamp wraps > at 2^32/(90000*3600) ~= 13 hours 15 minutes. RTP decoder correctly unwraps > RTP timestamps to 64-bit > values. But later, in demux.c, they are treated as 32-bit and incorrectly > unwrapped twice, producing negative > timestamp deltas. > > You can set correct_ts_overflow ffmpeg parameter on the client to fix this. > > If you are not using ffmpeg as RTSP client, you can look at finalize_packet > function in libavformat/rtpdec.c > to write your own unwrap code. > > Yurii > > Ср, 15 февр. 2023 г. в 08:54, wolverin via Libav-user < > [email protected]>: > >> Hello, maybe someone has encountered — I transcoding from MJPEG to H264 >> and streaming RTSP publication to the server, everything works well for >> exactly 13 hours and 15 minutes, then the pts/dts timestamps on the server >> suddenly start coming from scratch, therefore the online video goes down, I >> don't have timestamps reset in the code and don't set the duration for >> online stream. >> where can the duration of the stream be set or what can affect it??? >> >> >> >> _______________________________________________ >> Libav-user mailing list >> [email protected] >> https://ffmpeg.org/mailman/listinfo/libav-user >> >> To unsubscribe, visit link above, or email >> [email protected] with subject "unsubscribe". >> >
_______________________________________________ Libav-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
