Luca Abeni wrote: > Hi Michel, > > Michel Bardiaux wrote: > [...] >> 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. > > I am not sure if I fully understand the problem, here, but in my understanding > there is not much to compensate: if pts_wrap_bits is 33, then the MPEG demuxer > generates timestamps on 33 bits, and if you consider only 33 bits there should > be no problem. > > >> 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. > > I suspect this is the problem. I do not know what the libavformat's behaviour > is supposed to be, but either: > 1) libavformat somehow take care of the rollover, converting timestamps from > pts_wrap_bits to 64 bits, or
It does not. > 2) libavformat only consider pts_wrap_bits, and in this case using 64bit > arithmetic on timestamps is wrong. Worse: some parts of libavformat (read_pes_header) only consider 33 bits, but other parts (like seeking) expect normal 64-bits arithmetic. > > >> 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. > > I do not think the muxer should be in charge of handling the rollover: in my The *muxer*? > understanding mpegps_read_pes_header should return 33bit timestamps. > So, I suspect the problem is somewhere else... > But maybe I am just confused ;-) Again: *if* read_pes_header is supposed to work as it does, ie return 33-bits timestamps, then the rest of libavformat should do the same, and I dont see how seek_frame could work then! In other words: for av_seek_frame to work, the rollover has to be compensated inside libavformat itself. Also, as Vladimir, and Michael Conrad, pointed out, if you pass timestamps truncated to 33-bits to av_write_frame, and rollover occurs, you get "non-monotonous timestamps" (and harakiri). This happens with ffmpeg-command-line too, which is weird to say the least, since an MPEG-1 system-stream file with rollover in the timestamps is strictly conformant AFAICS. -- Michel Bardiaux http://www.mediaxim.com/ _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
