Opened 12 years ago

Closed 12 years ago

#872 closed defect (invalid)

av_rescale_q returns wrong 64bits in arm cortex-a8 processor

Reported by: kaijun Owned by: Michael Niedermayer
Priority: important Component: avutil
Version: git-master Keywords: av_rescale_q
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

When I try to convert a audio pts timestamp 61415424 into clock time via av_rescale_q() of mathmatics.c in arm cortext-a8 processor of beagleboard, it returns a wrong 64bit.
in av_rescale_rnd(a,b,c,AV_ROUND_NEAR_INF), where a=61415424, b=1000000000, c=28224000, I checked it's return value is 2176000000 (0x81B32000). But it returns 18446744071590584320 (0xFFFFFFFF81B32000). It seems the high 32bits return minus instead of 0x0 due to sign bit in low 32bit (for timestamp smaller than 61415424, there is no problem). This case never happened when I used ffmpeg from svn repository.

Change History (22)

comment:1 by Michael Niedermayer, 12 years ago

you could add a few av_log/printf or use a debugger to follow the code in av_rescale_rnd() and check where it goes wrong

comment:2 by kaijun, 12 years ago

yes, I have debugged. The value is correct inside av_rescale_rnd(). But after it returns, the value is wrong.

comment:3 by Michael Niedermayer, 12 years ago

That sounds like a compiler bug

comment:4 by kaijun, 12 years ago

I use same compiler. This case happens at e1a86d03855f2fb1bf7961efd6794ddd9226f228 (master-git), but not at c6c2dfcf15c1d93b2189adff6f71c5c4b6b05338 (0.6.2). I guess some compilation options in configure or Makefile produce the issue.

comment:5 by Carl Eugen Hoyos, 12 years ago

Please use git bisect to find the version introducing the problem.

comment:6 by Carl Eugen Hoyos, 12 years ago

Which compiler are you using?

comment:7 by kaijun, 12 years ago

angstrom

comment:8 by Carl Eugen Hoyos, 12 years ago

I don't know what "angstrom" is but I would have expected a version number or "cc -v" output - please provide that.
Do I understand correctly that the problem cannot be reproduced with gcc?

comment:9 by kaijun, 12 years ago

arm-angstrom-linux-gnueabi-gcc is a cross-compiler for arm-based device like beagleboard.

run arm-angstrom-linux-gnueabi-gcc -v

Using built-in specs.
COLLECT_GCC=tmp/sysroots/x86_64-linux/usr/armv7a/bin/arm-angstrom-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/libexec/gcc/arm-angstrom-linux-gnueabi/4.5.3/lto-wrapper
Target: arm-angstrom-linux-gnueabi
Configured with: /home/tang/Projects/OE/build/tmp/work/armv7a-angstrom-linux-gnueabi/gcc-cross-4.5-r38.1+svnr170880/gcc-4_5-branch/configure --build=x86_64-linux --host=x86_64-linux --target=arm-angstrom-linux-gnueabi --prefix=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a --exec_prefix=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a --bindir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/bin --sbindir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/bin --libexecdir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/libexec --datadir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/share --sysconfdir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/etc --sharedstatedir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/com --localstatedir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/var --libdir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/lib --includedir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/include --oldincludedir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/include --infodir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/share/info --mandir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/share/man --with-libtool-sysroot --enable-largefile --disable-nls --enable-ipv6 --with-gnu-ld --enable-shared --enable-languages=c,c++,objc,fortran --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-angstrom-linux-gnueabi- --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap --with-float=softfp --with-sysroot=/home/tang/Projects/OE/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi --with-build-sysroot=/home/tang/Projects/OE/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi --with-build-time-tools=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/bin --disable-libunwind-exceptions --with-mpfr=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr -with-libelf=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr --with-system-zlib --program-prefix=arm-angstrom-linux-gnueabi- --enable-cxa_atexit
Thread model: posix
gcc version 4.5.3 20110311 (prerelease) (GCC)

comment:10 by Carl Eugen Hoyos, 12 years ago

Where you able to run git bisect to find the change introducing the problem?

comment:11 by kaijun, 12 years ago

