Menu
▾
▴
openquicktime-devel
|
From: Jean-Francois P. <pan...@co...> - 2004-07-06 07:55:49
|
There is code in lib/io_file.c and utils/recover.c to force the use of ftello64() and fseeko64() on platforms which have it to avoid problems seeking on files larger than 2GB. OS X doesn't have ftello64() or fseeko64(), but it does have ftello() and fsseko(). The following changes fix this problem and allow larger than 2GB files to work on OS X. First, test for the presence of fseeko()/ftello() in configure.in: --- configure.in.orig 2004-07-06 00:40:59.000000000 -0700 +++ configure.in 2004-07-06 00:52:33.000000000 -0700 @@ -208,6 +208,7 @@ dnl ------------------- AC_CHECK_FUNCS(ftello64, has_ftello64=yes, has_ftello64=no) +AC_CHECK_FUNCS(ftello fseeko) AH_TEMPLATE([OQT_64SEEK], [Use 64bit versions of ftell and fseek ?]) echo "Support for 64-bit file seeking.......... $has_ftello64" Then make sure to use the right functions in lib/io_files.c and utils/recover.c --- io_file.c.orig 2004-07-06 00:54:33.000000000 -0700 +++ io_file.c 2004-07-06 00:54:43.000000000 -0700 @@ -43,8 +43,16 @@ #define FSEEK(f,o,w) fseeko64((FILE*)f,o,w) #define FOPEN(p,m) fopen64(p,m) #else +#if HAVE_FTELLO +#define FTELL(f) ftello((FILE*)f) +#else #define FTELL(f) ftell((FILE*)f) +#endif +#if HAVE_FSEEKO +#define FSEEK(f,o,w) fseeko((FILE*)f,o,w) +#else #define FSEEK(f,o,w) fseek((FILE*)f,o,w) +#endif #define FOPEN(p,m) fopen(p,m) #endif --- recover.c.orig 2004-07-06 00:55:27.000000000 -0700 +++ recover.c 2004-07-06 00:55:41.000000000 -0700 @@ -49,9 +49,17 @@ #define FTELL(f) ftello64((FILE*)f) #define FSEEK(f,o,w) fseeko64((FILE*)f,o,w) #else +#if HAVE_FTELLO +#define FTELL(f) ftello((FILE*)f) +#else #define FTELL(f) ftell((FILE*)f) +#endif +#if HAVE_FSEEKO +#define FSEEK(f,o,w) fseeko((FILE*)f,o,w) +#else #define FSEEK(f,o,w) fseek((FILE*)f,o,w) #endif +#endif #define SEARCH_FRAGMENT (oqt_uint64_t)0x1000 |
|
From: Jean-Francois P. <pan...@co...> - 2004-07-06 07:49:36
|
In acinclude.m4, there is code to figure out if dlsym() automatically adds an underscore in front of a symbol name on systems where symbols have an underscore prepended to them when an object file is generated. Here is what the code says: dnl ********************* dnl dlsym and Underscores dnl ********************* dnl Check checks whether dlsym (if present) requires a leading underscore. dnl Written by Dan Hagerty <ha...@ai...> for scsh-0.5.0. Unfortunately, this code doesn't work, since it depends on having previously tested for the presence of dlopen and/or whether dlopen lives in libdl, which is not done in configure.in. Thus on OS X, which adds underscores to names in objects but compensates for this in dlsym(), you end up with: /* #undef DLSYM_ADDS_USCORE */ but: #define USCORE 1 in include/openquicktime/config.h when you run ./configure (I know that there's a special macconfig.h in macos, but on OS X 10.3.x, it looks like the generic bootstrap/configure mechanism mostly works without needing special magic). The solution is to add the following tests to configure.in: *** configure.in.orig 2004-07-06 00:40:59.000000000 -0700 --- configure.in 2004-07-06 00:42:31.000000000 -0700 *************** *** 180,185 **** --- 180,187 ---- CFLAGS="$CFLAGS $my_cv_comment" dnl Check to see if dlsym adds an underscore + AC_CHECK_LIB(dl, dlopen) + AC_HAVE_FUNCS(dlopen) MY_DLSYM_USCORE AH_TEMPLATE([USCORE], [Define if symbol tables on this system use leading underscores.]) AH_TEMPLATE([DLSYM_ADDS_USCORE], [Define if dlsym automatically supplies a leading underscore.]) These tests will set the variables ac_cv_func_dlopen and ac_cv_lib_dl_dlopen to the correct values for the platform, and will make the code in MY_DLSYM_USCORE correctly generate the DLSYM_ADDS_USCORE define in config.h With this fix, OpenQuicktime can correctly load codec plugins on OS X 10.3.4. JF |
|
From: Jean-Francois P. <pan...@co...> - 2004-07-06 07:39:02
|
Currently, the mdat atom at the head of a QuickTime file generated by
oqt has a 32 bit size field,
limiting the file size to 4GB. By default, Apple QuickTime uses a 64 bit
mdat atom in case the
file grows larger than 4GB: this only adds 8 bytes to a file and is
probably what you want to do.
Here's a patch for lib/openquicktime.c which does this and seems to work
(there was already support
for 64 bit atoms in the code, but it didn't seem to be used).
JF
--- openquicktime.c.orig 2004-07-06 00:33:33.000000000 -0700
+++ openquicktime.c 2004-07-06 00:33:44.000000000 -0700
@@ -378,7 +378,7 @@
}
// Start the mdat atom
- oqt_atom_write_header(file, &file->mdat.atom, "mdat");
+ oqt_atom_write_header64(file, &file->mdat.atom, "mdat");
return 0; // Success
}
|
|
From: Jean-Francois P. <pan...@co...> - 2004-07-06 07:31:00
|
The following patch to lib/mvhd.c sets the preferred_volume property to
1.0 instead of
0.996094, this seems to better match what is output by QuickTime.
--- mvhd.c.orig 2004-07-06 00:29:03.000000000 -0700
+++ mvhd.c 2004-07-06 00:29:27.000000000 -0700
@@ -38,8 +38,7 @@
mvhd->time_scale = 600;
mvhd->duration = 0;
mvhd->preferred_rate = 1.0;
- mvhd->preferred_volume = 0.996094; //EH ?!
- //mvhd->preferred_volume = 1.0;
+ mvhd->preferred_volume = 1.0;
for(i = 0; i < 10; i++) mvhd->reserved[i] = 0;
oqt_matrix_init(&(mvhd->matrix));
mvhd->preview_time = 0;
JF
|
|
From: Jean-Francois P. <pan...@co...> - 2004-07-06 07:30:13
Attachments:
codec_tga.c.patch
|
When reading TGA media from a QuickTime file, decode_tga() incorrectly validates the width and height of the images read from the file: it only looks at the low byte from the TGA header, so the code only works when reading TGA images smaller than 256x256. The patch attached to this mail should fix this problem. JF |
|
From: Jean-Francois P. <pan...@co...> - 2004-07-05 19:16:43
|
The CVS version of import/oqtimport_dv.c references a non-existant frame
rate, 24.97 FPS (looks like a cut-n-paste typo). I suggest replacing
this with frame rates more likely to occur, 24FPS and 23.976FPS.
JF
--- oqtimport_dv.c.orig 2004-07-05 12:01:02.000000000 -0700
+++ oqtimport_dv.c 2004-07-05 12:14:37.000000000 -0700
@@ -161,7 +161,8 @@
fps = (1.0*decoder->audio->frequency) /
decoder->audio->samples_this_frame;
// round if near to a well known value
if(fabs(fps - 29.97) < 0.01) fps = 29.97;
- else if(fabs(fps - 24.97) < 0.01) fps = 24.97;
+ else if(fabs(fps - 24) < 0.01) fps = 24;
+ else if(fabs(fps - 23.976) < 0.01) fps = 23.976;
else if(fabs(fps - 30) < 0.01) fps = 30;
else if(fabs(fps - 25) < 0.01) fps = 25;
}
|
|
From: Jozef H. <jh...@ho...> - 2004-07-07 15:52:55
|
Hello, Thanks for the fixes! I committed your patches to the CVS. Could some-one provide writable repository access to JF, please? jh -- "There are two major products that come out of Berkeley: LSD and Unix. We don't believe this to be a coincidence." -- Jeremy S. Anderson |
|
From: Stuart E. <st...@3i...> - 2004-07-08 05:01:44
|
Yes, Jean-Francois, email me your SF userid info and I'll add you as a committer to the project :) On 08/07/2004, at 1:52 AM, Jozef Hatala wrote: > Hello, > > Thanks for the fixes! I committed your patches to the CVS. > > Could some-one provide writable repository access to JF, please? > > jh > > -- > "There are two major products that come out of Berkeley: > LSD and Unix. We don't believe this to be a coincidence." > -- Jeremy S. Anderson > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Openquicktime-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openquicktime-devel > > -- 3ivx is pronounced Thrivex Stuart Espey mailto:st...@3i... 3ivx Technologies Pty. Ltd. |
Thanks for helping keep SourceForge clean.
X