[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