2ndMouse

Finally built ExifTool.exe successfully. I did have to go acquire findfile.pm (missing) and put it where it belongs, but after that pp_build_exe.args ran OK. My new exe version is over 12 MB vs 8MB for the distributed version. Are there techniques to reduce the exe size, or perhaps remove unnecessary modules?

Thank you! I'm game...Perl and PAR it is...

Not really an install issue, but I would like to know if the source for producing the standalone version for Windows is available? EXIFTool command line is wonderful, but I have a requirement to demonstrate building all s/w form 3rd parties from source. I appreciate that this might be complex, but I would like to try. Thanks. Dave. -- Complexity is friction. Computers, servers, smartphones, tablets and other network-connected devices began to outnumber human beings, in 2014. Scientific American.

Thanks for that. I will revisit this after I have some clean machines, eliminate cacheing, and try more varieites of video files. Bizarre. On a side note, is there any reason not to mix functions from DirectShow.NET filtertools.cs with my EVR player (MediaFoundations.Net) using DSPlayer.cs? I have used LoadGraphFIle and SaveGraphFile with no trouble in both types of projects, so I guess IFilterGraph is the same in each, but I wonder how far I can go with this. Are there rules to follow, or things...

Ultimately, this problem shows up everywhere! Media Player Classic can also displays this behavior, when EVR is selected Renderer, i.e. the second video takes 5 seconds to load, but the first does not, an neither does the third, fourth. which all open in about half a second. I am moving on to a new machine.... Can anyone else reproduce this phenomenon? Driving me nuts.

Good point. My dev system does have K-Lite installed. I will try that. Thanks.

Thanks for getting back to me. I also built the c++ MF sample, which has problems opening a second file at all. Has no one ever tried to open a second video file in the samples? I initially guessed that the second file load might be slower because the current session had to be torn down, closed, released, etc. before building the next topology. But my timing shows that this cleanup is very fast, and also this does not explain how subsequent files load quickly after the second one. All flavors of...

Properly timed, stopwatch started immediately before call to SetTopology and stopped at beginning of OnTopologyReady handler. First file takes 120 ms roughly, second file takes 5000 ms. Ideas? Fixes?