Posts for Aktan

Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Sorry for the delay, I have no excuse =(. It works fine here, how do you trigger the cam hack? I have the cam hack hotkey set to S.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
MUGG wrote:
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?
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
--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.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
you should try --qp 10 -b 0 Edit: --crf 0 is really --qp 0, --crf 0 doesn't make much sense.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
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
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
feos wrote:
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.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
feos wrote:
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?
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
feos wrote:
Aktan, what do you think of new kkapture versions? https://github.com/rygorous/kkapture/commits/master
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.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
thecoreyburton wrote:
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.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
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.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
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.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I'm on vacation right now, so when I get back, I can
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
It's a special VBA build. Should be available somewhere.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
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.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
If you make a new AVS with only the following line and open it in VirtualDub, what happens?:
Language: avisynth

Version()
Post subject: Re: Problem with VirtualDub and avs scripts
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Stovent wrote:
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?
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Pokota wrote:
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.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
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.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
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...
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
thecoreyburton wrote:
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.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Sonia wrote:
@Pokota Does it need to be only to the power of 2 or can I simply use any even number? I'm asking this because I work with 6x and 10x sometimes too.
Any even number for YV12 and YUY2.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
creaothceann wrote:
Try doubling the resolution:
Language: Avisynth

AVISource("video.avi") PointResize(Width * 2, Height * 2)
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:
Language: Avisynth

ConvertToYV24(chromaresample="point") ConvertToYV12(chromaresample="point")
Last minor point is there are color conversion matrix for different resolutions. For native console resolutions, it is mostly BT.601.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
This is why our download encodes on the site are in YV24 colorspace.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Hetfield90 wrote:
I was still having the same issue with Lagarith without null frames enabled.
Well, so much for that, lol. It's too bad YT doesn't like Lagarith. Oh well, I would go with feos' suggestion.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Hetfield90 wrote:
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.