On 06/11/2016 08:19 PM, Marton Balint wrote: > > On Sat, 11 Jun 2016, DeHackEd wrote: > >> Presently the mpegts demuxer passes the timestamps from received packets >> directly to the output AVPackets. 2^33 / 90000 >> seconds is about 26.5 hours at which point applications start having a fit, >> and that's assuming timestamps begin at >> time 0. >> >> So here's a first revision of a patch to fix that issue. >> >> Improvements possible: >> * In its current form intended for continuous sources like over-the-air >> receivers and multicast sources. When used on >> files there will be problems with seeking. >> * Constants such as 2^33 could be turned into macros for readability >> > > I think there is already an infrastructure for handling PTS wraparound when > decoding, check > AVStream->pts_wrap_behaviour. Or is this something else?
The behaviour here is that when the DTS is less than its original value, it will be incremented by the wrap point -- 2^33 in this case. But that's all it does. If the timestamp comes back around to its original value, the effect stops and you get non-monotonic DTS values. In the mpegts case this means that regardless of the starting point of the timestamps you will get 26.5 hours before it breaks. > > Thanks, > Marton > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
