[MPlayer-users] A/V out of sync + corrupted time stamps on x86_64for some files [SOLVED]
Christian Aistleitner
tmgisi at gmx.at
Wed May 3 17:39:06 CEST 2006
Hello again,
>> CVS: main/libmpdemux demux_mpg.c,1.78,1.79
>> http://mplayerhq.hu/pipermail/mplayer-cvslog/2006-April/024687.html;
>
>
> surely not that patch itself (that is correct), maybe something related.
That depends on what you mean by "correct" :)
If you wanted that patch to change the
- return type to unsigned long long and the
- type of pts (2x), dts (1x) to unsigned long long
the above patch is correct.
However, if you wanted to correctly move from unsigned int to unsigned
long long representation for timestamps in the mpeg demuxer (which i
considered the goal), the patch is not correct.
The reason is in line 164 of the current cvs version of
libmpdemux/demux_mpg.c:
pts=(((c>>1)&7)<<30)|((d>>1)<<15)|(e>>1)
As far as I can tell, c is an int and d and e are unsigned int.
In my recorded file, in one packet, there
c = 0x2D
d = 0x49D
e = 0x8539
occurs.
What is the result?
v1.79 gives: FFFFFFFF8127429C (I assume, you see the sign problem)
v1.78 gives: 8127429C (not correct, but the best possible value in
unsigned int)
The correct value would be: 18127429C
Maybe this should go to a devel mailing list, as this is actually a patch
now...
I am not a C exert, but I'd sugest, to replace the above line by
pts=((((unsigned long long)c>>1)&7)<<30)|(((unsigned long
long)d>>1)<<15)|((unsigned long long)e>>1);
Then:
- no shifting is sign affected (<< shifts)
- no shifting is limit to int (32-bit) precision (>> shifts)
Finally, read_mpeg_timestamp gives 18127429C, as expected.
--
Kind regards,
Christian
More information about the MPlayer-users
mailing list