| Blog |
|
| Releases |
Page:
0 ... 5 ... 10 ... 15 ... 20 22 23 24 25 26 27 28 29 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80
| DVB → Mp4 | |
|---|---|
|
Date: 2/9/2008 | For a long time I've had a private stock app that manages encoding DVB mpeg2 to whatever compressed video format is in fashion. Which at the moment is H.264.
So anyway recently I started pushing HD through it and well it did not like that at all. Basically after much head scratching I worked out that avisynth, which serves up frames to x264 was "guessing" the length of the input mpeg2 file, or more correctly, one of the filters in it's direct show graph was doing the guess. Unfortunately, because Avisynth has to report an exact length of it's AVI at startup it means that the video stream is only ever as long as Avisynth's "guess". This is unacceptable, and there is only one route around this, and that is not to use direct show (i.e. DirectShowSource). So the option is using Mpeg2source filter plugin (oh no yet another dependency!). And that relies on an indexer to produce d2v indexes of the mpeg2 first. So now my graph looks like this: 
This is a graphical editor for video processing blocks that I've been working on. Essentially the current system is a hardcoded version of this, but when I'm done, all the same functionality will be plug and play, probably with some scripting support as well. This week I did finally get my mpeg parsing library up to snuff so that it can dump out all the meta data for a mpeg video stream (not PS/TS, just video at this stage) which is a good step forward. At the moment the mpeg2demux stage runs Pvastrumento which is the best error correcting demuxer available. However I'm about halfway to having a demuxer myself, and I suspect that I can create something that can compete with the error correcting capabilities of Pvastrumento and probably produce a d2v file in the process. So that would greatly simplify the whole diagram and get rid of that ungainly d2v indexing step. Eventually I'll build up a library of components and graphs to handle the vast majority of media re-encoding needs and possibly release it as an application. |
| (0) Comments | Add Comment | |
| Imap Design | |
|---|---|
|
Date: 29/8/2008 | I've been working on the IMAP code for v2 a bit and thought I'd post an architecture diagram. Just for fun.
This how email gets from the server to the screen in the current dev build of Scribe v2. I had to write a new FETCH implementation in the IMAP class because the existing methods were too restrictive. Basically I'm moving more towards an API that maps far more directly to the protocol, exposing more power to the calling code. The new FETCH code parses the response on the fly and when it has a whole record, calls a callback method with the fields in a hash table. It's a lot faster and more flexible than the old code. So, reading mail works. Now just to add moving, deleting and mail change notification. |
| (1) Comment | Add Comment | |
| Translating Script Menu Names | |
|---|---|
|
Date: 13/8/2008 | Well I've finally settled on a solution to the translation of scripting menu commands. The new scripting support in Scribe v2 uses the new bytecode VM and I've extended the API to include a wrapper around LgiLoadString which is what Scribe uses natively to load strings from the lr8 resource file. So the script can use that to load it's translated name straight from the source. However that doesn't get it on a menu. So the new scripting engine runs each script in "./Scripts" on startup and the main function of each script calls "AddToolsMenuItem" which is a new function that registers a callback connected to a menu item in the tools menu. i.e.
AddToolsMenuItem(LoadString(IDS_REMOVE_DUPES), "DeleteDuplicateMessages");So you can see that the text of the menu will be translated and the 2nd parameter to that function is the name of the callback method to call when the user clicks the menu item. All in all it's very neat. There is another tricky part in the define "IDS_REMOVE_DUPES" is in a C header file. So originally I just copied the integer value that it mapped to as a literal into the script file. But I decided that it would break too easily and so I made the script engine cope with C style #include and #define so that I can just include the resource defines straight into the script and then use the actual name of the string. Neat. Previously, Previously. |
| (7) Comments | Add Comment | |
| Deleting Scribe v2.00 Plugins | |
|---|---|
|
Date: 8/8/2008 | I'm seriously considering deleting the whole plugin feature from v2.x of Scribe and replacing it completely with the scripting engine. For the most part the plugins are fragile because of their dependency on C++ ABI's not changing. Also they tend to be a little bit of glue between the application and some 3rd party tool or library. This should ideally be handled by a script so that the ABI dependency goes away and the functionality is "open source" allowing the user to tweak it to their own preferences.
This will mean that the scripting language will have to support calling into the operating system and shared libraries (DLL's). I think I can make the basic part of that work ok. I'm a lil worried about more complex types not being represented in the scripting language. Currently it's limited to a range of basic types, string, int, list etc governed by the types support by the Lgi GVariant class. Maybe it needs to a custom data type, and I have some idea on how that might work. But at this stage I'm working on making the script engine cope with registering hooks and callbacks so that it can take over the functionality of the existing plugins. See how far I get. |
| (0) Comments | Add Comment | |
| Scribe: Stuff to delete and clean up for v2 | |
|---|---|
|
Date: 28/7/2008 | I've been inspired to clean out some cruft for Scribe v2 so that the UI and design is clean and easy to understand. The things that are going to be cut so far are:
Which are all fairly tame I think. However there is one change that I'm considering thats a little risky. And that is the default location for settings and folders. Currently the default is in the same folder as the application install. Which works for single user Windows quite well. But it's been several years since Scribe has run on Linux and Mac OS X and well things just don't work that way on unix based operating systems. Their main concept is that the app sits in a central location and saves all it's user specific data somewhere in the user's home directory. A definate separation of application and data, and in Linux enforced with permissions so that users can't modify the application. Modern Windows applications follow the same model as well, the app sits in the Program Files hierarchy and the data is saved in the user's Application Data folder. By default I think Scribe should move to this model. However Scribe has prided itself in being able to by portable so I'm considering making the install ask the user for a "desktop" install or a "portable" install and locate the settings and folders appropriately. That way people get the best of both worlds. There are some edge cases that will need smoothing over but I think it'll work in theory. Backup/Copy: the user can no longer assume that operating on the app's folder will backup, copy or move their settings and email. So I will probably make some sort of menu for doing that manually. Maybe in the form of converting between desktop and portable storage post install. I'll probably get a fair bit of feedback about that in the next few v2 builds. What else needs to be cut from v2? |
| (3) Comments | Add Comment | |
| The Reinstall | |
|---|---|
|
Date: 27/7/2008 | So every 2-3 years I have to reinstall windows. It's part of life. This week it's my turn to face the dreaded reinstall to get XP running on a new faster HD with way more space. Anyway the install went something like this:
Of course it's not good is it. TV out doesn't work. Here we go. I have painful memories of getting this working last time.
|
| (0) Comments | Add Comment | |