This only happens on AMD64: After saving a project with avidemux and loading it again, all movie segments start at the beginning of their file (i.e. the lines "Start: ..." in the saved project file always have the same effect as "Start: 0"). This was reproducible in all versions of avidemux which I tried (which were many up to the current 2.0.42-r1). With the currently masked 2.1_pre1, I did not try, because it already crashed when saving a project. Reproducible: Always Steps to Reproduce: 1. Edit some avi-movie, copying some segment starting from the middle of the movie to some other place. 2. Save the current project. 3. Load the project again. Actual Results: The copied segment starts from the beginning of the movie. Expected Results: The copied segment should start from the middle of the movie. Since the saved information is apparently correct, the bug must happen during the loading of the project. Moreover, in the x86 chroot the problem does not occur. System uname: 2.6.11-hardened-r15 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.13 ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-fPIC -march=athlon64 -O2 -O3 -pipe" CHOST="x86_64-pc-linux-gnu" CXXFLAGS="-fPIC -march=athlon64 -O2 -O3 -pipe" FEATURES="autoconfig ccache collission-protect distlocks sandbox sfperms strict userpriv usersandbox" LANG="de_DE" LDFLAGS="-Wl,-O,1,-z,now" MAKEOPTS="-j2" USE="amd64 16bit 7zip S3TC X a52 aac aalib acl acpi adsl alsa amarok aotuv apache2 arts async athena atlas auctex audiofile avi ax25 bash-completion bcmath berkdb bigpatch bindist bitmap-fonts bl blas bmp browserplugin bzip2 cap caps ccache cdda cdio cdparanoia cdr cdrom cg chasen checkpath chipcard crypt css curl curlwrappers custom-cflags dga dio dnd double-precision dpms dri dts dv dvd dvdr dvdread ecc edl emacs emul-linux-x86 encode escreen esd eurofile exif experimental extras fam fame fat fbcon fbsplash festival ffmpeg flac fmod fortran gatos gd gdbm gif gimp gimpprint ginac gkrellm glade glgd glibc glibc-compat20 glibc-omitfp glitz glut glx gmail gmailtimestamps gmp gmtsuppl gmttria gpm gs gsm gtk gtk2 gzip hardenedphp hbci id3 idea ieee1394 image imagemagick imap imlib imlib2 irda jack jasper java jbig jce jp2 jpeg jpeg2k kde kdeenablefinal lame latex libsamplerate libtommath libwww lirc live logitech-mouse logrotate lzo lzw lzw-tiff mad math matroska maya-shaderlibrary mbox md5sum mikmod mime mimencode mixer mjpeg mng mode-force mode-paranoid motif mozilla moznocompose moznoirc moznoxft mp3 mp4live mpeg mpeg2 mpeg4 mplayer mupad-noscilab musepack music mythtv nas ncurses nls no-old-linux no_wxgtk1 noamazon nocardbus nocd noflagstrip nowin nvidia octave offensive ogg oggvorbis ogre on-the-fly-crypt openal openexr opengl oss pcntl pcre pdflib perl pic player plotutils png pnp pop portaudio posix print python qt quicktime rar readline real realms recode reiserfs remix rogue scanner scp screen sdl slang smime sndfile sox speex spell sse-filters ssl stats stream subp subtitles svg svgz symlink sysfs szip tabs tcltk tcpmd5 tetex theora thumbnail tiff timidity tomsfastmath transcode unicode usb userlocales utf8 uudeview v4l v4l2 vcd vcdimager videos vlm voice vorbis wmf wxwindows xanim xatrix xgetdefault xine xlockrc xml2 xmms xosd xpm xrandr xscreensaver xv xvid xvmc zlib zvbi userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LINGUAS
Created attachment 97047 [details, diff] Patch to fix the scanf/fscanf calls Since there are no new avidemux versions in the portage tree for a long time now, I decided to repair the old "current" version: <=avidemux-2.0.42 is not nearly 64-bit clean: It uses scanf/fscanf and printf/fprintf with "%ul" and passes only a (pointer to an) uint32 object (similar things happen also for other arguments). In the appended patch, I corrected the (about 20) scanf/fscanf calls, but without any automatism, I will not repair the several hundred printf/fprintf calls (does somebody know of a script which simply casts printf/fprintf arguments into the right form when the first argument is a constant string?). However, for amd64 the printf/fprintf calls seem to work anyway, probably due to the fact that function parameters are passsed in registers and not on the stack (which would allocate the wrong size), but this is just a guess and not really tested (for certain parameter combinations or too many parameters the printf calls might probably fail anyway). Anyway, the attached patch of scanf/fscanf fixes at least the reported problem, so on 64-Bit machines, avidemux will certainly work better with this patch than without it, but I wouldn't rely too much an the full functionality on AMD64 (although I observed no further problems so far, but I am using only very few of the functionality of avidemux).
Could you test w/ the ebuild from Bug 150175? Doesn't make sense to hack outdated versions that are completely unsupported upstream IMHO.
Created attachment 102303 [details, diff] scanf-fixes (for e.g. 64bit) for avidemux-2.3_preview2 Yes, of course: This was only a temporary hack until the upstream version is in the gentoo tree. avidemux-2.3 uses a completely different mechanism to save projects (it uses spidermonkey), so it is not surprising that the described effect does not occur anymore. However, when looking through the source code, I still found some suspicious scanf calls although upstreams seems to have fixed most of them. I attach some quick-and-dirty hacks which presumable fixes the one I found for avidemux-2.3_preview2.
Martin, whats the status with 2.3.0?
It is the same as with avidemux-2.3_preview2: The above patch applies (with only one small offset difference) which means that the upstream code is not fixed yet. In fact, I had reported it upstream but had received no reply.
(In reply to comment #5) > It is the same as with avidemux-2.3_preview2: The above patch applies (with > only one small offset difference) which means that the upstream code is not > fixed yet. In fact, I had reported it upstream but had received no reply. > yes, were not using previe2, were using 2.3.0 now. :)
I don't understand why this is marked as "need info" now; I hope that I am not the reason. Maybe my previous posting was unclear: Concerning this bug there is no difference beetween 2.3_preview2 and 2.3.0. The same patch works (with only one offset difference). I do not know whether the patch for 2.3* is just of a cosmetical nature, or whether really something will go wrong without it (as was the case with 2.0.42), but I am rather sure that it cannot hurt and fixes *potential* bugs.
