Resizing anamorphic images

HandBrake for Mac support
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Post Reply
Posts: 2
Joined: Thu May 24, 2007 2:04 pm

Resizing anamorphic images

Post by smst » Thu May 24, 2007 2:37 pm

I've recently started using HandBrakeCLI on a linux box to encode TV shows from DVDs, and I find it to be excellent: vastly simpler than wading through a GUI, and produces working output (unlike the Windows tools I was previously using). But I'm sure you all get tired of hearing how great HB is. :)

I have a question about resizing (rescaling?) and anamorphic images. I'm not sure that what I want to do is supported, but I may well be misguided in wanting to do it in the first place.

I've just finished encoding a season of Seinfeld episodes, for which the aspect ratio was 4:3. I had no need to keep the full resolution (my eyes can't tell the difference on this material if I lower it somewhat), and resized the video to make a considerable saving on disk space -- 21 minute episodes clocking in (at '-q 0.5') in the region of 150MB, give or take 20MB depending on the video and the number of audio tracks.

I resized by using '-Y 432' (=maxHeight), which gave me 576x432 output. I used the '-p' flag too, but I didn't try encoding without it so I don't know if I wasted encoding time there, or would otherwise have been better off if I'd omitted it. Didn't really know what I was doing!

That all seemed to come out fine, so I've moved on to Arrested Development, which is 16:9. (Running HandBrakeCLI with '-t 0' reports that it's 720x576 on disc, with an aspect ration of 1.78:1.) This time the resizing did not go so well, due to my improper understanding, I thnk.

'-Y 432' gave me a horizontally stretched image, so I tried using '-l 432 -w 768'. With '-p' I still store a 720x576 image (according to mplayer, which also tells me it detects a 1.78:1 aspect ratio); without it I seem to store 768x432. But of course, looking at how close those numbers are, I'm not making any saving on pixels and I may as well not resize: the files still come out much bigger than desired. I thought that it might be possible to resize to, say, 540x432 (same x-y ratio of 1.25:1 as 720x576) and continue using wider pixels... but I can't work out how to do that, or if it's feasible.

So I'm in a bit of a confused state now, and am willing to challenge my assumptions too!

1. Am I being silly to resize the video to save on bitrate (and hence disk space)? Using the full original resolution seems to double the file size from what I've got now, in my 4:3 material. I had assumed that lowering '-q at the original size would lead to a worse picture in higher resolution.

2. What's the difference between -l and -Y? Should either be used with or without -w and -X respectively?

3. Can I use wider pixels in a 540x432 (say) video to end up with a displayed picture in 16:9? Or do I relinquish that ability by resizing? I've read the useful Anamorphic Guide on the wiki, but that didn't seem to cover what I want to do.

Can somebody help to put me straight? Thanks in advance for any guidance!

Regular User
Posts: 138
Joined: Thu Feb 22, 2007 8:38 am

Post by deckeda » Thu May 24, 2007 6:15 pm

In regards to 4:3 content, my advice is to not attempt to make it something it is not. So encode it as 640x480 (or whatever's close to that if minor cropping is necessary. This is where using the GUI is a plus ...)

Leave any upscaling to hardware since it does it on the fly and there'd be no file size penalty, and the quality of the upscaling can improve as the TV or playback server (AppleTV, etc.) improves later. If you do it in software (such as Handbrake) you're forever locked into whatever quality it managed at the time the file was created.

Do not attempt to create a file with the exact 16:9 dimensions of your TV --- almost none of your sources will have this aspect ratio, so making it so will result in a skewed or cropped image just for the sake of having no black bars. Black bars are not the end of the world.

Bitrate is a good indicator of file size, but you're throwing so much more into the mix it's confusing you (and adversely affecting file size it would seem.)

[Edit] Sorry I can't directly answer your questions, but hopefully I've given you something to think about that will indirectly help.

Posts: 2
Joined: Thu May 24, 2007 2:04 pm

Post by smst » Fri May 25, 2007 11:33 am

Thanks for the thoughts. I shall indeed think about them when I return to this after the weekend -- it's appreciated.

Post Reply