search

popcornmix / omxplayer

omxplayer
GNU General Public License v2.0
1.02k stars 333 forks source link

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

Open Litrona opened 3 years ago

Litrona commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.