Luca Abeni wrote:
>
>>>>>> But why does negative value appear?
>>>>> Because you are printing the timestamp as a signed value ;-)
>>>>>
>>>> Yes, that's right.
>>>> However, I thought, that sign bit is 63th.
>>> Sorry, but I do not get your point:
>>>> 8589927402(10) = 111111111111111111110001111101010(2)
>>>> The timestamps have a difference of 3600, so if I append 3600, I will
>>>> get
>>>> 8589931002 ( 111111111111111111111000111111010)
>>> Which, printed as a signed integer is -3590
>>
>> Only if your to-decimal function operates specifically on 33 bit values.
>
> Yes, we are reasoning in the assumption that av_read_frame() returns 33bit
> values (from Vladimir's findings, it seems it does - I do not know if this
> is intended or if this is a bug):
>
It returns int64_t values, the C language doesn't have a type with a length
of exactly 33 bits.
So, the upper 31 bits of the returned values should remain 0 in any way.
I didn't print them in my previous mails, but all binary values should be
prepended with 31 zeroes (8589931002 =
000...0111111111111111111111000111111010).
However, something sets them to 1, and we obtain -3590.
--
View this message in context:
http://www.nabble.com/How-to-handle-33-bits-rollover-in-MPEG--tp18282365p18337203.html
Sent from the libav-users mailing list archive at Nabble.com.
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
