View Full Version : AVI.Net - Effect of Changing Aspect Height
flambot
30th January 2008, 01:41
I've been doing some exploration of various S/ware / Codecs for compressing video. I took a shine to Avi.Net because of its simple interface and reasonably easy use. I have read many posts about various things and tried to understand what I've been reading - without a lot of success.
So I thought the best thing would be to ask specific questions about my attempts.
Test File - 720x576 PAL 16:9 recorded VBR 8.0Mbps peak .mpg of 245Mb.
When I use this file in AVI.Net, the S/ware really only gives a width value (720) and rescales it (if that the right word) to 416 height. Isn't this decreasing the resolution? Can I keep the original res? What effect does a lesser height have?
If I use the "+" button, I can adjust the height back to 576, but this causes the output (even though W/S) to look more like 4:3.
I tried several tests using the various functions of the S/Ware. The S/Ware defaulted to 63Mb size. I stepped that up to 100Mb. Using this size the best result was 720x416 using D/I, Sharp+1 HQ. The quality was still fairly poor compared to the original.
Like most posts, I'm trying to achieve max quality for reasonable file size - something more suited to a beginner. Output is currently on a 42" W/S LCD played through XBMC @ SD. I'm looking at the Xvid codec but not sure if this is the best. I have tried numerous pieces of S/ware with mixed results. Some does the same scaling as this, while others allow you to keep the original aspect, which I think is what I want if I read the posts correctly.
Is there a better program? I tried AutoGK but it seemed slow (compared to some of the others). I looked at AVS, AlltoAVI, Handbrake, meGUI to name a few. I'm not really sure what to look for and it doesn't have to be free.
Thx in advance.
The Scientist
30th January 2008, 04:26
If you have a 720x576 PAL 16:9, then why are you stretching it back out to 576? Of course it will then look like 4:3...... The original 576 height includes everything, you know, the big chunk of black bars at the top and bottom, the reason it then said 416 was because that is the size of the actual "picture" area.
flambot
30th January 2008, 08:42
If you have a 720x576 PAL 16:9, then why are you stretching it back out to 576? Of course it will then look like 4:3...... The original 576 height includes everything, you know, the big chunk of black bars at the top and bottom, the reason it then said 416 was because that is the size of the actual "picture" area.
Thx for your reply. I guess it's pretty obvious I don't really know anything about this sort of thing.
The original video file had no black bars at all, so I was trying to get it to output the same size. Didn't see an option. So why 416? Other programs (can't remember right now which ones) handled the video as it was and re-encoded as such. What I'm trying to understand is what is happening to further my experiments. :thanks:
plugh
30th January 2008, 16:16
The thing most newbies miss is the fact that usually things like DVDs, which are targetted at TVs, not PC monitors, do not use square pixels. In the case of PAL, the two common Pixel Aspect Ratios are 12:11 (for 4:3 Display Aspect Ratio) and 16:11 (for 16:9 Display Aspect Ratio). (You will note that those ratios mean the pixels are always wider than they are tall.)
Conversely, typical Xvid (etc) encodes are targetted for square pixels (Pixel Aspect Ratio 1:1). The numbers you are seeing are the square pixel resolutions. For example:
(for technical reasons its more appropriate to use 704 vs 720)
(704 * 16/11 ) / 576 = 1.78 = 16:9
(720 * 1/1 ) / 416 = 1.73 ~ 16:9
Both resolutions give a 16:9 displayed image, though the first one uses more total (non-square) pixels to do it.
The reason your picture looked distorted when you forced the full resolution setting is because your encode did not include the "flags" that told the playback software (xbmc) that it should display the decoded image using non-square pixels.
If your encoding software does not give you access to these flags, there are tools (such as "mpeg4modifier) that can set them after the fact.
The Scientist
30th January 2008, 17:51
So why 416?In avi.NET, the size (height) you are left with should be the size based on the correct aspect ratio for that width, give or take a little. So unless something drastic has happened to the 'autocrop' procedure during detection and removal of black areas, the height should be correct when loaded in or width changed.
flambot
30th January 2008, 21:34
The thing most newbies miss is the fact that usually things like DVDs, which are targetted at TVs, not PC monitors, do not use square pixels. In the case of PAL, the two common Pixel Aspect Ratios are 12:11 (for 4:3 Display Aspect Ratio) and 16:11 (for 16:9 Display Aspect Ratio). (You will note that those ratios mean the pixels are always wider than they are tall.)
Conversely, typical Xvid (etc) encodes are targetted for square pixels (Pixel Aspect Ratio 1:1). The numbers you are seeing are the square pixel resolutions. For example:
(for technical reasons its more appropriate to use 704 vs 720)
(704 * 16/11 ) / 576 = 1.78 = 16:9
(720 * 1/1 ) / 416 = 1.73 ~ 16:9
Both resolutions give a 16:9 displayed image, though the first one uses more total (non-square) pixels to do it.
The reason your picture looked distorted when you forced the full resolution setting is because your encode did not include the "flags" that told the playback software (xbmc) that it should display the decoded image using non-square pixels.
If your encoding software does not give you access to these flags, there are tools (such as "mpeg4modifier) that can set them after the fact.
plugh - Thx for this - I didn't know about the pixel shape.
So if Xvid is aimed primarily for Square pixels, is there S/ware (codec?) that is aimed at TV viewing (W/S)? Or is it just a matter of changing the flags (Done this lots for DVD)
Ultimately, quality is more important than eeking the smallest file - although everything needs a balance I guess - quality/size Vs time/complexity.
I'll create some 704 wide test file and check out the software for flag changing.
Really appreciate you taking the time to draft a great explanation.
flambot
30th January 2008, 21:35
In avi.NET, the size (height) you are left with should be the size based on the correct aspect ratio for that width, give or take a little. So unless something drastic has happened to the 'autocrop' procedure during detection and removal of black areas, the height should be correct when loaded in or width changed.
This makes a lot more sense now with the knowledge of the square pixels. Off to do a 704 test. Thank you again.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.