Note: This isn't an error report. It's an AVISynth suggestion to help deal with the problem fsvgm777 mentioned in the previous post.
Oh dear. Thanks for bringing this up, that looks awful. It's good to see them working on the decoder still, but it'd be nice if we got some actual progress rather than what appears to be the systematic destruction of things that worked perfectly fine this time last year.
I have been point resizing up (using the smallest factor that is larger than the destination dimension) and then Lanczos resizing down to the exact dimensions since moving to 8K. In my tests, it gave a better result than letting YouTube handle the downscaling anyway. I made a few adjustments to my scripts to accommodate this automatically back then. I don't have access to the exact scripts, but here's the gist of it (segmented, for explanation):
1) Quick calculation of the target dimensions. This would need to be modified in order to be compatible with the encoding package, to allow proper width and height definitions, along with aspect ratio adjustments, based on encode types. Off-hand, I don't know the variables used and so I've just defined it for Youtube use, with YoutubeHeight in this case being assumed to be defined as 2160.
# Calculate the output dimensions
Height = YoutubeHeight
Width = Float(YoutubeHeight) * ARWidth / ARHeight
2) This is optional, but I'd recommend it. It ensures that the video is not only width limited, but also height limited. This means the video's maximum width when the height is set to 2160 is 3840. It does not affect the resulting aspect ratio, only the resulting dimensions to ensure they fit within Youtube's specifications.
# Limit the output dimensions
Scale = (Width > (Height / 9 * 16)) ? ((Float(Height) / 9 * 16) / Width) : 1
Height = (Scale == 1) ? Int(Height) : Int(Height * Scale)
Width = (Scale == 1) ? Int(Width) : Int(Width * Scale)
3) This is already present in the encoding package and ensures the resulting dimensions are multiples of 4.
# Ensure the output dimensions are divisible by 4
Height = (Height % 4 == 1) ? Height + 3 : (Height % 4 == 2) ? Height + 2 : (Height % 4 == 3) ? Height + 1 : Height
Width = (Width % 4 == 1) ? Width + 3 : (Width % 4 == 2) ? Width + 2 : (Width % 4 == 3) ? Width + 1 : Width
4) This is the actual scaling code. If you're after that exclusively, this is what you want. For anyone unfamiliar with the Ceil function, it rounds the value up to the nearest whole number. This means that the source will be Point resized by integers to either the output dimensions (if they're evenly divisible) or to the lowest value that exceeds these dimensions, after which the clip will be Lanczos resized down.
# Scale the source clips
PointResize(Last.Width * Ceil(Float(Width) / Last.Width), Last.Height * Ceil(Float(Height) / Last.Height)).LanczosResize(Width, Height, Taps=2)
It's also worth noting that AVS handles each dimension exclusively and does not perform any resize if the dimension is already correct. This means it's possible to have the original dimensions as the destination dimensions, with the resize making no change at all (this can be verified using subtract). It also means that if one dimension can be reached via exclusively resizing by integers, this dimension can be point-resized to directly and it will then not be adjusted during the LanczosResize.
This means that the original resolution MKV encode will not be processed at all, and the AR-corrected MP4 encode will only have one destination dimension adjusted (and in cases where the source width is less than half of the destination width, this will produce a clear result than simply Lanczos resizing, due to having being Point resized first). This effectively means that the resize method is both automatic, has consistent pixel sizes and is universal across all encode types. Plus, due to only performing the required resizes, if a dimension happens to align via an integer multiple, it benefits from the sharpness and clarity of a point resize and processing time is reduced appropriately.
Hopefully something there proves useful, it's nice to have something automatic for things like this. I'd also recommend briefly testing it before proper use (just to be safe), as whilst I've used this idea extensively, I still don't have PC access and this has been transcribed from memory and a screenshot I had on a mobile device.
This is also a good time to announce that I'm taking bets on what Youtube will do next. 3:1 odds, will they break 1440p or will they fix either 5K/8K? Who knows!
(incidentally, this was uploaded at 5k resolution, and it does not have that quality option, when previously uploaded videos actually showed that option)
It should be noted that the background scrolls insanely fast upwards in this segment.
By the way, this will affect all quality options (I always double-check my encodes at 720p60, like in this instance, but 4k will equally be affected)
If it was encoded at 4k res, it will be fine:
(note: this is with Lanczos downscale, though I assume straight point upscale is also fine)
As an aside, this has happened to me (to a lesser extent) when I did The Mysterious Murasame Castle:
(note: 2688p encode, quality options do not go beyond 4k (expected))
The published encode does not have these nasty artifacts below the tree.
If anyone still wants to upload a video that's above 4k res, then it should be double-checked that it's fine on YouTube.
Until YouTube fixes the issue, it is strongly recommended to not upload anything between 4k res and 8k res, especially with the 5k option no longer available on new uploads, even if it was encoded at 5k res.
