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
2) libavformat only consider pts_wrap_bits, and in this case using 64bit
arithmetic on timestamps is wrong.
> 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
understanding mpegps_read_pes_header should return 33bit timestamps.
So, I suspect the problem is somewhere else...
But maybe I am just confused ;-)
Luca
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
