Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 ASP

Reply
 
Thread Tools Search this Thread Display Modes
Old 28th November 2007, 20:18   #1  |  Link
BitBasher
Registered User
 
Join Date: Mar 2005
Posts: 14
divx.dll is spewing "Licensestate disabling" messages to stdout

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:
Code:
   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.
BitBasher is offline   Reply With Quote
Old 30th November 2007, 20:55   #2  |  Link
DigitAl56K
Registered User
 
Join Date: Nov 2002
Location: San Diego, CA
Posts: 936
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.

Last edited by DigitAl56K; 30th November 2007 at 20:58.
DigitAl56K is offline   Reply With Quote
Old 30th November 2007, 23:52   #3  |  Link
BitBasher
Registered User
 
Join Date: Mar 2005
Posts: 14
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.
BitBasher is offline   Reply With Quote
Old 1st December 2007, 03:27   #4  |  Link
DigitAl56K
Registered User
 
Join Date: Nov 2002
Location: San Diego, CA
Posts: 936
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.
DigitAl56K is offline   Reply With Quote
Old 2nd December 2007, 16:55   #5  |  Link
BitBasher
Registered User
 
Join Date: Mar 2005
Posts: 14
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.
BitBasher is offline   Reply With Quote
Old 1st April 2008, 01:44   #6  |  Link
DigitAl56K
Registered User
 
Join Date: Nov 2002
Location: San Diego, CA
Posts: 936
Yo Bit,

Try out this beta, see if it works for you:
DivX 6.8.2 Beta 1

- Al
DigitAl56K is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:48.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.