View Full Version : Resolution Mod 4
Atlantis
19th July 2020, 15:47
The more you do encoding and learn, the more you find new flaws. Ignorance is bliss!
Recently I realized again I have been encoding wrong. This time about cropping. I always wanted to go mod 2 for resolution but always said, to be on the safe side, I will go mod 4.
Now I see that even mod 4 is not good enough. This is especially visible on TV and less on PC. For example for a 1920 x 804 video, you see a distorted last line on the button. Only trained eyes will notice it, especially visible with lines with an angle.
So I realized that I should go mod 8 not to get that bottom line distortion. To my eyes, I don't see difference with mod 8 or mod 16. Should I go mod 16?
What are your experiences? Is this more visible in H265 encoding? Does this exist in H264 also?
microchip8
19th July 2020, 16:24
I always encode to mod 4 and do not see such a line. Never have, not on TV and not on monitor
Boulder
19th July 2020, 18:52
That must be a decoder issue. I've never had problems with mod-4 resolutions that I use all the time.
Atlantis
19th July 2020, 22:18
It is indeed hardware dependent also. For example I have an Amlogic CoreELEC that amplifies the problem and it's easily visible. But it is there, less visible, you have to pixel hunt and once you see it, you never unsee it. I'm definitely leaving mod 4 behind and go mod 8. I will see if I can do screengrabs.
benwaggoner
20th July 2020, 19:08
I generally only do mod4 for square pixel frame sizes below 640x480. mod8 up through 1080p, and then mod16 for higher.
In theory mod2 should work fine with modern codecs. Alas, it's hard to test that something works on everything.
Atlantis
20th July 2020, 22:58
So I did a little search and this thing is a little more complicated. There is indeed a hardware limitation in Amlogic hardware that does not show mod 4 videos correctly. It supposedly repeats the last lines to make it mod 8.
But this caused me to look a little closer at the encodes on PC and I see a second different issue. This happens at the edges of the video where the black lines start.
Even if I do a perfect mod 16 crop on picture, I see a little artifact on the last line. It's not 100% smooth. So in some cases I find that if I keep a little more black lines, the encodes are better on the edges. Have you seen this? What is this encode difficulty at the edges of the video?
Atlantis
20th July 2020, 23:02
In theory mod2 should work fine with modern codecs. Alas, it's hard to test that something works on everything.
Yes, on PC mod 2 works but in the real world with so many hardware decoders, I think mod 8 is the safe way to go.
benwaggoner
21st July 2020, 16:07
Even if I do a perfect mod 16 crop on picture, I see a little artifact on the last line. It's not 100% smooth. So in some cases I find that if I keep a little more black lines, the encodes are better on the edges. Have you seen this? What is this encode difficulty at the edges of the video?
Are you sure you cropped tight enough to make sure it's 100% full brightness pixels at the bottom edge?
I can imagine cases where if letterboxing is mod4 or even mod2, AMP would help in making that bottom line solid. But if it is dimmer from being from the edge, you could get some weirdness.
Atlantis
21st July 2020, 22:26
These are very subtle things that only zooming in on PC and pixel hunting will show them. It is not visible on TV. I suppose I shouldn't even go down this path but it's "fun" and I have discovered even stranger things!
Discovered that if you just add 4 lines, 2 on the top and 2 on the bottom to go from mod 4 to mod 8 (1920 x 804 to 1920 x 808) the entire encode looks different and not just the edges. Even in the middle of the picture it is different. The mod 8 encode looks better, sharper with less artifacts than the mod 4 encode!
Atlantis
26th July 2020, 19:09
I just realized something after all these years and it blew my mind! 1080 is not mod 16! I always thought that the Bluray resolution is divisible by 16. I always thought they go for mod16.
Sharc
26th July 2020, 19:16
The coded size is actually 1920x1088. The display size is 1920x1080 for 16:9 DAR.
Atlantis
26th July 2020, 21:58
Wow, that explodes my mind even more. Please explain that. What that means exactly? What do you mean the coded size?
Sharc
26th July 2020, 22:52
The encoder uses internally 16x16 macroblocks and pads the source to 1920x1088. For playback the 'excess' vertical pixels are just cropped off so you won't see these.
Atlantis
26th July 2020, 23:40
Do you mean that in the finished video file present on the bluray, there are 8 more vertical lines? If yes, these are image information or black lines and how come media info still says it's 1080.
Sharc
26th July 2020, 23:49
Yes, 8 extra black lines ar encoded in the frame. They are discarded by MediaInfo and most other tools, as there is no practical use case or standard for 1920x1088. It is just more efficient for the encoding process.
benwaggoner
27th July 2020, 02:14
Yes, 8 extra black lines ar encoded in the frame. They are discarded by MediaInfo and most other tools, as there is no practical use case or standard for 1920x1088. It is just more efficient for the encoding process.
...and it's been that way for decades, including ATSC 1080i MPEG-2 and Blu-ray. Modern codecs with variable block sizes make non-mod 16 more efficient.
Atlantis
27th July 2020, 08:17
So if you take a 4K file or a larger file and crop it to 1088 with image (no black lines), everything discards the extra 8 lines? Or is it a flag that says discard it?
Sharc
27th July 2020, 08:28
Why don't you just try and see what you get with "everything"?
When you crop a 4k file to 1088 it will become 1088. The subsequent steps depend on the encoding SW + authoring SW + player + media (e.g. Blu-ray) constraints.
benwaggoner
27th July 2020, 20:39
Why don't you just try and see what you get with "everything"?
When you crop a 4k file to 1088 it will become 1088. The subsequent steps depend on the encoding SW + authoring SW + player + media (e.g. Blu-ray) constraints.
I expect that many players won't know what to do with real 1088p content, since that's super-HD and not something really seen in the wild. An interesting experiment, but nothing I'd do with my own content.
And there really isn't any quality drawback do doing mod8 versus mod16 post MPEG-2. H.264 and later have mirroring features to eliminate the quality issues from having a sharp black edge at the bottom of the encoded region.
Boulder
27th July 2020, 20:51
Quite a lot of Blu-ray releases have these strange bright one or two pixel high artifact lines on top or bottom of the frame.
Asmodian
27th July 2020, 21:26
I think that is unrelated. The extra eight pixels have always been on the bottom in my experience.
Atlantis
27th July 2020, 21:31
Boulder is right. This is not true that you do not get artifacts on the edges with modern codecs.
At least for me with x265 I have seen it myself. I have a 2.40:1 image in a 1920 x 1080 with black bars. I used to crop it to 1920 x 804. Now because of AmLogic problems now I go mod 8. So I did a test and cropped to 1920 x 808 instead. This caused like 2 lines of black border on top and bottom. The resulting encoded picture was not a clear edge. It has artifacts. Then I tried to crop it to 1920 x 816, I got 6 black lines on top and bottom. The resulted encoded file had a much better black edge. It did not have the artifacts of the 1920 x 808 crop. So now I do several tests to see which one is better. For sure I know that if you have 2 extra black lines, it's not good. You need more.
Asmodian
27th July 2020, 21:45
I think you misunderstood what the issue is. Your experiment does not test for edge artifacts, it tests for encoding hard edges that are in the video. Codecs have block sizes which are in frequency space so a sudden change to black will always have issues if it happens within one of those blocks. The smallest blocks I know of are 4x4 in HEVC, and 8x8 is the smallest I would consider for this purpose, so 2 extra black lines will always cause problems. Even if the video was mod 16.
However, if you crop all the video data away the codec can do the cool trick benwaggoner mentioned above:
H.264 and later have mirroring features to eliminate the quality issues from having a sharp black edge at the bottom of the encoded region.
This mirrors the video data into what would have been the empty section of the block when encoding, preventing these artifacts. So it is usually better to have missing lines instead of lines full of black when your video data is not a mod of the smallest block size your codec uses.
If the codec does not do this trick (MPEG2) then you get the same artifacts you noticed, because empty means the same as black.
Sharc
27th July 2020, 22:12
Discovered that if you just add 4 lines, 2 on the top and 2 on the bottom to go from mod 4 to mod 8 (1920 x 804 to 1920 x 808) the entire encode looks different and not just the edges. Even in the middle of the picture it is different. The mod 8 encode looks better, sharper with less artifacts than the mod 4 encode!
Hmmm... could it be that it the alignment of the re-encoded 16x16 macroblocks with the original macroblocks makes a difference? We are discussing the re-ecoding of already compressed sources.
(Assuming that the comparison was based on equal file size).
benwaggoner
28th July 2020, 05:43
Hmmm... could it be that it the alignment of the re-encoded 16x16 macroblocks with the original macroblocks makes a difference? We are discussing the re-ecoding of already compressed sources.
(Assuming that the comparison was based on equal file size).
It's always a good idea to keep alignment if possible.
Getting the right combination of cropping and scaling can be a thing. I've certainly had content where I cropped more off the top than the bottom in order to get mod8 on both instead of mod4 on both. Rember you need to count down from the top to figure out mod, since things like 1088-in-1080 mean that counting from the bottom isn't reliable.
Sharc
28th July 2020, 08:26
It's always a good idea to keep alignment if possible.
Getting the right combination of cropping and scaling can be a thing.
Indeed. Even more so when the video is interlaced and one wants to apply filters on the fields. The cropping must comply with the colorspace (4:x:x) and the size of the fields need to comply with the filter constraints.
foxyshadis
1st August 2020, 10:16
Quite a lot of Blu-ray releases have these strange bright one or two pixel high artifact lines on top or bottom of the frame.
Ugh. x264 introduced blurred extended crop-box how many years ago, at virtually no encoding cost? At least 15? And yet it's still some kind of mystery to encoders that just slap a flat black or white there.
Atlantis
1st August 2020, 23:09
I have done several tests with x265 and it seems to me that mod 16 gives a better encoding results than mod 8. Is this correct?
Atlantis
2nd August 2020, 00:04
Here, one is mod 8 and the other mod 16.
Make 2 guesses, first say which looks better and at what mod it was encoded 8 or 16
Picture 1A 1B
https://i.imgur.com/IXwMeSg.png
Picture 2A 2B
https://i.imgur.com/Qxm4QBO.png
Boulder
2nd August 2020, 12:16
Have you enabled logging and checked how the frame based stats compare against each other?
Atlantis
2nd August 2020, 13:36
I use staxrip. You mean logging in x265? No. I don't know what frame based stats is but what that helps? The best and only important thing to use is our own eyes and what we see.
Boulder
2nd August 2020, 14:39
Of course it helps in determining what the encoder is doing differently. It's clearly making different decisions, which is quite interesting.
Nevertheless, without seeing the encoder settings it's impossible to say anything certain.
Sharc
2nd August 2020, 15:02
Also, as A and B are different encodes, the decision for I,P and B frames are different. Are the pictures A and B for comparison of the same type?
Is the filesize the same for the A and B encodes?
I have no clear peference for A or B so far.
Atlantis
2nd August 2020, 15:23
The source is HDR. One is 3840x1608 vs 3840x1616 at CRF 21.
A is 1608 and B is 1616. On the black edge 2B is better than 2A. As talked before because 1608 crop has fewer black lines.
These images doesn't do it justice. You have to do it yourself and compare the whole image. Same settings, crop 8 and 16 and compare. It seems (and it is not definitive) to me that crop 16 has less artifacts overall.
benwaggoner
11th August 2020, 00:35
The source is HDR. One is 3840x1608 vs 3840x1616 at CRF 21.
A is 1608 and B is 1616. On the black edge 2B is better than 2A. As talked before because 1608 crop has fewer black lines.
These images doesn't do it justice. You have to do it yourself and compare the whole image. Same settings, crop 8 and 16 and compare. It seems (and it is not definitive) to me that crop 16 has less artifacts overall.
Back in olden times, my practice was to always crop to at least the first full-brightless line on all edges. Even a line that was a blend of signal and black and was dim could cause issues. Sometimes, that meant cropping out a couple of lines of image in order to meet mod8 or mod4 requirements. For MPEG-2, I sometimes even adjusted the source frame up or down a little bit to get better alignment with the target mod value and to equalize how much would be cropped off opposite edges.
NTSC 486 got automatic cropping of 4 top, 2 bottom, and 8 left/right to make 704x480, and then adjustment from there. Per NTSC and SMPTE, there wasn't supposed to be actual signal outside of that center(ish) 704x480 block.
Atlantis
14th August 2020, 23:52
I'm going with not cropping anything and only add borders. Again, my unscientific feeling is that regardless of borders, mod 16 seems to compress and look better than mod 8. Maybe because the original uncropped source was encoded mod 16? I don't know
benwaggoner
20th August 2020, 02:20
I'm going with not cropping anything and only add borders. Again, my unscientific feeling is that regardless of borders, mod 16 seems to compress and look better than mod 8. Maybe because the original uncropped source was encoded mod 16? I don't know
How do you mean it compresses and looks better?
Personally, I hate adding borders as well, because it causes all sorts of issues when playing full screen when the display and content have different aspect ratios. Like having one shade of black for letterboxing in the content and another for pillarboxing by the playback device.
Atlantis
20th August 2020, 02:34
Well, I use the same settings, one is cropped 808 and the other 816 for example. The 816 resolution gets encoded with a little lower bitrate, smaller file size. The difference is not huge.
I also take screenshots from the 2 encodes and compare them and the 816 version has less artifacts than the 808 version.
To go mod 16 is not huge. For example going from 808 to 816 is only 8 lines. That is only 4 black line on top and on bottom.
The TV must be really really bad if you see those small black lines. It's a non issue for me. Impossible to see the black borders if the TV is decently configured.
Boulder
20th August 2020, 05:20
But did you check that the frames are the same type in both encodes? In x265, there's a huge difference between a P- and a B-frame.
Atlantis
20th August 2020, 14:22
No I didn't.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.