Friday, December 30, 2005
News on v1.2 of iPodDrop
EDIT: This post is WAY longer than I intended it to be. I'm tempted to just say "That was why scroll wheels were invented" when it comes to the amount of space this is going to take up on planit, but then that would be rude :P If anybody knows how I can do a "sanity barrier" type thing with Blogger where it only shows part of the blog post on planit and the rest via a link, let me know in the comments. And comment on the app while you're at it ;)
I know I said last post that it would probably be a long while before a v1.2 ever arrived, but, well, something came up and now I've been busy working on v1.2.
I remembered that one of my buddies actually bought a 60GB iPod with Video. So I suggested to him that he try my app. Problem is, while my app is designed to max out the res to play back on a TV, he didn't have the cables, and only wanted to watch stuff on the screen.
Well, I made him a custom hacked up build of v1.1 that encoded to 320x240 (changing the 240 based on aspect ratio, so 16:9 content would give 320x180 video). Also hardcoded ffmpeg to start up with 2 threads to take advantage of HyperThreading on his CPU.
It worked great. He's using it, and reports that not only is my app encoding 3x faster than the convert that the rest of the world seems to use (Videora iPod Converter, and this is odd because both my app and Videora use ffmpeg, albeit different builds compiled by different people), but my app also properly handles non-four-by-three aspect ratios (like 16:9). Videora just stretches everything to 4:3, ruining widescreen content, while my app properly calculates the correct res (The iPod can do letterboxing by itself).
Well, that hacked up build was working for him. Problem is, he had a suggestion. He wanted iPodDrop to keep a log file of what it was encoding, and how long it took. That seemed like it was something that would do well to be in my mainline build, but I didn't want to keep having to hack him up a custom version over and over again. My solution? Integrate optional support for the changes to his version into the mainline version ;)
The end result is that in the upcoming v1.2, you can enable SMP support with a commandline switch (Uses 2 threads to take advantage of HyperThreading, dual core, or dual procs), and you can tell the app to target an iPod screen rather than a TV screen.
I actually will probably make the iPod screen target the default behavior, since this feature now makes my app suitable not just for myself and the few others who use the iPod on a TV, but EVERYBODY who plays video on their iPod. The minority like myself can use a commandline switch to target a TV instead. The switches still work with shortcuts, so you can have switches and still drag and drop.
Here is the current-to-date changelog for v1.2, pretty much what I've described above:
- 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.
- Added ability to output for iPod screen resolution instead of TV resolution.
As you can see, I fixed aspect ratios while I was at it. I was tired of seeing stuff like 2.2222222222222222222222. Now that shows up as 20:9 like it should.
Other changes I'm thinking about for v1.2 are the log file suggestion, and also changing how the app treats content that is less wide than 4:3. Like 1:1. My guess is that 1:1 content is probably going to be 480x480 or 480x576, which would be SVCD res. And when you decode SVCD content, you squish it down to 480x360 for display (Like anamorphic content, sort of). The actual display isn't 1:1, it is just stored like that. So I think that if a ratio that is less wide than 4:3 is detected, the app should just squish that down to 4:3. I'd also provide an option to leave the ratio untouched, in case you somehow manage to get such content (I have a 480x480 video file that for some reason really is 1:1 for display).
I have to be careful about such options, because if you add special case options like that, you start destroying the point of the application, the ability to drag and drop (even onto shortcuts). I think that in this case, though, the default handling is more correct, and the switch would be available just in case you have very rare content, so that you can type out the command by hand (Or have a shortcut already handy?).
Anyhow, I haven't received any comments on any of my past blog posts about iPodDrop, so I'm assuming that nobody downloaded it. That means that my buddy Dan is now my first official regular user, which is quite exciting for an app that I originally wrote to be super simple for myself :) I'm truly surprised at how crappy Videora is, considering how most of the rest of the world seems to be doing. My app is super simple an doesn't have a fancy GUI, and yet it is still somehow faster, more correct, and easier than Videora. Maybe I should do up a website and try to spread the word some. Maybe somebody else might find the app handy.
To talk a bit about the point about this having started to be so simple... The first version of the app was something on the order of 125 or 150 lines. It did exactly what I wanted it to do. But then I noticed some areas that could use some improvement, and so version 1.1 clocked in at about 175 lines (lots more rewriting than new stuff). And now here I am with a partially completed beta 2, and it is up to 275 lines already. Most of it seems to be dedicated to the new handling of command line arguments, since I need to handle commandline switches now. This program is rapidly growing way beyond what I intended for it, and I'm sort of proud of how that happened. It is almost like my little program is growing up. Lots of the original internal simplicity is giving way to more complex logic to deal with situations that I wouldn't normally run in to, but somebody else might. I've tried to keep it simple on the outside, though ;)
If you have any suggestions for v1.2 or later, drop it in the comments, I'd be interested to hear what other people think about this little app. Oh, and sorry for the long post about a version that isn't even out yet, I'm just rather pleased with how much more useful v1.2 is than v1.1 already :)
I know I said last post that it would probably be a long while before a v1.2 ever arrived, but, well, something came up and now I've been busy working on v1.2.
I remembered that one of my buddies actually bought a 60GB iPod with Video. So I suggested to him that he try my app. Problem is, while my app is designed to max out the res to play back on a TV, he didn't have the cables, and only wanted to watch stuff on the screen.
Well, I made him a custom hacked up build of v1.1 that encoded to 320x240 (changing the 240 based on aspect ratio, so 16:9 content would give 320x180 video). Also hardcoded ffmpeg to start up with 2 threads to take advantage of HyperThreading on his CPU.
It worked great. He's using it, and reports that not only is my app encoding 3x faster than the convert that the rest of the world seems to use (Videora iPod Converter, and this is odd because both my app and Videora use ffmpeg, albeit different builds compiled by different people), but my app also properly handles non-four-by-three aspect ratios (like 16:9). Videora just stretches everything to 4:3, ruining widescreen content, while my app properly calculates the correct res (The iPod can do letterboxing by itself).
Well, that hacked up build was working for him. Problem is, he had a suggestion. He wanted iPodDrop to keep a log file of what it was encoding, and how long it took. That seemed like it was something that would do well to be in my mainline build, but I didn't want to keep having to hack him up a custom version over and over again. My solution? Integrate optional support for the changes to his version into the mainline version ;)
The end result is that in the upcoming v1.2, you can enable SMP support with a commandline switch (Uses 2 threads to take advantage of HyperThreading, dual core, or dual procs), and you can tell the app to target an iPod screen rather than a TV screen.
I actually will probably make the iPod screen target the default behavior, since this feature now makes my app suitable not just for myself and the few others who use the iPod on a TV, but EVERYBODY who plays video on their iPod. The minority like myself can use a commandline switch to target a TV instead. The switches still work with shortcuts, so you can have switches and still drag and drop.
Here is the current-to-date changelog for v1.2, pretty much what I've described above:
- 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.
- Added ability to output for iPod screen resolution instead of TV resolution.
As you can see, I fixed aspect ratios while I was at it. I was tired of seeing stuff like 2.2222222222222222222222. Now that shows up as 20:9 like it should.
Other changes I'm thinking about for v1.2 are the log file suggestion, and also changing how the app treats content that is less wide than 4:3. Like 1:1. My guess is that 1:1 content is probably going to be 480x480 or 480x576, which would be SVCD res. And when you decode SVCD content, you squish it down to 480x360 for display (Like anamorphic content, sort of). The actual display isn't 1:1, it is just stored like that. So I think that if a ratio that is less wide than 4:3 is detected, the app should just squish that down to 4:3. I'd also provide an option to leave the ratio untouched, in case you somehow manage to get such content (I have a 480x480 video file that for some reason really is 1:1 for display).
I have to be careful about such options, because if you add special case options like that, you start destroying the point of the application, the ability to drag and drop (even onto shortcuts). I think that in this case, though, the default handling is more correct, and the switch would be available just in case you have very rare content, so that you can type out the command by hand (Or have a shortcut already handy?).
Anyhow, I haven't received any comments on any of my past blog posts about iPodDrop, so I'm assuming that nobody downloaded it. That means that my buddy Dan is now my first official regular user, which is quite exciting for an app that I originally wrote to be super simple for myself :) I'm truly surprised at how crappy Videora is, considering how most of the rest of the world seems to be doing. My app is super simple an doesn't have a fancy GUI, and yet it is still somehow faster, more correct, and easier than Videora. Maybe I should do up a website and try to spread the word some. Maybe somebody else might find the app handy.
To talk a bit about the point about this having started to be so simple... The first version of the app was something on the order of 125 or 150 lines. It did exactly what I wanted it to do. But then I noticed some areas that could use some improvement, and so version 1.1 clocked in at about 175 lines (lots more rewriting than new stuff). And now here I am with a partially completed beta 2, and it is up to 275 lines already. Most of it seems to be dedicated to the new handling of command line arguments, since I need to handle commandline switches now. This program is rapidly growing way beyond what I intended for it, and I'm sort of proud of how that happened. It is almost like my little program is growing up. Lots of the original internal simplicity is giving way to more complex logic to deal with situations that I wouldn't normally run in to, but somebody else might. I've tried to keep it simple on the outside, though ;)
If you have any suggestions for v1.2 or later, drop it in the comments, I'd be interested to hear what other people think about this little app. Oh, and sorry for the long post about a version that isn't even out yet, I'm just rather pleased with how much more useful v1.2 is than v1.1 already :)
Comments:
<< Home
Yep, it was released in a later post:
http://teknews.net/~guspaz/iPodDrop_v1_2.zip
The readme could probably use some work, so just leave a comment if you have any trouble, and I'll get back to you.
The next version, 1.3 (which is half finished), also has some nifty additions. So far, in the already-complete category, I've replaced ffmpeg's output with a text-based progress bar and an estimated-time-remaining counter. It might just be a cosmetic change, but it is way nicer than the raw ffmpeg output.
One word of warning about the SMP support: I don't have a hyperthreaded or multicore/processor machine, so I can't really test it. Brief stopwatch tests with a test build on a friend's hyperthreaded box showed a small speed boost, but the timing wasn't precise enough to confirm. Now that v1.2 features logging of how long the encode took, I'm going to have him run some more benchmarks.
http://teknews.net/~guspaz/iPodDrop_v1_2.zip
The readme could probably use some work, so just leave a comment if you have any trouble, and I'll get back to you.
The next version, 1.3 (which is half finished), also has some nifty additions. So far, in the already-complete category, I've replaced ffmpeg's output with a text-based progress bar and an estimated-time-remaining counter. It might just be a cosmetic change, but it is way nicer than the raw ffmpeg output.
One word of warning about the SMP support: I don't have a hyperthreaded or multicore/processor machine, so I can't really test it. Brief stopwatch tests with a test build on a friend's hyperthreaded box showed a small speed boost, but the timing wasn't precise enough to confirm. Now that v1.2 features logging of how long the encode took, I'm going to have him run some more benchmarks.
Hey! After searching how to keep the 16:9 ratio for videora, I stumbled upon your site and your program! I can't wait to try it out! Thanks for doing this btw, you're a life saver (since I would've seriously done something if I couldn't fix the damn resolution problem as well as the tracking problem videoar seems to have)
It shouldn't have any problem maintaining the 16:9 aspect ratio. Keep in mind that iPodDrop uses the same backend encoder (ffmpeg) as Videora does. Videora and iPodDrop use very different versionsof ffmpeg though, so who knows if a problem in videora will show up in iPodDrop. I hope not ;)
Thanks for the work on this app. However, I stumbled across a problem(?): a 16:9 (letterboxed) VOB file was identified as having an aspect ratio of 3:2. Using -tv (and -smp) the
produced file ended up being
586 x 390, 2.07mbits/sec, AAC 48Khz Stereo. iTunes refused to copy it to the iPod (5th gen). Also viewing the file in Quicktime reflected the 3:2 aspect ratio (seemed squished). Again, thanks and looking forward to your reply.
produced file ended up being
586 x 390, 2.07mbits/sec, AAC 48Khz Stereo. iTunes refused to copy it to the iPod (5th gen). Also viewing the file in Quicktime reflected the 3:2 aspect ratio (seemed squished). Again, thanks and looking forward to your reply.
Thanks for your feedback.
Firstly, a reminder that v1.3 of iPodDrop was released quite a while ago. It makes it a lot easier to me if you post your comments in the newest post about iPodDrop, currently here:
http://guspaz.blogspot.com/2006/02/ipoddrop-v13-released.html
As for your problem, I'm taking a look. At first glance, the aspect ratio doesn't seem to be an issue. NTSC DVDs are encoded at 720x480, which is indeed 3:2 aspect ratio. The letterboxing is done with the black borders encoded into the video. It is possible that you have an anamorphic DVD. This is where they purposfully take a 16:9 video (or other widescreen video), and encode it in 3:2. Then when it is played back, they scale it back to the original aspect ratio. This is is done to take advantage of the extra resolution normally use up by the black bars.
Unfortunately, I'm not aware of any way for me to detect anamorphic content with current methods, and I don't have any anamorphic DVDs to test with. And I'm not even sure if this is your problem. However, the fact that your video isn't accepted by iTunes IS a big problem, and I'm going to look into that with a test DVD of my own. If I can reproduce the problem and figure out what is going on, I'll throw out a tiny upgrade to v1.4 to fix the issue (Maybe I'll throw in a new commandline switch to try to manually handle anamorphic content, but without anything to test it with...)
I'm in the middle of exam week, so I'm a bit pressed for time, but I'll look into the issue.
It may be more efficient to contact me directly, at guspaz.gmail@com (Reverse the . and the @)
Post a Comment
Firstly, a reminder that v1.3 of iPodDrop was released quite a while ago. It makes it a lot easier to me if you post your comments in the newest post about iPodDrop, currently here:
http://guspaz.blogspot.com/2006/02/ipoddrop-v13-released.html
As for your problem, I'm taking a look. At first glance, the aspect ratio doesn't seem to be an issue. NTSC DVDs are encoded at 720x480, which is indeed 3:2 aspect ratio. The letterboxing is done with the black borders encoded into the video. It is possible that you have an anamorphic DVD. This is where they purposfully take a 16:9 video (or other widescreen video), and encode it in 3:2. Then when it is played back, they scale it back to the original aspect ratio. This is is done to take advantage of the extra resolution normally use up by the black bars.
Unfortunately, I'm not aware of any way for me to detect anamorphic content with current methods, and I don't have any anamorphic DVDs to test with. And I'm not even sure if this is your problem. However, the fact that your video isn't accepted by iTunes IS a big problem, and I'm going to look into that with a test DVD of my own. If I can reproduce the problem and figure out what is going on, I'll throw out a tiny upgrade to v1.4 to fix the issue (Maybe I'll throw in a new commandline switch to try to manually handle anamorphic content, but without anything to test it with...)
I'm in the middle of exam week, so I'm a bit pressed for time, but I'll look into the issue.
It may be more efficient to contact me directly, at guspaz.gmail@com (Reverse the . and the @)
<< Home