Background info: we encode 24/7, by files of 1 minute, using MPEG-1 (with lavc of course!). The timestamps and timecodes in the files are supposed to be *exact* - that is, they are the 1970-based time, converted to the 90kHz clock, and of course truncated to 33 bits by the MPEG muxer.
On decoding, av_read_frame gives the timestamps as found, hence every 26 hours, the time apparently recycles (but contrary to Monopoly I don't get €50 each time :-)). So, apparently the burden of compensating for the rollover is left to the user. The sequential reading is relatively easy to handle, I just need to remember whether my wrapper for av_read_frame has seen a TS bigger than say 1 million; then if it sees a ts near zero, rollover has occurred and I just have to add 2exp33. (That would only work for files < 26+ hours, but an MPEG that long is bloody unlikely!) The seek, however, is something else entirely since it uses arithmetic on timestamps as if they were plain normal 64bits integers, without rollover. One can disable the index rather easily, but even then the seek is unlikely to work when rollover occurs in the file. From reading The Fine Source, it seems the critical function is mpegps_read_pes_header and if I patch that to handle the rollover (ie add 2exp33 when appropriate) everything would work just right. But before proposing a patch to -devel, I would like to know whether there is a pure client-side solution? TIA? --- Michel Bardiaux http://www.mediaxim.com/ _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
