--bframes 16 isn't needed for --crf 0 since bframes don't exist on lossless. --bframes 16 also is pointless with --qp 10 -b 0 since -b 0 means NO bframes. --crf 33 is a lot worse quality than --qp 10. Please don't use --crf 0, it's really --qp 0. Oh, and change --keyint to infinite. Lastly, --output-csp should not be there. You're not going for RGB. It should be YV12 for YT.
This is a hard question. Technically you want to be in control all resizes, so if you send a file and YT resizes, you really should resend a new file to match the resize of YT so YT doesn't do any resize. Since we know any scale factor will result in a resize by YT, I think the best bet is to resize larger than what YT will resize to, then downscale to YT's resolution. Basically point resize up, then probably Lanczos resize down.
Edit: Basically we may have been sending all encodes to YT wrong all this time... oh crap... lol
Doing any AR flag is not a good method because YouTube would resize with whatever way to be AR corrected. So sending a MKV with AR flag should never be done. We are stuck now with what we are doing now, which is try to resize in multiples as best as we can to the correct AR with point resize.
Commit was over a year ago, so I'm assuming still using the new way (name escapes me) and not detours. The new way wasn't working for me at all in the two applications I used .kkapture for (Mupen and PCSX). Sure we can try again if someone can compile the latest source on github, but I'm leaning towards no change in it working.
If I remember correctly, while you can load the file with FFVideoSource, the timestamps were not correct however. If the AVI has dup frames though, wrong timestamps shouldn't matter.
This is a known issue with FFV1. Basically FFV1 codec version 2 or 3 (I forgot) is not well supported in AviSynth. The workaround is to set Dolphin to use version 1 of FFV1. Or reencode to version 1 with FFMPEG (which seems like it isn't possible). Fog had add the option to encode to version 1 (since the options for FFV1 used to be hard coded) but I'm not sure if it actually got in. I think it did.
I'm on vacation right now, but when I get back, I can take a look. The problem with the camhack enabled recording over the movie sounds familiar, but I think there is a simple workaround.
I'm with fsvgm777, if even a simple AVS with just Version() in it doesn't work, it sounds like 32-bit/64-bit problem. Where did you get your install of AviSynth and where did you get your install of VirtualDub. Exact URLs please.
Honestly, since you already point resized upscale, not much. There will be slight color bleeding, but not enough for anyone to really notice at 1080p since the original resolution was so small.
Edit: I just like to really do the best I can to reduce that amount, hence the lines I posted earlier.
To make matters worse, when you convert back to RGB as most displays are or YUV4:4:4, the upscaling of the chroma is probably not using point resize either, adding some color bleeding also...
This doesn't work because when you convert to YV12, the downsampling of the chroma is not done by point usually. Bilinear (I think?) and Bicubical looks more than the 2x2 block. That means the color sample might have a hint of the surrounding color with it.
Just doubling wouldn't work as most colospace conversion when discarding the color info is using a scaler other than point resize. The correct way is to convert is to make sure the chroma scaler is using point resize. Like so:
Language: Avisynth
ConvertToYV12(chromaresample="point")
To add onto this, unless the later AviSynth version fixed this, the param "chromaresample" would be ignored if the source isn't already in YUV, so the real way is doing like this:
You could also retry Lagarith without NULL frames. That's probably what is really causing it.
Edit: H.264 in AVI is a bad idea. I would recommend not doing it that way.