I adjusted my settings to include your suggestions, but it increased the file size to 0.6 MB. I can't really tell if it means anything; the 200 frames segment is relatively low-motion.
Thank you!
I need more details, like what was the exact line and what resize factor? I'm assuming 8x?
--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
Aktan, do you remember? In good old days we were using mkvmerge option for youtube HD aspect ratio correction. Back then we were also using somewhat low resolutions for HD.
Then we switched to avisynth resizing for aspect ratio correction. It was reported to yield sharper picture, but I don't exactly remember.
Then we switched to x8 encode and ARC with a youtube tag.
After the latter method died, we reverted to the avisynth ARC method, which required reducing our ambitions with the file sizes again.
But what if we switch to mkv way again? It would let us send x8, with less file size, giving the benefits of the 2 methods. Will it look worse than x8 + yt tag ARC? Will it look as good as it does right now?
I could do some tests (feos versus youtube v2), but kinda busy.
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.
Or we could try working with the author in order to help us do our job with encodes. Jeez, if only I had MORE TIME. We're a constant source of new tests after all, and he seems somewhat active.
He is? His last commit being over a year ago seems otherwise. Also us moving away from Mupen and PCSX, I don't see a need really anymore?
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.
Thank you. I messaged Fog and he helped me import the file (I believe it was an oversight on my behalf). The correct way to do so is to use FFVideoSource, for anyone else coming across this message.
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.
Hi, I try to encode a movie, but when I launch my script with VirtualDub, he tells me : "variable 'LoadPlugin' not found"
Does anyone knows how to fix this ?
Can you post your script on Pastebin.com and give us a link?
So the larger the original footage, the more color bleeding there will be. Well, that's fair I guess. (I normally do 720p instead of 1080p, but GBx footage doesn't 2x scale to 720p)
You must also remember, the larger the source, the less pixelated it is in general also, so less likely to also have color lines.
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...
So assuming you have a video in RGB to begin with, you resize with a factor of 2 using point size or nearest neighbor. The point of this is to double (or quadrouple, etc) each pixel both horizontally and vertically, making each 2x2 block contain four identical pixels. This means that when the chroma is compressed down to represent the 2x2 block, no data is discarded and then no blurring/blending occurs.
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.
Afaik only YV24 and RGB have pixel-perfect colors at native resolution.
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:
I see. Switching to x264 solves that issue, but now I am getting sound desyncs.
Pretty sure I still have everything set to default in my configurations. Is there anything I should change there that might fix it?
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.