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".
