|
The multi-thread
change I started updating GSpot two years ago, after the last release. The first order of business was to make MPEG info more accurate. With AVI files I can get frame count & hence duration, etc from the header. I still went “into” the data to get the more esoteric info like QPEL & GMC, but there was no need to read the entire file. By contrast, streaming formats like MPEG have no such header. When adding MPEG support in beta 2.5x, I wanted to keep GSpot as fast as it was when it only supported AVI files - basically instantaneous – rather than reading entire, potentially multi-gigabyte files. So I “cleverly” derived that information by reading the beginning and the end only, and then subtracted various embedded timestamps. But for various reasons, the methodology described above lacked accuracy in certain situations. And sometimes the errors were significant. I came up with an idea of starting a second “thread” to solve the problem. This other thread of execution continues to read and parse the entire file, updating the GUI “on the fly”- even as the initial data is displayed immediately. During this time GSpot remains fully functional in every regard, maintaining its the responsive “look and feel”. There are no progress bars or “salt timers”. In fact, if the user isn’t specifically interested in the final version of those particular fields of info, he or she is permitted to move on to other menu items or even start examining a completely new file at any time. The fields which are updating are highlighted in a darker yellow, indicating the info is not final. When the file is completely read and the information shown is thus “finalized”, the background color returns to normal. Of course for smaller to medium files you may never even notice any of this, as the code was optimized to run as fast as possible. The above mechanism is now incorporated in GSpot 2.6x, so MPEG info should be much more accurate. It also runs the thread for MPEG in AVI (e.g. DivX), but isn’t finished yet for other formats which would also benefit. Indeed, this preliminary version has very partial support for certain formats where you may even see the duration & frame count absent altogether. This is being worked on now.
But that distraction that
led to.... Once I was already examining every frame, I became interested in displaying technical things which are often settable in encoders but not easily “determinable” afterwards. Originally this was just things like “percentage of B-frames”, max consecutive B-frames, max and average keyframe distance, “GOP structure” and more. I delved into that deeper and deeper and eventually created what is really an entirely separate “sub-program”, called “VGS” (“Visual GOP structure”), which is a separate dialog accessible via a small button (included in this version). The VGS dialog gives more detail, much of it extremely technical, than probably almost anyone needs to know. But it does so in a completely graphical fashion, and will probably be of interest to many just because it’s interesting to “glance at”, even without understanding everything. I won’t go into that more here, but there are some screenshots, and, unlike most of the rest of GSpot, this "subsystem" actually has a modest series of “help” screens to aid in understanding it.
And then that distraction led to... After many months of working on that “graphical” subsection, I became “OD’d” on GSpot programming and got distracted doing some other graphics related programming. That led to delays of six months or more, and I thus never released a version with the work I had done because there were so many other things “on the platter”, many of them started but not complete. These ranged from the very technical down to basic issues like support for additional file formats. Not to mention existing bugs and many excellent requests I’ve received by email and elsewhere. I basically had gone off in too many different directions at once that I never really finished any of them So GSpot just kinda sat around...
The final delay Even as I finally got back to working on it, there was another long (nine month) delay due to a medical condition1.
Finally, back to work... But I pulled all that code back out of “storage” a few months ago, and spent several weeks on some things I considered important, most importantly the handling of video formats that had become popular in the interim, e.g. various types of “MP4” structure files and “FLV” (the latter, in particular, has actually become extremely popular due to the proliferation of sites like “youtube.com” which deliver videos via FLASH. It bothered me personally that I couldn’t even find out the most basic information (size, framerate, etc.) about these files. So the current version contains a support for variety of new containers and embedded audio and video types, which I won’t go into here. Note, however, that in some cases the info is currently limited; display of the remaining info is still under development. GSpot still has no support for common Windows Media (.wmv), RealAudio (.ra) or QuickTime (.mov) nor for the open source Matroska containers or Ogg related media formats. Each format takes a while to add, as I write code to parse each of them myself rather than relying on any built-in Microsoft API’s, installed codecs or third party libs or source. That’s an important design criterion since one of its functions is to identify problems when those things are absent. But these things are all in the works. Meanwhile, it is able to parse info from raw DV (as well as DV in AVI, type 1 or 2) as well as AAC, AC3, DTS, H.263, M4A, 3GP/3G2, MPEG-4AVC / H.264, FLV and others - often when embedded in unexpected containers, or, alternatively, in unexpectedly “raw” form. Note that many files, including the basic unsupported mediatypes mentioned above, are at least identified as to what they are, so you know what you’re dealing with , even if it’s misnamed. GSpot never relies on a file extension for any purpose whatsoever, for exactly that reason. The identification routine supports many non-media formats too, so if you inadvertently receive an AVI inside a ZIP but misnamed with an .avi extension, you’ll immediately realize what the problem is.
And I haven’t
forgotten... I’ve been discussing and adding a lot of technical details about files being examined, but I haven’t lost sight of the fact that in all probability, the great majority of users download GSpot for the simple question “why won’t this file play”, and want a short answer in non-technical terms. The question has gotten more complicated as tie goes on (some files require a replacement of the ineptly written Microsoft AVI-splitter with a third party one, and some are best (or only) played with a more “intelligent” player MPC or one like MPlayer or VLC that completely bypass the use DirectShow / VFW codecs altogether. In fact, if you’re reading this document and having problems (or even if you’re not) and can’t wait for the next update, I’d strongly recommend that you just install VLC media player (free from http://www.videolan.org/vlc/). It will directly play almost anything you throw at it, including poorly supported formats like FLV (without the use of a dedicated FLV player). I am not affiliated with the VLC player in any capacity - that’s just my two cents on a quick solution to a lot of problems. Steve G 30 August 2006
Prequel... If you've read this far, I'll answer a question I often get asked: "Where did the name GSpot come from"?. The answer is kinda funny, insofar as the name came first and then the app (I may never have written the app had it not been for the name!)
Four or five years ago, I was bothered by the fact (I'm sure along with many others) that Windows Media Player would refuse to play some files with no indication of "why" - i.e. as to what codec you needed. When I finally ran across a webpage on the subject one day, it suggested loading the entire binary media file into "WordPad" and looking for a four letter code (the "4cc"). As a programmer, it seemed absurd to me that such a solution would be suggested when it would be so easy to write an app to acess this "4cc" directly. I was posting on a message forum at the time, under the rather unimaginative nick "Steve G". And there was already a program called EncSpot which identified audio encoders. Somewhere along the line the idea came up that I could write such a program for video and call it "GSpot". The idea was funny enough that I actually did it. That version 1.0 didn't do much else at the time, but the rest, as they say, is history... |