[Theora-dev] Theora dll in debug mode

Wed Apr 27 06:59:14 PDT 2005

Hi

 --- illiminable <ogg at illiminable.com> a écrit : 
> Hi there,
> 
> Firstly... the runtime error (not initialised), is due to the theora source 
> code. If you look at the project file in my source, it disables all those 
> runtime checks so this shouldn't happen.

If the runtime checks are disabled, why do they appear ?

> Secondly... the crash is likely due to linking to the wrong runtime 
> libraries. You need to link to Multithreaded Debug DLL (in debug mode) or 
> Multi-threaded DLL in release mode. Also remember, if you have compiled the 
> theora dll in debug mode, you have to compile everything that links to it in 
> debug mode. Another thing, my filters never link directly to libtheora.dll, 
> i use libtheora as a static library and it is wrapped inside the 
> libOOTheora.dll.

Yes, I have. All dll listed in my previous email was compiled in debug mode. I
needed to compile them because there are dependencies with their .lib files
(except for libOOOggSeek.dll, I compiled it but there was no dependencies with
theora).

> When you say you downloaded the theora source to compile yourself, do you 
> mean the source to libtheora, or the source i have on my website (which 
> contains a custom version of libtheora)... if you compiled libtheora 
> yourself, from something other than what was in my package, you likely have 
> a lot of incorrect settings. Is there a reason why you can't use the version 
> that is provided ?

They are the source on your website :
http://www.illiminable.com/ogg/oggcodecs_src_0.69.8924.zip

The provided version works fine out of the application I develop. I can encode
and decode files. But this application (a videoconference application) uses
some non-standard DirectShow filters with currently another codec. And we want
change the codec to Theora. The application works correctly with the current
codec, but crashes with Theora. I can't be more precise, because the only error
message I get is "access violation". Debugger isn't able to show me the file
source wich faulted, nor the dll.
The asm code with has faulted is :
cmp [esi+$10], ebp

$10 in Delphi langauge is an equivalent to 0x10 in C language. Registers esi
and ebp are both 0, that explains the access violation. But nobody understand
what's happened.

For this reason we need debug version of the theora dll in order to check if
the codec is the problem.

> Also, i assume you know that to build it needs the BaseClasses library from 
> the directX9 sdk. You have to change some settings in this project, so it 
> links with __stdcall, uses Multithreaded Debug Dll (or MultiThreaded DLL for 
> release) and builds as a static library.

Yes, I know ;)

> Another thing... there are several other static libraries that are linked to 
> those libraries you list.

Whenever the compilation failed (starting with dsfEncoderFilter and
dsfDecoderFilter) because it needed a .lib file, I compiled the project wich
provided those libraries.

> If you are using the code provided, you should just be able to toggle the 
> setting to "Debug" at the top of visual studio, rebuild the "oggcodecs" 
> project, and that will build all the dependancies. As far as i'm aware, all 
> the correct runtime/warning ignore settings are set such that the runtime 
> error should not occur.

So, I only need to compile "oggdsf\build\oggcodecs\oggcodecs.vdproj" ?
I haven't understand, I was compiling files separately.
For example
"oggdsf\src\lib\codecs\theora\filters\dsfTheoraEncoder.dsfTheoraEncoder.vcproj".
When compilation failed because of depenencies, I compiled other files to
obtain requested .lib and .dll.

Ok I am going to try this.

> Another thing... you can't just rebuild and start using them... directshow 
> filters are COM objects... all filters need to be properly registered on the 
> system, which also means deregistering any existing ones first.

Yes I know.
However, this is a particular case. Release version and Debug version of these
files have the same CLSID and GUID, because there have both the same source
code. They have also the same name. So, no modifications need to occur in the
registry file. Isn't this correct ?

> One other thing to be aware of... the filters haven't been all that well 
> tested in real-time conditions... it's entirely possible the encoder is too 
> slow for the amount of data you are throwing at it. I just did a brief test, 
> not with a live source but using a file source run into a theora encoder 
> then into a theora decoder then to a video renderer, and that configuration 
> works ok.

I will test that, because I work on a videoconference application. I need to
compress at very low bitrate as 64000.
If you are interested, I will tell you if the codec well support real-time
compression.

> If you have anything of any substantial resolution and framerate, the 
> encoder just isn't fast enough to cope with that yet. And there is no built 
> in throttling/frame dropping mechanism, so it will just eventually back up 
> with unencoded frames and die.

Frame Droping is one one the non-standard DirectShow filter the application
uses. I will compress only small video from a webcam capture, as 176x144.
Theora seems supporting it in real-time.

> One other thing, i assume you know that using Multithreaded DLL or 
> MultiThreaded Debug DLL means you need to put the appropriate runtime dlls 
> in the same directory ? ie mscvp71.dll and msvcr71.dll

No I didn't ! Thanks.
But I have simply replace relase version of the dll by the debug version, so
mscvp71.dll and msvcr71.dll are already in the installation directory of the
codecs.

I am going to compile the the codec once more time with your indications.

Seb

__________________________________________________________________ 
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/