View Full Version : Optimal 480p resolution for HEVC
kotuwa
28th September 2015, 03:48
480p for 16:9 is 853.33x480. right?
Since a pixel should be a whole number, ppl use 854 or 852 or 848 for width.
Ppl use 852x480 to get the width dividable by 4.
And 848x480 to it dividable by 16.
I would like to know how HEVC behaves among those 3 resolution. (854x480, 852x480, 848x480)
Sure it supports all 3... But what are the impacts of encoding...
Regarding the resolution factors and image stretch and A/R deviations when resizing, what could be the optimal for HEVC
In HEVC, is that, dividable by 4 and 16 factors are less important than in AVC?
!
foxyshadis
28th September 2015, 14:23
x265 pads the video out to min-cu size, generally 8x8 but can be set higher. The visual compression difference of any of the three sizes will probably be completely unnoticeable. (Frankly, the aspect ratio differences will also probably be unnoticeable in casual viewing.) Just use whatever you prefer.
HEVC won't gain you much at all at that resolution though; it barely even gains much at 1080p. It's tremendously better than x264 at 4K and up, but that's worlds away from 480p. Give it a shot, though, maybe your video works better.
MeteorRain
28th September 2015, 14:52
Typical process on DVD source is to crop 8 pixels on left and right side, and then resize to 854x480.
If you are looking for optimal width then you can try different cropping.
(For example, 10 pixels on each side and then 848x480, etc
HarryM
28th September 2015, 16:15
Typical process on DVD source is to crop 4 pixels on left and right side, and then resize to 854x480.
If you are looking for optimal width then you can try different cropping.
(For example, 6 pixels on each side and then 848x480, etc
Its not true. "480p" compatible HW players support only 720 pixels in width as maximum. No more. Therefore, the best is 704x400px or 720x400px only.
Mod16 is preferable for ALL codecs.
sneaker_ger
28th September 2015, 17:30
This is about HEVC, you will have a very hard time finding any hardware player that does not support 1920x1080 at the very least.
mandarinka
28th September 2015, 19:49
Typical process on DVD source is to crop 4 pixels on left and right side, and then resize to 854x480.
If you are looking for optimal width then you can try different cropping.
(For example, 6 pixels on each side and then 848x480, etc
Its not true. "480p" compatible HW players support only 720 pixels in width as maximum. No more. Therefore, the best is 704x400px or 720x400px only.
"Best" (see rules about the word best, BTW) resolution is the original one. Crop only as much as is needed to get rid of black bars and keep it at that, encode anamorphically and use a proper display aspect ratio, for example what this calculator (http://ps-auxw.de/cgi-bin/ar-calc.pl) tells you.
Mod16 is preferable for ALL codecs.
Don't say such things. It is hardly true for anything decent since x264 and thanks to myths like this, people ruin their videos by using wrong ARs, overcropping and such. The benefits of using mod16 resolution are basically zero. If you disagree, try to make a comparison of two encodes where rounding the resolution to mod16 would be improving quality! (And that would still ignore the issue that forcing mod16 harms quality in the first place by requiring resampling and/or overcrop.)
kolak
29th September 2015, 10:40
Yes, there is no need anymore for mod16.
852x480 (assuming no crop was done) would be good. 854 is probably most accurate and "expected".
SeeMoreDigital
29th September 2015, 12:32
I recently went through some of my old 720x480 (16:9 DAR) MPEG-2 disc sources and have re-encoded them to AVClossless at 856x480 pixels (ie: mod-8) ;)
benwaggoner
2nd October 2015, 17:28
I recently went through some of my old 720x480 (16:9 DAR) MPEG-2 disc sources and have re-encoded them to AVClossless at 856x720 pixels (ie: mod-8) ;)
Didn't that leave you will a bigger file that is less accurate than the source?
Now that non-square pixel support is pretty well universal, I'm a fan of just cropping to active image area and keeping all the pixels and the SAR. There's no benefit to throwing pixels out or to creating new ones.
I think Mod-4 is pretty well universally compatible today in released decoders. The only exception I can think of will have that fixed in a mandatory firmware update within a week.
MeteorRain
5th October 2015, 04:12
Most time when we are talking about non-anamorphic, or mod XX, we are talking about compatibilities.
For a "normal" player, these features are all well supported, and keep the original resolution + crop only the margin + mod 4 + anamorphic should be a very good option.
However when dealing with buggy decoders (who may crash on non mod 8/16), buggy subtitle filters (who may ignore ARs), extra care should be taken when making decision.
You never know what soft/hardware user is gonna use.
Asmodian
5th October 2015, 18:46
Again, this is HEVC. All of that is much less likely on something that can play HEVC. I also prefer encoding the original pixels if possible.
MeteorRain
6th October 2015, 04:11
Again, this is HEVC. All of that is much less likely on something that can play HEVC. I also prefer encoding the original pixels if possible.
TBH, hevc player != well designed / developed / tested player.
benwaggoner
13th October 2015, 19:57
TBH, hevc player != well designed / developed / tested player.
Well, except HEVC player = recently updated player. I suspect most HEVC decoding is being doing in players/OSes/SoCs that already had anamorphic nailed. I certainly feel more comfortable that anamorphic HEVC will work on an arbitrary HEVC compatible player than anamorphic HEVC will work on a arbitrary compatible H.264 player.
movmasty
5th January 2016, 20:28
Typical process on DVD source is to crop 4 pixels on left and right side, and then resize to 854x480.
If you are looking for optimal width then you can try different cropping.
(For example, 6 pixels on each side and then 848x480, etc
I thought we were talking about BR source?
However, 712x 40/33 ~ 863....
Remember that DVD frames are 720, but mpeg frames are ~704
in fact 704x 40/33 = 853.333
HarryM
9th January 2016, 13:34
I tested x264 codec and non-mod16 and mod16 resolution coding... in many scenarios.... and my conclusion is, that non-mod16 resolution is generally possible, but with significant filesize penalty - plus +2-4% on bitrate/framepixel.
Selur
10th January 2016, 09:29
but with significant filesize penalty - plus +2-4% on bitrate/framepixel.
Significant, is really relative.
May be I'm wrong, but with a bit rate of 10 MBit/s and a resolution of 1920x1080 one would have a bit/framepixel value of 10000000 / 2073600 = 4.8225308641975308641975308641975 bit/framepixel.
4% of that would be 0.1929012345679012345679012345679 bit/frame pixel, which would be 400 bit/frame.
Given a 3hr ( = 240min = 14400 sec) movie with a frame rate of 24fps we would have 345 600 (= 14400*24) frames and thus a file increase of (345 600*400) 138 240 000 bit = 17 280 000 byte = 16.4794921875 MB.
Normal file size would be (10MBit/s = 10 000 000 = 1 250 000 byte/s =) 1.1920928955078125 MB/s time 14400 sec = 17 166.1376953125 MB.
Less than 1% file increase doesn't sound that significant to me,...
movmasty
10th January 2016, 11:06
Given a 3hr ( = 240min,... ...Is the hour? It is 80 minutes.
A good movie is 2 hours, and this 3 hours are 240 minutes :D
If its +2-4% on bitrate/framepixel, its +2-4% on bitrate or size as well.
I like numbers, but there are too many in your post.
what is the distance of Centauri? 4Ly, 480 days in a year, 32 hours in a day, 80 mins in a hour, 80 secs in a min.....very big!
The difference exist, but is very smaller mod16xmod8 is still very good
If you really seek for total compatibly and universal rendering should use mod64xmod64.
that gives few res available
for 4:3 256x192 and multiples
for 16:9 1024x576 and multiples
for 2.35 2560x1088 and multiples.
vivan
10th January 2016, 11:08
4% of that would be 0.193 bit/frame pixel, which would be 400 bit/frame.How do you do that?
And I'm pretty sure he meant just 4% increase in bitrate or bpp.
If you really seek for compatibily and universal rendering should use mod64xmod64.Compatibility? What kind of decoder can't decode 720p because it's not mod64?
movmasty
10th January 2016, 13:51
Compatibility? What kind of decoder can't decode 720p because it's not mod64?
Amiga? Commodore :confused:
vivan
10th January 2016, 14:39
Amiga? Commodore :confused:Yet they can decode 576p because it's mod64 resolution?
movmasty
10th January 2016, 18:18
Some Appalachian self.constructed board :confused:
Selur
10th January 2016, 20:40
...Is the hour? It is 80 minutes.
A good movie is 2 hours, and this 3 hours are 240 minutes
LoL, wanted four instead of 3 hours. ;)
4% of that would be 0.193 bit/frame pixel, which would be 400 bit/frame.
How do you do that?
0.192 'frame pixel' and 1920x1080 pixel per frame = 400 000 and then I lost the 1000 :) (damn really need more sleep)
foxyshadis
11th January 2016, 13:50
...Is the hour? It is 80 minutes.
A good movie is 2 hours, and this 3 hours are 240 minutes :D
If its +2-4% on bitrate/framepixel, its +2-4% on bitrate or size as well.
I like numbers, but there are too many in your post.
what is the distance of Centauri? 4Ly, 480 days in a year, 32 hours in a day, 80 mins in a hour, 80 secs in a min.....very big!
The difference exist, but is very smaller mod16xmod8 is still very good
If you really seek for total compatibly and universal rendering should use mod64xmod64.
that gives few res available
for 4:3 256x192 and multiples
for 16:9 1024x576 and multiples
for 2.35 2560x1088 and multiples.
I don't think you understand how modX is decoded. Once you're past the hurdle of requiring decode and output resolutions to be identical, without which 1080p wouldn't exist, any other resolution is OK down to mod 8x2 (for the usual 4:2:0), and mod 2x2 on nearly all hardware. At this point the ones with bugs even in their horizontal conversion are extremely rare, it's a long solved problem.
And maybe tamp down on the sarcasm, or whatever it is, and answer questions and correct mistakes directly instead of throwing out non sequiturs.
bcn_246
17th February 2016, 14:10
Widescreen NTSC DVDs are not quite 16:9 (1.77778:1). The standard NTSC DVD has a resolution of 720x480. It also has a signalled Pixel Aspect Ratio of 40:33. This tells the decoder to stretch the image out horizontally. This makes the actual Aspect Ratio 1.81818:1 (720/480 = 1.5, 1.5 x (40/33) = 1.818...).
480 x 1.81818 = 872, so 480p DVDRips should really 872x480. However, 872 is not mod16. Ideally clips should be mod16, however with newer decoders it seems far less important (I have yet to find any player that struggled with anything other than mod2). If you want to be safe, go with 864x480 (1.8:1) and crop to reduce error.
It is worth bearing in mind that some mastering facilities may have made the mistake of assuming a DVD to be 16:9 also. When I can I have a look through the DVD for squares or circles to check what the actual aspect ratio is (logos in the credits are always a good indicator). If you do find the DVD has been mastered at 16:9 then I would go with 852x480 (again, not mod16, so go with 848x480 if you want to be safe).
It is also worth bearing in mind that when muxing to MKV (with MKVToolNix GUI) you can manually set the playback Aspect Ratio (see screenshot). While I don't use this to encode at Aspect Ratios far off (not all devices read this header correctly) it is useful to get things exact. For example, if you encode at 848x480 and wish to have it (when possible) be resized to 1920x1080 on your display it is worth setting the flag (although an error of 0.63% is really not much of an issue).
Also, for reference PAL DVDs are also not exactly 16:9 (1024x576). They use an aspect ratio of 16:11, so 576p content should be really be resized to 1048x576 (or 1040/1056 if you wish to keep it mod16).
Hope this helps explain things,
Ben
foxyshadis
24th February 2016, 11:49
Widescreen NTSC DVDs are not quite 16:9 (1.77778:1). The standard NTSC DVD has a resolution of 720x480. It also has a signalled Pixel Aspect Ratio of 40:33. This tells the decoder to stretch the image out horizontally. This makes the actual Aspect Ratio 1.81818:1 (720/480 = 1.5, 1.5 x (40/33) = 1.818...).
Widescreen NTSC DVDs are exactly 16:9, because the active area is 704x480, not 720x480. Some discs are encoded that way, most are 720. Some discs violate the standard and some players ignore it, but the 704 middle pixels are what's supposed to be displayed even when the encode is 720. Most commercial DVDs will have 8 pixels of dark or black pixels on each side, though it's fairly often off-center, and sometimes the active frame is edge-to-edge and should be treated as having a different aspect ratio. (Though the difference is small.) That's the trouble with having thousands of companies putting out releases, quite a few of them screw it up.
There have been quite a few threads here about this problem.
MeteorRain
25th February 2016, 05:19
in fact 704 x 40/33 = 853.333
Good catch, I typo'd.
pandy
25th February 2016, 15:38
Amiga? Commodore :confused:
Nope - Comodore Amiga is:
at first non ITU video source
at second capable to do MOD16 in horizontal and any MOD1 in vertical
at third it can use (ICS/OCS) 2 pixel clocks and (ECS/AGA) 3 different pixel clocks
at fourth is Amiga is not capable to decode H.265 with reasonable speed even with most fastest accelerator board (for today such as Apollo which is something around 150MHz MC68060 i.e. somewhere around 200MHz 486DX).
And to not be completely OT: H.265 is not optimized for SD resolution (compression efficiency will be significantly bellow promised 50%).
benwaggoner
25th February 2016, 20:17
And to not be completely OT: H.265 is not optimized for SD resolution (compression efficiency will be significantly bellow promised 50%).
I don't know if that is true. Implementation maturity might not be there to be able to deliver x264 quality at half the bit rate in x264's sweet spot, but we're not THAT far off with 1.9 now. 50% is probably achievable with some content (low noise).
pandy
26th February 2016, 20:17
I don't know if that is true. Implementation maturity might not be there to be able to deliver x264 quality at half the bit rate in x264's sweet spot, but we're not THAT far off with 1.9 now. 50% is probably achievable with some content (low noise).
Well it is proven (sort of) that even HD content is to small for H.265.
Even if H.265 will deliver few % gain then IMHO is not worth all fuzz behind it.
But yes, i never saw objective test with focus on how H.265 scaling with source resolution - based on experience with previous codecs i don't expect different behavior.
benwaggoner
26th February 2016, 22:59
Well it is proven (sort of) that even HD content is to small for H.265.
Even if H.265 will deliver few % gain then IMHO is not worth all fuzz behind it.
Yes, not much reason to use HEVC for a few %. But even for SD I'd expect >25% for a lot of content.
The advantage of HEVC goes up with high resolutions; it's >50% at 3840x2160. But it's not JUST high resolutions.
YamashitaRen
29th February 2016, 19:41
Can you elaborate on what makes HEVC more interesting the higher the resolution goes ?
Are we talking about transparency, metrics, perceptual quality ?
benwaggoner
29th February 2016, 22:39
Can you elaborate on what makes HEVC more interesting the higher the resolution goes ?
Are we talking about transparency, metrics, perceptual quality ?
Larger block/TU sizes are probably the primary thing that helps relative efficiency at frame size goes up. And UHD, you can find flat areas where 32x32 works, while H.264 would be stuck with 8x8.
Lots of other HEVC features provide efficiency improvements irrespective of frame size. So there's a base efficiency improvement, and an additional frame size differential improvement.
YamashitaRen
1st March 2016, 12:20
Oh I see... Thanks for your answer :)
kolak
6th March 2016, 22:01
Widescreen NTSC DVDs are exactly 16:9, because the active area is 704x480, not 720x480. Some discs are encoded that way, most are 720. Some discs violate the standard and some players ignore it, but the 704 middle pixels are what's supposed to be displayed even when the encode is 720. Most commercial DVDs will have 8 pixels of dark or black pixels on each side, though it's fairly often off-center, and sometimes the active frame is edge-to-edge and should be treated as having a different aspect ratio. (Though the difference is small.) That's the trouble with having thousands of companies putting out releases, quite a few of them screw it up.
There have been quite a few threads here about this problem.
Well, when you follow this BBC guide (which I assume is correct and as per old analog standard) than if you scale HD master to SD (with 8 pixels padding) than when you watch it on LCD/Plasma etc it circle won't be circle. When you do the same on old CRT than it will be fine.
My own practical test shown that BBC rules don't work for modern TVs. Adobe adopted these rules some time ago and now their HD to SD scaling has black bars on side which I'm not that sure is correct for modern TVs (as they use square pixels and seams to have no compensation for "old standard"- Sony broadcast monitors have special setting for it).
benwaggoner
8th March 2016, 00:26
Well, when you follow this BBC guide (which I assume is correct and as per old analog standard) than if you scale HD master to SD (with 8 pixels padding) than when you watch it on LCD/Plasma etc it circle won't be circle. When you do the same on old CRT than it will be fine.
My own practical test shown that BBC rules don't work for modern TVs. Adobe adopted these rules some time ago and now their HD to SD scaling has black bars on side which I'm not that sure is correct for modern TVs (as they use square pixels and seams to have no compensation for "old standard"- Sony broadcast monitors have special setting for it).
I think the challenge comes from being able to do 16:9 704x576 in broadcast but not DVD; DVD only allows <720 widths with 4:3 for some long-forgotten reason.
Optimally encode to 704x576 from 16:9 with full raster and no black bars and standard PAL sample aspect ratio, and circles should be circles.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.