Hi Michel,
Michel Bardiaux wrote:
> 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.
Ok
>> 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,
read_pes_header is in the demuxer, so I think it is right in considering
only 33 bits
> but other parts (like seeking) expect normal 64-bits arithmetic.
I think this is the bug (but, again, this is just my understanding - or maybe
misunderstanding... Michael should say something here). In my understanding,
either there should be some code in libavformat which does the 33->64bit
conversion, or the seeking code should not do 64bits 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*?
Sorry, that was a typo. I obviously wanted to write "demuxer"
>> 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
or could contain some code (in the generic code, not in the demuxer) to
do the 33->64 conversion...
> 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.
I agree with you, here. I just think that the compensation should be done
in generic code, and not in the mpeg-specific one.
> 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).
Ok; there is a clear asymmetry between av_read_frame() and av_write_frame().
I do not know if it is intended or not.
I think we need some authoritative opinion here (Michael?).
Luca
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
