[Libav-user] RTSP and duration limitation

[Yurii Monakov]

> 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 <monakov.y at gmail.com>:

> 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 at 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 at ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/libav-user
>>
>> To unsubscribe, visit link above, or email
>> libav-user-request at ffmpeg.org with subject "unsubscribe".
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20230215/252e0343/attachment.htm>