-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm pleased to announce the availability of opusfile v0.4. The opusfile and opusurl libraries provide a high-level API for decoding and seeking within .opus files on disk or over http(s). * https://ftp.mozilla.org/pub/mozilla.org/opus/opusfile-0.4.tar.gz * https://ftp.mozilla.org/pub/mozilla.org/opus/opusfile-0.4.zip * http://downloads.xiph.org/releases/opus/opusfile-0.4.tar.gz * http://downloads.xiph.org/releases/opus/opusfile-0.4.zip * https://ftp.mozilla.org/pub/mozilla.org/opus/win32/opusfile-0.4-win32.zip Changes since v0.3: - - New API to parse album art tags. - - Visual Studio project file fixes. - - Include Visual Studio projects in source package. - - Minor unicode fixes. Changes since v0.2: - - Fix a buffer overflow downmixing multichannel files. - - UTF-8 filename support on Windows. - - HTTP(S) url support on Windows. - - Support Windows system certificate store for HTTPS. - - New project files for MS Visual Studio. - - New gain control API with op_set_gain_offset() and op_get_track_gain(). - - Documentation and build improvements. - - HTTP(S) support split into a separate opusurl library. - - Implement soft-clip for paths where libopus doesn't. - - opusfile_example now outputs WAV. - - Fix http basic auth. - - Fix 255 packet-per-page assert. We recommend upgrading for all current users. If you're not a current user, please give it a try! Checksums: 4248927f2c4e316ea5b84fb02bd100bfec8fa4624a6910d77f0af7f0c6cb8baa opusfile-0.3.tar.gz 9836ea11706c44f36de92c4c9b1248e03a4c521e7fb2cff18a0cb4f8b0e79140 opusfile-0.4.tar.gz f187906b1b35f7f0d7de6a759b4aab512a9279d23adb35d8009e7e33bd6a922a opusfile-0.4.zip ae23da5963295c6aa13c97becf50ae013e2317706f0e2a9472f2384aa70aaa43 opusfile-0.4-win32.zip We didn't announce v0.3 separately because the Visual Studio project files were one of the major new features...but we forgot to include them in the source package. Thanks to everyone who contributed! -r -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSE+v3AAoJEEcAD3uxRB3vJMoH/1ZciZWEdWPTevoqo/zfHyPu FDrohLby9tH0LgdbIFDtHwxnfbyVFRkwYd9b1XPwDgecdCWSVImOPeF7H59umIB/ ZrFL+EYZvhsSj2dTihDlPHkdORz1dRW3cKWbuc+xL+op4XJ/+TrzCdhsKKSKQPU6 dyxZquLcaZ41QIpyWjJ3e5mGDyhsfvAgRB6XKWfhk7fcxD1hCbcXqLkMZAwUL35q M1b6VP1R8NfA50Gs1wYX843Zj3ZH0mGg02gEkXePLeQhBGtWw455jLsMBg9+7BD0 +OCAZeZVMVq/l7PqaquIb3AhK03DP1Rm7lNi++3G2A2/eKgjgndnpXRd33Ij9aU=jUQS -----END PGP SIGNATURE-----
I've developed the unofficial Opus codec support plugin for Winamp and I have been able to keep the libopusfile libraries inside a folder inside the application's install path - "%PROGRAMFILES%\WinampNarf\opusfile" - and all seemed to be fine and dandy. However, if I try to load the new libopusurl-0.dll from the same folder as I have always done as with the other libraries, I get a NULL HMODULE handle from LoadLibraryW and GetLastError() return error code 126 - "The specified module could not be found." I then redid my code to load the libraries from the same folder as the application executable instead and it loaded this time. I'm assuming that "libopusurl-0.dll is looking for its supporting DLL's from the exe path instead of it's own. Can this be fixed? tia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20130820/6e00c528/attachment.htm
alpha thinktink wrote:> Can this be fixed?I'm not sure I fully understand the problem. Can you make a simple testcase that demonstrates it (i.e., a dummy project that works and one that doesn't).
On 20/08/13 08:38 PM, alpha thinktink wrote:> However, if I try to load the new libopusurl-0.dll from the same folder > as I have always done as with the other libraries, I get a NULL HMODULE > handle from LoadLibraryW and GetLastError() return error code 126 - "The > specified module could not be found."In addition to what Tim said, do you get the same error loading libopusfile-0.dll, or is it just libopusurl? Could it be an ordering problem? -r
On 13-08-21 12:35 AM, alpha thinktink wrote:> I just had a thought and tested it out and it seemed correct. By > loading the libeay32.dll and ssleay32.dll libraries myself before > loading libopusurl-0.dll then libopusurl-0.dll loads and I can use it. > Before I was just trying to load libopusurl-0.dll without loading its > support DLLs at all assuming it would pick them up on it's own.I don't know anything about this, but msdn says the default search path is the directory containing the processes' executable file, so this isn't completely surprising, even though it's unfortunate. Are you using SetDllDirectory to tell it to load the plugin's dependencies from the plugin directory, or just giving a relative path? Does it fail to auto-load the openssl dependencies in both of those cases? -r