On Wed, Jun 29, 2005 at 09:45:51PM +0200, Vegard|drageV wrote:
> Avidemux works fine with smaller movies (typically 700MB), but gives
> an errormessage in the commandwindow:
>
> Images stat:___________Max memory consumed (MB) : 0
> Current memory consumed (MB) : 0
> Max image used : 0
> Cur image used : 0
> #0 0x407330f4 in g_on_error_stack_trace () from /usr/lib/libglib-2.0.so.0
> #1 0x0809e9c7 in sig_segfault_handler ()
> #2 0x40e06825 in __pthread_sighandler () from /lib/libpthread.so.0
> #3 <signal handler called>
> #4 0x0836003e in _3GPHeader::buildIndex ()
> ...
> #25 0x08360f46 in adm_atom::read32 ()
I do not have the foggiest as to how Avidemux is implemented, but this
read32() remotely sounds like there might be a problem with "large file
support" (LFS). Absence of the latter means that either the system
calls or program-internal variables use 32-bit long ints to represent
sizes and file offsets.
IOW, in this case, maximal file size is 2^31 = 2147483647 ~ 2GB...
Can't tell you exactly what to do to solve the problem (if that _is_
the problem at all), but adding those keywords "large file support" to
your google searches _might_ steer you in the right direction... :)
Maybe you can recompile the app with some configure option enabling
LFS. As a last resort, messing with the sources itself might also
be an option (in theory), though that's likely to get a little too
involved...[1]
Can't be more precise, sorry.
Almut
[1] typically, it would mean adding two defines at the top of the source,
before including header files (or passing them as -D options to gcc):
#define _LARGEFILE_SOURCE
#define _FILE_OFFSET_BITS 64
but depending on how the rest of the code is written, this doesn't
necessarily guarantee anything...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
