While I encode something in SD, I always make my own "..._512kb.mp4" file to make a stream from some server and for Archive.org. As an AviSynth user, I have to make a final resize so the final video's size matches the 4:3 aspect ratio.
There are numerous ways to resize something with AviSynth. I'd like to know which one you'll recommend so we get a "TV feeling". Because I think that a TV won't do a point resize so a video fills the screen.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
If it was up to me, I'd try a point resize, correct with point resize, and point resize 2x more... basically... the same thing as a HD encode.
But that's just me. Otherwise, Lanczos4Resize.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
By the way, on Youtube it's now possible to add a special tag that will stretch the content to 4:3 (yt:stretch=4:3). The stretching is achieved in software (non-destructively) by simply rendering the decoded pixels to an area of a different size. Might want to give that a try the next time you upload something there. Here's an example.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Flygon wrote:
Dada just simplified HD encoding for everyone. I for one welcome this new robot overlord.
It's been around for a while and I think some other encoders with their own Youtube channels are already using it. (I don't remember where I first saw that tag being used but I'm sure it was on a video by someone from here.)
Grunt was skeptical about it when I mentioned it on IRC but I think it's worth some testing with original-sized uploads.
By the way, on Youtube it's now possible to add a special tag that will stretch the content to 4:3 (yt:stretch=4:3). The stretching is achieved in software (non-destructively) by simply rendering the decoded pixels to an area of a different size. Might want to give that a try the next time you upload something there. Here's an example.
That's pretty neat, though interesting that one would need to put it in tags. I see it in the tags listing in your example and that doesn't make sense as a tag. YouTube should have it separate somewhere instead, but oh well.
So this answer I got from Flygon months ago is now invalid?
EDIT: That would be useful for my HD encodes on YouTube, but for my SD encodes anywhere else... I guess I'd use Lanczos4Resize.
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
I would prefer control over the scaling process rather than allowing an unknown algorithm of YouTube's to take precedence, given YouTube's penchant for low-quality output.
I would prefer control over the scaling process rather than allowing an unknown algorithm of YouTube's to take precedence, given YouTube's penchant for low-quality output.
I believe the scaling is done by flash really. JWPlayer has something similar in terms of stretching. Basically it has nothing to do with YouTube except YouTube telling flashing to display at a certain size.
For YouTube, I should mention the better solution is resize it so that the resolution is a multiple of the WxH and in 4:3 aspect ratio. For example of 256x224, pointresize to 3584x2688. That's 256*14x224*12, so there is zero distortions (the current method has a slight distortion).
But this is all off topic, lol.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
sgrunt wrote:
I would prefer control over the scaling process rather than allowing an unknown algorithm of YouTube's to take precedence, given YouTube's penchant for low-quality output.
Yeah, when I mentioned this on IRC you said the same thing. Really, I don't get why you'd just dismiss this so easily. It's not like it's impossible to simply try and see what happens rather than concluding that it's "an unknown" and therefore not worth pursuing. As I already told you on IRC, this isn't "Youtube's algorithm", it's done in realtime by the Flash Player.
So, I went and checked which algorithm the Flash Player uses: it turns out to be a simple bilinear resize.
I guess it entirely depends on how you encode things to begin with. If all you're doing is a nearest neighbor rescale to, say, 12x the original size followed by an interpolated rescale to correct the aspect ratio, it probably doesn't matter all that much whether you use Lanczos4 or bilinear. (But again, I don't know much about this topic. I'm not an encoder. Just saying it might be worth checking this out.)
There is also the order of when it has been resized. If the resize happens before the colorspace conversion to RGB, that's not a good thing since there will be more color loss. If the resize happens after the colorspace conversion to RGB, then all the color is there with as you said, minor interpolation.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Aktan wrote:
There is also the order of when it has been resized. If the resize happens before the colorspace conversion to RGB, that's not a good thing since there will be more color loss. If the resize happens after the colorspace conversion to RGB, then all the color is there with as you said, minor interpolation.
If I had to guess, I'd say it probably occurs after conversion to RGB. Not exactly sure how to properly test that, though. Just resized another test pattern in a Flash video container (one with a 1x1 grid of red/blue pixels) and it appeared exactly the same as a bilinear resize. I'd appreciate any information on how I could properly test this.
I'm quite sure there is no transcoding going on when using the 4:3 or 16:9 tags, just rendering at a different pixel aspect ratio. You can test it quite easily: just add or remove the tags to one of your videos and observe how it is instantly rendered at a different aspect ratio.
I'm quite sure there is no transcoding going on when using the 4:3 or 16:9 tags, just rendering at a different pixel aspect ratio. You can test it quite easily: just add or remove the tags to one of your videos and observe how it is instantly rendered at a different aspect ratio.
Oh, we know there is no transcoding, but the scaling is done on fly. The question in which order. In one way (resize, then colorspace conversion) would introduce color bleeding. The other way (colorspace conversion, then resize) would not. That is the test we are talking about.
Oh, we know there is no transcoding, but the scaling is done on fly. The question in which order. In one way (resize, then colorspace conversion) would introduce color bleeding. The other way (colorspace conversion, then resize) would not. That is the test we are talking about.
interesting clips, though I would say you should be making smaller resolutions since the color loss gets less and less noticeable the higher the resolution. Another thing I would say is make the boxes 2x2 pixels, and make sure the colorspace conversion to YV12 is with point resampling. That way there is zero color loss when going to YV12. The test I just mention is something I was going to do later when I have time. Lastly, usually color loss is more visible on contrasting colors. Both the white and red are bright colors, so harder to see. I would try something like yellow and black.
Interesting that actually the green/red combination showed the errors more. On my computer, which could be more related to my GPU since flash can use GPU acceleration, the left and right sides seem stretched a little bit, and there is slight bleeding for the red/green. Maybe upload the same clips but without the tag to compare?
Well right now the scaled version looks no different in terms of bleeding vs the unscaled. So I'd say it's done correctly. I really wonder though how much of it depends on the GPU but not flash. I'll try without hardware acceleration.
So reviving this old thread, I finally got around to testing a bit and found out that these tags should really be used instead of manually scaling when a video needs a DAR of 4:3 (or 16:9).
EDIT: That would be useful for my HD encodes on YouTube, but for my SD encodes anywhere else... I guess I'd use Lanczos4Resize.
