Observe PTS counter overflow #1227

Closed
wants to merge 2 commits into from

3 participants

@FernetMenta
Team Kodi member

This fixes ticket 13133.

  • ffmpeg failed seeking in mpeg-ts files if 33bit PTS counter did overflow.
  • dvdplayer showed wrong timing information
@jmarshallnz
Team Kodi member

@elupus ping

@elupus elupus and 1 other commented on an outdated diff Aug 15, 2012
xbmc/cores/dvdplayer/DVDDemuxers/DVDDemuxFFmpeg.h
@@ -121,7 +121,7 @@ class CDVDDemuxFFmpeg : public CDVDDemux
int ReadFrame(AVPacket *packet);
void AddStream(int iId);
- double ConvertTimestamp(int64_t pts, int den, int num);
+ double ConvertTimestamp(int64_t pts, int den, int num, int streamIdx = -1);
@elupus
Team Kodi member
elupus added a note Aug 15, 2012

Just pass a stream pointer instead. then den/num isn't needed either.

@FernetMenta
Team Kodi member

I thought about this but chapter has den/num as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@elupus
Team Kodi member

I¨m a bit hesitant what it might break. Would have been nice to run this by some ffmpeg devs. Feels like it should be solved somewhere deeper into fffmpeg.

@elupus
Team Kodi member

The internal timestamp index in ffmpeg expects linearly increasing timestamps to, so i bet more things get broken here. I've many times thought we should ignore time based seeking for mpegts only use average bittrate and position in file.

@FernetMenta
Team Kodi member

I will ask the ffmpeg devs about this.

@FernetMenta
Team Kodi member

@elupus
You were right, here is the answer from ffmpeg: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-August/129720.html

I have changed the pr as you suggested. It does a file based seek for input formats that allow discontinuity in timestamps.

@FernetMenta
Team Kodi member

I have changed it again. Although it does not handle all use cases for discontinuity in timestamps, it does at least handle this very common use case that about 10% of all tv recordings have a pts overflow and won't be able to seek or fast forward.

The strategy:
After a seek (current function) it checks if the result is more than 10s off. Can't get worse, right? If so, it does a bisect seek (code taken from ffmpeg) and assumes a pts overflow.

@elupus
Team Kodi member

This pulls in way too much complicated code from ffmpeg. Fixup ffmpeg's idea of total duration, then do byte based seek based on percentage position in file instead.

@elupus
Team Kodi member

Also, seems weird that you have so many files with pts wraparound. It doesn't wrap very often.

@elupus
Team Kodi member

But as michael said. This should likely be fixed lower down in the mpegts demuxer. Having it correct for at least 1 wrap in the file.

@FernetMenta
Team Kodi member

Also, seems weird that you have so many files with pts wraparound. It doesn't wrap very often.

It wraps every 26 hours on tv. Hence it is very likely that a recording does not seek.

@elupus
Team Kodi member
@FernetMenta
Team Kodi member

I already tried byte based seek with percentage. Unfortunately the result was not very good, in particular when doing ff or rewind which uses seek as well.

@FernetMenta
Team Kodi member

@elupus
I agree that ideally a fix should come from ffmpeg but I don't think we can expect one in the near future. This work around only engages if ffmpeg seek has badly failed.
I cleaned this up a bit. Now after PVR is in I think this would make many (at least vdr) users happy.

@FernetMenta FernetMenta deleted the FernetMenta:ptsfix branch Mar 23, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment