Fooling Around

FFDShow is already known for it issues (including for example mentioned one). Today’s featured one is related to its Video Decoder. A great deal of FFDShow related issues amy be worked around with a single shot by listing the image name as an FFDShow exclusion under registry:

HKEY_CURRENT_USER\Software\GNU\ffdshow; blacklist

but I felt relaxed and the problem re-occurred from Windows service where HKEY_CURRENT_USER was not available/applicable.

FFDShow Video Decoder registration looks like:

It is immediately clear that the filter registered with extremely (and definitely unreasonably, breaking guidelines) high merit in conjunction with generic video media type will be taken as a possible decoder in every single graph rendered. At the very least, this is a perofrmance issue, similar to frequently reported like this recent one: How to reduce time during pin connection on vista ultimate using RenderStream function…?.

However the real problem was that the filter was accepting connection on my source pin and pretending it could be a valid decoder instead my own one (definitely registered with a proper merit of 0×00800000 (MERIT_PREFERRED). Did it actually decode? No, just sent blackness on the output… It seems that it is getting a good manner to distance from this crapware by implementing IAMGraphBuilderCallback interface on the graph builder site and reject consideration of FFDShow A/V Decoders as candidates.

I was recently at an autosport event under the aegis of FIA, where I leased my Magellan eXplorist 600 Europe unit to be used in the off-road race/baja (or “rally raid”) as a helper navigation device (the primary navigation for pilots is their roadmap in a hard paper version). Immediately before the rally the organizer was loading the track into pilot’s GPS and for the Magellan GPS owner it has always been an additional headache. First of all, most GPS units are Windows Mobile based or Garmins. Magellan is a rare bird and it was not the first time when they were just unable to load a track into it. I don’t even mention USB cable, which is buggy enough that only the device owner (who is also an advanced PC user) can make it work from time to time. Loading to SD card is also a problem.

However it would be the only problem if Magellan would provide satisfactory software. I used to make a few tools myself for frequent tasks and track log conversion is among them. But I am also using MapSend Lite to visualise tracklogs on map, correct, modify tracks etc. Earlier and this time again I had a problem loading a track into MapSend Lite for ridiculous reason. Once loaded most of the track points disappear.

Disappointment was the feeling to say the least. I am making software myself: codecs, performance, sophisticated format conversions, bugfixes and workarounds, maintaning version compatibility, third party components and stuff - all this myself. And from this point of view I don’t see any rocket science in getting damn track log loaded into map management software. Still the reality is that track log points disappear just because… they have the same timestamp. I had to manually add .01 to each timestamp in text editor to make the track log file valid for Magellan software! Maybe it is not quite correct that points don’t have valid time, I can understand this, but still this is the track and longitude and lattitude differ from point to point so why the hell software from leading vendor would drop points that have duplicate time - I could not accept any justification for this. With a $600 worth GPS device I would expect this be handled more adequately in software.

I would also wish eXplorist could follow track while recording a new one but frankly after disappearing points thing I can see that it is too much to ask from Magellan, basically it is the impossible. I am afraid there is no way I am going to have another piece of hardware from Magellan ever soon.

Yesterday I received a complaint from a Most Important Customer about a weird problem on a few of their digital video recording servers. The problem was that a new version of software, client part, would out of a sudden auto-close without any notice. The problem was quite persistent and basically of not a difficult kind because such fatal problems are automatically logged with a descriptive enough log to identify the cause in an extremely effective way. However the log files appeared to be empty. Another unexpected part was that a few systems showed the issue while the other did not and software worked in a quite expected and stable way there.

After a couple of phone calls and setting up remote access using TightVNC and port forwarding I could see this myself and it was obvious that there is an exception, such as memory access vioaltion, which takes place however on a thread created outside of my code and runnning without a proper guarding section to at the very least catch the exception and log its call stack. The visual symptoms led to supposition that it is something DirectShow related and chances are high that it is either a hardware acceleration issue, or a software compatibility issue. Luckily, hardware acceleration assumption is easy to eliminate by switching off, letting it run without and seeing if there is any difference. There was not.

Then it appeared that while these system were close to clean installation state, there was another DVR software installed also, to be used for tasks not covered by our software. And my first guess was if it installed certain DriectShow filter of the crappy kind, which could interfere with our award winning software, the best of the best. A quick test of renaming “C:\Program Files\Another-DVR” into a different name making all contained binaries unopenable by path showed that nothing changed essentially. So it was GraphEdit, which was downloaded there and a list of installed filters was insepected visually.

There were a few filters that was present in the system but which were obviously installed additionally to the system, as a part of Another-DVR product or in a different way. There was a few filters by I. and then my look stumbled on something which I immediately thought of “That’s It!”. Well, taking into consideration time spent on the problem it was rather “That’s Fucking It!”.

A rename of the hosting file pvmjpg21.dll in %WINDIR%\system32 immediately fixed the problem! Oo-omm-m “PICVideo MJPEG Decompressor” by Pegasus Imaging Corporation, crap! It was one of those moments sung of by Fort Minor:

This is twenty percent crap, eighty percent lame
And a hundred percent reason to remember the name!

However, let us what was going on there. A quick look at the registration information makes it clear the video decoding bastard registered itself under MERIT_PREFERRED (0×00800000) merit and generic MEDIATYPE_Video/MEDIASUBTYPE_NULL media type. Why on earth a properly made codec would claim to be able to decode any video as prefered software? It obviously adds overhead to the entire DirectShow subworld on that system by poking its pin into anything that moves without a proper luck to actually connect.

However, it would be just an overhead, maybe even unnoticable, if the bastard was a thread safe library. But it was unfortunately not. Since my software starts showing multiple video feeds simultaneously, this piece of junk was simultaneously instantiated in multiple threads and just crashed the entire process.

P.S. Bonus: “pvmjpg21.dll crash” on Google

Can there be any justification for a completely custom GUI replacing standard caption, buttons etc. and imitating Vista look on Windows XP? Vista look, but with unusual custom controls and still with a jerky Windows 3.11 style font (see prompt for installation path below).

I was about to write that unlike previous versions of Nokia PC Suite, this one at least does the very first thing it is expected to do… but nope, it crashed on… viewing contacts! And it crashes every time soon after contacts browsing is opened!

OK, this might be a “little glitch”, but the Suite is still losing USB cable connections just like it has been doing for a long long time, even when it did not yet have Vista look…

How many Windows processes is necessary for this type of application? I left Bluetooth and Infrared disabled as unneeded. Service context: ServiceLayer.exe which started NclMSBTSrv.exe, NclUSBSrv.exe, NclRSSrv.exe (thanks, because there is 4 more .exes in this Transports subdirectory); Desktop: PCSuite.exe and an application for any major task: ContentCopier.exe, ConnectionManager.exe, CommunicationCentre.exe. It makes an impression I have installed another operating system on top of Windows. I never thought that communication with a cellular phone might be such complex task, which requires so many applications started.

Nokia’s service is “ServiceLayer”, display name “ServiceLayer”, service description is missing…

How did they come to this software design? To implement custom look and feel, fully customized GUI and just not provide any descriptive name for the service, which is by the way starting automatically (well, service startup is Manual, but user applications auto-start by default and would start the service) and keeps bloating system even when the Suite is not being used.

I wonder what was the reason to change and basically disable well known behavior on multipart/x-mixed-replace MIME type with the release of FireFox 3? It never worked with Internet Explorer but it has been working with Mozilla Netscape through FireFox 2. Why the hell this was to be changed?

GET /cgi-bin/zzz HTTP/1.1
Host: xxx:yyy
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 200 OK
Server: GoAhead-Webs
Pragma: no-cache
Cache-Control: no-cache
Content-Type: multipart/x-mixed-replace;boundary=myboundary

--myboundary
Content-type:image/jpeg
DaemonId:0x00360003

No longer I can check server push M-JPEG streams using FireFox, supposedly there is a configuration tweak to bring well known behavior back.

A customer complained that he was unable to get things working with Y-Cam Black camera. Naming models using colors is already a sign that problems are inevitable. The camera either had old firmware and implemented a different protocol (other than documented) or the documentation sucked but I would like to mention a different thing.

I was impressed that the camera did not accept HTTP authentication from FireFox. Sure it claims to be RFC 2616 (Hypertext Transfer Protocol — HTTP/1.1) compliant, it would get insulted being suspected in not abiding it by, but still the fact: open camera URL from Internet Explorer and you get authorized after a propmt for a password and a valid entry. Open it using FireFox and you will be kept prompted for the password infinitely. No firmware updates available free, one should be requested by email. People are seriously releasing and selling such a crappy stuff.

There is a demo camera, a different model however (White) http://guest:guest@y-cam.dtdns.net:8152/, it is free from this issue.

I am whining about software/firmware only, if you need a comprehensive review on the camera, you can find it on networkwebcams.co.uk/blog.

Continue Reading »