I just noticed now that the encode has stereo sound, which is awesome. Makes it easier on the ears if you want to focus on half of the screen for a while.
Thanks for the compliment, but this is not a new idea. The Mega Man quad run already did this, and I think Flygon's YouTube version did this as well.
It was interesting to me to see that only SMB3 used any power-ups, though, as people have already said in this thread, SMB3 is the longest of the four, and needs to be optimized the most. Easy yes vote.
Sorry for the delay, but will have this published soon.
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.
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?
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.
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.
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.
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.
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.
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.
Updating won't fix it. The fix is to disable the header removal compression. That option is in the newer versions of MKVToolnix. I don't think using an older version just so you don't need to set the option is a good idea.