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 <libav-user@ffmpeg.org >: > 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 > Libav-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/libav-user > > To unsubscribe, visit link above, or email > libav-user-requ...@ffmpeg.org with subject "unsubscribe". >
_______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email libav-user-requ...@ffmpeg.org with subject "unsubscribe".
