divx.dll is spewing "Licensestate disabling" messages to stdout

[BitBasher]

I have a console app (not a win32 app) that processes AVI files. I am trying to get the name of the video decompressor, using code similar to this:
HIC hIC = ICOpen( ICTYPE_VIDEO, VideoStreamInfo.fccHandler, /*ICMODE_DECOMPRESS*/ICMODE_QUERY );
if ( hIC )
{
ICINFO ICI;
if ( ICGetInfo(hIC,&ICI,sizeof(ICI)) >= sizeof(ICI) )
WideCharToMultiByte( GetConsoleOutputCP(), 0, ICI.szDescription, -1, szVideoCodec, sizeof(szVideoCodec), NULL, NULL );
ICClose( hIC );
}
Note that ICOpen works with either ICMODE_DECOMPRESS or ICMODE_QUERY.

Now here's the rub. During the call to ICGetInfo(), stdout get a SPEW of about 50 to 70 lines saying:
Licensestate disabling

My fccHandler is "divx" so this code would be talking to the DIVX decompressor.

I assume that most programs wouldn't see this cuz they're windows apps and typically stdout writes get tossed into the bit bucket.

After a bit of investigating I can see the string "Licensestate %sabling" in divx.dll memory, and the display of this seems to be related to an internal string, "enable_feedback".

I need a way to control the divx.dll so it does NOT spew debugging information to stdout - especially since divx.dll is a retail release - it shouldn't be writing ANYTHING to stdout.

Is there a way (registry setting, API call, etc) for me to get divx to stop writing to stdout?

Is this a bug in DIVX 6.7 (that's the one I'm using)? I think the default should be for it to NOT write to stdout.

Thanks very much!
Bit.

[DigitAl56K]

Try registering DivX Pro and see what happens. It sounds like it's related to the code that turns off the feedback window in the community codec (vs the Pro codec).

It's not possible for me to commit to this behavior changing, but I would suggest that you can probably work around the issue using freopen() to temporarily redirect stdout to an alternative FILE* during affected calls.

[BitBasher]

Thanks for the reply, DigitAl56K!

I actually have the Divx PRO codec - registered and everything - but the machine I'm doing testing on just uses the community codec (because that system get's rebuilt a LOT and the divx registration doesn't survive a system rebuild).

I'll try running the app on systems that have the registered codec and see if that helps.

Thanks for the tip on freopen() - I'll give that a shot and see if it works!

Bit.

[DigitAl56K]

Glad to help.

Unless you're doing disk operations that change a ton of data on the system that you're testing on (i.e. Ghost/TrueImage/Defragging), I recommend Rollback RX. You can roll the entire system back to an earlier state in just seconds, and it also only takes seconds to make a new snapshot. Works with Vista, too.

You could then make a clean image, snapshot it, put divx on and register it, snapshot it again.

You now have the option to rollback to the moment you registered DivX and the system was otherwise clean at any time. Snapshots take almost no disk space.

[BitBasher]

Hi DigitAl56K,

Thanks for the great suggestions!

Unfortunately, it appears that the freopen() solution does not allow us to reliably get back the original stdout handle. Some research indicates that there is no portable way of doing this, and there's no portable way to get the filename of stdout (if it was redirected).

The current solution we have decided to implement is that we'll check if fccHandler == 'divx' and if so we'll printf out a warning stating to ignore licensestate messages as they are debug messages from the divx codec - not our app. It's not a pretty solution but we can't add "hacks" to our code to fix another apps "bugs" (enabled debugging messages on a retail release).

I know you can't commit to a fix, but can it least be added to the divx "bug list" for a future release of divx that the codec should NOT be writing ANYTHING to stdout EVER? If there's a chance that future versions of divx can have this fix, then we can document that if someone sees the licensestate messages that they can try to get a newer version of the divx codec.

Thanks,
Bit.

[DigitAl56K]

Yo Bit,

Try out this beta, see if it works for you:
DivX 6.8.2 Beta 1 (http://labs.divx.com/node/4904)

- Al