GetCurrentPTS() jumps more than 10 hours back, after 95382 seconds of live playback

[Litrona]

I know this project is deprecated, but mabbe someone could help me with this issue.
The commandline used is:
omxplayer -s -o hdmi --live --no-osd http://192.168.1.168/0.ts
The source is live streaming video from a hardware encoder. No matter if I connect to rtsp or whatever, the issue always happens exactly a the same stamp point (after 95382 seconds, exactly when: m_av_clock->OMXMediaTime() > 95382000000)

M:95382739951 V: 0.83s 80k/ 4800k A: 0.79 0.59s/ 6.07s Cv: 0k Ca: 0k A_PTS:95383527611 V_PTS:95383572622
M:95383219988 V:-69027.66s 0k/ 4800k A:-69027.70 0.63s/ 6.07s Cv: 0k Ca: 0k A_PTS:26355526478 V_PTS:26355559500

I added to https://github.com/popcornmix/omxplayer/blob/master/omxplayer.cpp#L1655, logging code for:

double audio_pts = m_player_audio.GetCurrentPTS(); // A_PTS
double video_pts = m_player_video.GetCurrentPTS(); // V_PTS

Once it comes to that point, the audio_fifo and video_fifo get negative, so it is latency, at lines 1703 or 1705. And playback speed control from line 1719 to 1731, always sets speed = 0.990f; so playback starts shivering forever.
I saw that implied variables have enough room (double typed), so it is not an overflow issue.
I guess that wrong audio and video PTS values may come from libavformat.

Any clue on how to solve this issue ?
Thanks in advance.

[premultiply]

The PTS (and DTS) is a 33bit value sampling a 90 kHz clock derived from the MPEG-TS PCR value. So there is a rollover after 95443 seconds in these values. Something may be buggy in the clock rollover code. What type is that encoder?

[Litrona]

The hardware encoder, is a generic Hi3516A chipset H.264 encoder.
However, double stamp = m_av_clock->OMXMediaTime(); keeps growing the same rate, while PTS seems to rollover.