I'm using libjpeg (C/C++ programming on Windows Mobile 6.5), in order to decode images from an IP camera (sent in a MJPEG stream), before pushing them into a DirectShow graph.

Until now, I've been using a single function for : receiving the stream, parsing it manually (in order to find JPEG data starting- and end-point), decoding the data (i.e. initializing the libjpeg structures, reading the JPEG header, doing the actual decoding...) and finally pushing it into the graph. This works properly, but in order to make things smoother and tidier, i'd like to use a function for receiving, that calls another function (later, a thread) for decoding/pushing.

So, as a first step, instead of doing all the JPEG work right after finding the data in the stream, I simply call another function which is in charge of the JPEG structures init / header reading / decoding / pushing.

And this is where I get an error I can't decipher : "improper call to jpeg library in state 205".

I'm realizing I've omitted quite a lot of information in my original post. Here are some (maybe) useful details :

I'm using VS2008, but for many reasons I don't use the built-in debugger or emulators. Instead, the exe file is directly deployed and tested on the Windows Mobile device, using a custom dos-like command prompt.

libjpeg originally reads from and writes to files, but I'm using a patch (and custom error handler) enabling to read data directly from a buffer, without opening a file. Code can be found here, and it uses an "extended error handler" defined this way :

Also, i you can, avoid setjmp() and longjmp(). They are good if you really, really need them and a pain otherwise.
–
Prof. FalkenOct 25 '10 at 11:33

Thanks for the advice. I'm going to try using the lib without it. I must admit I'm using a sample from IJG's libjpeg, where setjmp() is used without clear explanation...
–
BlueCookieOct 25 '10 at 11:53

1

You can't avoid them in IJG, because its error reporting function is not meant to return : printf("ERROR\n"); abort(1); , and the caller don't expect a return from it. So returning from it normally will completely f*#$ up the rest of the program flow.
–
ruslikOct 25 '10 at 12:54

Interesting library, IJG. Very uncommon pattern for a library. Why did they do it like this?
–
Prof. FalkenOct 26 '10 at 7:19

Maybe it's a stupid question, but : Would it be possible to use IJG's lib without this heavy error handling ?
–
BlueCookieOct 26 '10 at 13:15

2 Answers
2

205 is 0xCD, that is the standard value put by VS in debug mode in unitialized memory, so I think that your cinfo was not initialized properly at the moment you've called the decoder. Post the code when you use it.

Also, the setjump() you're using make me think it's IJG library. Be careful with it because it's not a standard function. It remembers the exact state of the thread and stack when you've made the call and is able to return to that position from anywhere, except cases when this state is not valid anymore, as in:

Yes, it's the IJG library. I'll look deeper into these things and post when I have any news, thanks a lot !
–
BlueCookieOct 25 '10 at 10:22

Just edited the original post. I don't think I'm trying to call setjmp() and longjmp() from different functions/threads. (Not being a C or CRT expert, this problem is quite confusing...)
–
BlueCookieOct 25 '10 at 13:39

Thanks for the hint about cinfo - even if the problem persisted later on, it was the actual answer.
–
BlueCookieOct 27 '10 at 9:23

Found the answer to my problem, partly thanks to ruslik. Turns out that I was indeed badly initializing cinfo and jerr between the two functions.

But when I corrected this point, I still had the "state 205" error and thought it was at the same place. Digging in my logs, I found the error message to be issued later in the code execution, and caused by problems with function pointers. My own ugly mistake...

These are the function pointers in the jpeg_source_mgr struct, yes? I've just had a problem where I got the same Improper call to JPEG library in state 205 error because I failed to properly populate those pointers.
–
njahnkeMar 2 '14 at 1:18