Can you give me specific steps? I have run git bisect good or bad with
e1a86d03855f2fb1bf7961efd6794ddd9226f228 was both good and bad

comment:12 by Carl Eugen Hoyos, 12 years ago

I am not sure I understand: You wrote above that c6c2dfcf15c1d93b2189adff6f71c5c4b6b05338 works fine but that e1a86d03855f2fb1bf7961efd6794ddd9226f228 shows the problem you describe.

So you can run:

$ make distclean
$ git bisect start
$ git bisect good c6c2dfcf15c1d93b2189adff6f71c5c4b6b05338
$ git bisect bad e1a86d03855f2fb1bf7961efd6794ddd9226f228
$ ./configure && make

Then test if the problem occurs with the resulting binary or not and repeat the following lines until the responsible commit is found (git bisect good if the problem does not occur, git bisect bad if you can reproduce the issue):

$ make distclean && git bisect good / bad
$ ./configure && make

When you are finished, run

$ make distclean && git bisect reset

to get back to the revision before running the tests.

comment:13 by kaijun, 12 years ago

this issue happens at 0ebcdf5cdad6bf20a5170735a7f77b23ecc081ac where mathematics.h is removed from libavutil/avutil.h. After it is reverted, the issue is gone. I don't know why this would produce the issue.

in reply to:  13 comment:14 by Carl Eugen Hoyos, 12 years ago

Replying to kaijun61:

this issue happens at 0ebcdf5cdad6bf20a5170735a7f77b23ecc081ac where mathematics.h is removed from libavutil/avutil.h.

Given that libavutil/avutil,h does include mathematics.h this does not sound like a very likely explanation:
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/avutil.h;hb=HEAD#l330

The version numbers you used above also look suspicious: Are you sure that you are using a supported, non-broken version of FFmpeg as offered on http://ffmpeg.org/download.html

comment:15 by kaijun, 12 years ago

I need to mention, since ffmpeg is moved libav, I got source codes from libav. I assume both share same source codes. Are they different?

comment:16 by Carl Eugen Hoyos, 12 years ago

I don't think FFmpeg has moved, please test sources from http://ffmpeg.org/download.html and report if you can reproduce your problem.

comment:17 by kaijun, 12 years ago

I find mathematics.h was reverted later on for other reasons.

comment:18 by Carl Eugen Hoyos, 12 years ago

Do I understand you correctly that the issue is not reproducible with FFmpeg?

comment:19 by kaijun, 12 years ago

I feel confused about ffmpeg and libav. Before and including http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a85ce653fb14ae968419453fabf1ffe10d1f15df commit, both repos. look same. But from this snap, I don't see mathematics.h included. But its previous one and one after two commits, i.e. one you want me to look at have mathematics.h. Also after this snap, both libav and ffmpeg have different commits.

in reply to:  19 comment:20 by Carl Eugen Hoyos, 12 years ago

Replying to kaijun61:

I feel confused about ffmpeg and libav. Before and including http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a85ce653fb14ae968419453fabf1ffe10d1f15df commit, both repos. look same.

For several months, there is one (of several) forks of FFmpeg that is known to contain many (>100) regressions over FFmpeg. Since some of those bugs in this fork are possibly security-relevant, we strongly recommend only to use FFmpeg from http://ffmpeg.org (which you can download from the videolan server). The FFmpeg tree also contains the complete history of this fork, but there should be no reason for you to use it, the commit you quote above does come from the mentioned fork, the correct version to test would be 48706f41 (the subsequent commit):
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=48706f41e1a17e04b0aa09852eff021833708233

But from this snap, I don't see mathematics.h included. But its previous one and one after two commits, i.e. one you want me to look at have mathematics.h. Also after this snap, both libav and ffmpeg have different commits.

Can you tell me if you can reproduce the problem you described above with FFmpeg git head (or any released version)?

comment:21 by kaijun, 12 years ago

the issue is not reproducible in head commit.

comment:22 by Carl Eugen Hoyos, 12 years ago

Resolution: invalid
Status: newclosed

Thank you for testing!

Note: See TracTickets for help on using tickets.