Opened 5 years ago

Closed 5 years ago

#872 closed defect (invalid)

av_rescale_q returns wrong 64bits in arm cortex-a8 processor

Reported by: kaijun61 Owned by: michael
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 Changed 5 years ago by michael

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 Changed 5 years ago by kaijun61

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

comment:3 Changed 5 years ago by michael

That sounds like a compiler bug

comment:4 Changed 5 years ago by kaijun61

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 Changed 5 years ago by cehoyos

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

comment:6 Changed 5 years ago by cehoyos

Which compiler are you using?

comment:7 Changed 5 years ago by kaijun61

angstrom

comment:8 Changed 5 years ago by cehoyos

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 Changed 5 years ago by kaijun61

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 Changed 5 years ago by cehoyos

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

comment:11 Changed 5 years ago by kaijun61

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

comment:12 Changed 5 years ago by cehoyos

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 follow-up: Changed 5 years ago by kaijun61

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.

comment:14 in reply to: ↑ 13 Changed 5 years ago by cehoyos

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 Changed 5 years ago by kaijun61

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 Changed 5 years ago by cehoyos

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 Changed 5 years ago by kaijun61

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

comment:18 Changed 5 years ago by cehoyos

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

comment:19 follow-up: Changed 5 years ago by 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. 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.

comment:20 in reply to: ↑ 19 Changed 5 years ago by cehoyos

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 Changed 5 years ago by kaijun61

the issue is not reproducible in head commit.

comment:22 Changed 5 years ago by cehoyos

  • Resolution set to invalid
  • Status changed from new to closed

Thank you for testing!

Note: See TracTickets for help on using tickets.