Saturday, December 31, 2005
Some more 1.2 progress
A progress report on v1.2. It is pretty close to being done, I think, and could use some more testing before I let it go.
Here's an updated version of the changelog so far:
v1.2:
- Aspect ratio is now displayed as a fraction. IE, 4:3 instead of 1.333(...). It checks fractions with denominators up to 100.
- Added support for command line options/switches.
- Updated usage info.
- Added support for SMP (HyperThreading, dual core, dual processor) for the actual encoding via -smp switch.
- iPodDrop now targets the iPod screen rather than TV by default. Still maintains correct aspect ratio.
- Added new switch, -tv, that uses OLD default behaviour and tries to max out res.
- Added better handling of content with aspect ratios less than 4:3 (such as 1:1). iPodDrop now stretches them to 4:3 under the assumption that they are probably SVCD or some other such format.
- Added new switch, -allowtall, that allows aspect ratios less than 4:3 to remain unchanged.
- Bugfix to better handle relative paths in Windows
- Added logging. iPodDrop now logs how long it took to encode each file to encodes.txt in the log directory.
As you can see, there is some new stuff since the last post. v1.2 has turned into a rather large update compared to v1.1, and I'm pretty happy with it.
To respond to Avery's post (I'm not ignoring his changes in v1.2, just trying to avoid feature creep):
Right-click menus are definately a good idea. I'll try to slot them in for v1.3 or something. Probably I'll set them up the first time the program is run, and when I get an installer I can have it done there. The problem with this approach, of course, is that I have to specify filetypes to show the menu for. Since my app is an interface for ffmpeg, I don't really know what formats it supports. Certainly I can add all the common ones.
I've been thinking about a GUI for a while now. Originally I was trying to get this thing in a workable state as fast as possible, and for that, console was the way to go. However, the program DOES keep getting more and more sophisticated. I'd like to think that I've been influenced by NITI's autonomic background when I decided to make this program try to figure out the best default behaviors for everything. Most applications don't do anything without setting up many command-line switches, and the default behavior isn't very useful. iPodDrop tries to do as much as possible with no user input (beyond providing the filename), and if a user doesn't like the default behavior, THEN the switches allow them to tweak that.
But I'm getting off on a tangent again. GUIs. I don't really want to go the full GUI route quite yet. iPodDrop is actually my second media encoding app. The one I wrote about shortly after the iPod came out fizzled. I went too complex too fast without any planning (not that iPodDrop has much planning beyond features-planned-for-next-release) leading to a huge amount of work before the app could really do anything at all. (iPodDrop actually got a huge shortcut in the beginning by borrowing a bunch of functions from my old app, allowing a faster start). GUIs are a lot more work than a console app, so I have been avoiding writing a GUI.
There are two plans I've been formulating. The first involves what is printed to the console itself. I intend to simplify the console output by capturing all the FFMPEG output, and parsing it to produce a (text-based) progress bar and ETA. The program would still not be a GUI app, but would be much more friendly.
The second is sort of a launcher. A small GUI shell that calls iPodDrop. Perhaps it is kind of silly to write a front-end for a front-end, but the idea is to provide a standard Windows file browser dialog, possibly allowing dragging into the window too, and a few checkboxes/radio buttons that just set the command-line switches.
Even writing the frontend for iPodDrop, you'd still see the iPodDrop console after you hit "go", but the progress bar would be in the console window already. This is somewhat of a hybrid solution, but might be good enough.
An eventual possibility would be to take the whole shebang and convert it into a full GUI app. See, the beauty of going with the GUI shell first is that you can make iPodDrop a GUI app by shoving its code into the shell itself and doing something else where you normally do "Console.WriteLine()". Provide some sort of feedback where the console output used to be (Labels? Message boxes? Depends on context), turn the progress bar into a GUI element, and boom.
Right now it looks like what is likely to go into 1.3 is explorer context menus, and the hide-ffmpeg-and-show-progress-bar bit. The installer is still a possibility, and the GUI shell might make it in. Depends how long it takes to do the progress bar bit. My old GUI encoder had the progress bar and ETAs working with ffmpeg, but it was a bitch to do and was prone to crashing. Luckily iPodDrop waits for ffmpeg to finish while in a tight loop (Albeit with a sleep command so that it only loops a few times a second), which would make the progress bar a LOT easier.
You know what? I am afraid that one day if iPodDrop is in more general circulation, I'll be bombarded with questions better directed to the ffmpeg team. Hiding away ffmpeg's output to reduce complexity will only exacerbate that.
Damn it. Another long post when all I intended to do was post the changelog.
Here's an updated version of the changelog so far:
v1.2:
- Aspect ratio is now displayed as a fraction. IE, 4:3 instead of 1.333(...). It checks fractions with denominators up to 100.
- Added support for command line options/switches.
- Updated usage info.
- Added support for SMP (HyperThreading, dual core, dual processor) for the actual encoding via -smp switch.
- iPodDrop now targets the iPod screen rather than TV by default. Still maintains correct aspect ratio.
- Added new switch, -tv, that uses OLD default behaviour and tries to max out res.
- Added better handling of content with aspect ratios less than 4:3 (such as 1:1). iPodDrop now stretches them to 4:3 under the assumption that they are probably SVCD or some other such format.
- Added new switch, -allowtall, that allows aspect ratios less than 4:3 to remain unchanged.
- Bugfix to better handle relative paths in Windows
- Added logging. iPodDrop now logs how long it took to encode each file to encodes.txt in the log directory.
As you can see, there is some new stuff since the last post. v1.2 has turned into a rather large update compared to v1.1, and I'm pretty happy with it.
To respond to Avery's post (I'm not ignoring his changes in v1.2, just trying to avoid feature creep):
Right-click menus are definately a good idea. I'll try to slot them in for v1.3 or something. Probably I'll set them up the first time the program is run, and when I get an installer I can have it done there. The problem with this approach, of course, is that I have to specify filetypes to show the menu for. Since my app is an interface for ffmpeg, I don't really know what formats it supports. Certainly I can add all the common ones.
I've been thinking about a GUI for a while now. Originally I was trying to get this thing in a workable state as fast as possible, and for that, console was the way to go. However, the program DOES keep getting more and more sophisticated. I'd like to think that I've been influenced by NITI's autonomic background when I decided to make this program try to figure out the best default behaviors for everything. Most applications don't do anything without setting up many command-line switches, and the default behavior isn't very useful. iPodDrop tries to do as much as possible with no user input (beyond providing the filename), and if a user doesn't like the default behavior, THEN the switches allow them to tweak that.
But I'm getting off on a tangent again. GUIs. I don't really want to go the full GUI route quite yet. iPodDrop is actually my second media encoding app. The one I wrote about shortly after the iPod came out fizzled. I went too complex too fast without any planning (not that iPodDrop has much planning beyond features-planned-for-next-release) leading to a huge amount of work before the app could really do anything at all. (iPodDrop actually got a huge shortcut in the beginning by borrowing a bunch of functions from my old app, allowing a faster start). GUIs are a lot more work than a console app, so I have been avoiding writing a GUI.
There are two plans I've been formulating. The first involves what is printed to the console itself. I intend to simplify the console output by capturing all the FFMPEG output, and parsing it to produce a (text-based) progress bar and ETA. The program would still not be a GUI app, but would be much more friendly.
The second is sort of a launcher. A small GUI shell that calls iPodDrop. Perhaps it is kind of silly to write a front-end for a front-end, but the idea is to provide a standard Windows file browser dialog, possibly allowing dragging into the window too, and a few checkboxes/radio buttons that just set the command-line switches.
Even writing the frontend for iPodDrop, you'd still see the iPodDrop console after you hit "go", but the progress bar would be in the console window already. This is somewhat of a hybrid solution, but might be good enough.
An eventual possibility would be to take the whole shebang and convert it into a full GUI app. See, the beauty of going with the GUI shell first is that you can make iPodDrop a GUI app by shoving its code into the shell itself and doing something else where you normally do "Console.WriteLine()". Provide some sort of feedback where the console output used to be (Labels? Message boxes? Depends on context), turn the progress bar into a GUI element, and boom.
Right now it looks like what is likely to go into 1.3 is explorer context menus, and the hide-ffmpeg-and-show-progress-bar bit. The installer is still a possibility, and the GUI shell might make it in. Depends how long it takes to do the progress bar bit. My old GUI encoder had the progress bar and ETAs working with ffmpeg, but it was a bitch to do and was prone to crashing. Luckily iPodDrop waits for ffmpeg to finish while in a tight loop (Albeit with a sleep command so that it only loops a few times a second), which would make the progress bar a LOT easier.
You know what? I am afraid that one day if iPodDrop is in more general circulation, I'll be bombarded with questions better directed to the ffmpeg team. Hiding away ffmpeg's output to reduce complexity will only exacerbate that.
Damn it. Another long post when all I intended to do was post the changelog.
