Posts for Aktan


Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
feos wrote:
At 500% zoom I notice that some parts of the BG become a tiny bit blurrier, but I can't notice any difference in quality between all the encoded variants.
Which one becomes a tiny bit blurrier? Just curious, lol. Maybe easier to encode? I also do wonder if there is a performance hit. Probably, but it might be very minor.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
slither wrote:
I posted the ffmpeg commands used in the test, I simply did a nearest neighbor scale to the intended resolution. I think testing a stretch directy to 5974x4480 should be tried as well, as this scales the height by an integer.
Whoops, I didn't read closely enough, my bad. Well, we aspect ratio correct in a different way than your ffmpeg command. I think we upscale to a resolution that is close to the aspect ratio correct resolution and then resize to the aspect ratio correct resolution with a different resizer like lanczos. This will eliminate all the artifacts you saw.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Interesting, but how did you do the pixel stretching method? Please post your script. The reason why we don't use the flag is control. If we stretch it ourselves before sending to YT, we have control on how the stretch would take place. It's because we did the stretch already that causes the filesize to increase. This is a given. Depending on how YT does the stretch, it could end up with a smaller file size than how we do it, since the method we stretch is suppose to be an higher quality stretch.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Since this is pretty much Anime, I would personally suggest some kind of neural network to resize.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
It is known in the past that FFMS2 way of converting VFR to CFR is wonky. I don't know if it's still like that now as I have not kept up, but it's why I wrote my own plugin here: https://forum.doom9.org/showthread.php?t=165045
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Good job, keep at it!
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Great work! We should really be moving towards AviSynth+ or VapourSynth. Glad someone wrote a guide and even added multithreading!
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Welcome!
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Holy crap!
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I'm not sure what I say will be comforting, but I'll try. Don't be so hard on yourself. You made a mistake, and fortunately no one was injured. While the charges does seem overly harsh, I'm sure a good lawyer can get the penalty to be as small as possible as it was an accident and you panicked. A misdemeanor is only a minor crime. It's not a felony. I hope this helps.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I hope your father gets well soon and I wish you luck on finding your own path.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Weird, the sample was working fine here. Did you use VFRtoCFR? If so, post your script.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I know mugg did his overlay here all in AviSynth: https://www.youtube.com/watch?v=5NFpUVCfrSE
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Darth Marios wrote:
Thanks, now it worked (i've tried that Crash 2 example, but the final encode lead to a very slow frames video, idk)
What do you mean a very slow frames video?
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
As said by my post, you can also use VFRtoCFR to do the same thing but also FixFPS is also found on this forum. I'll update my post.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I've written the solution in detail here: http://tasvideos.org/forum/viewtopic.php?p=487316#487316 Edit: Here is an example fix using Spike's Crash sample (requires 64-bit AviSynth or get the 32-bit versions of the plugin) (FixFPS here) (Also can use VFRtoCFR to do the same thing): https://www.mediafire.com/file/gx22ljdn3fcpx2r/Crash.zip/file
Post subject: PCSX: How to sync OpenGL GPU with software GPU
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
When using .kkapture with OpenGL GPU plugin (unsure about OGL2 plugin), the capture files seem to be missing load/duplicate frames that the software GPU has. The audio can also be messed up for the OpenGL capture. To fix this, try the following: 1. Capture with OpenGL plugin without audio (we will use software audio) at normal 60 FPS (there may be exceptions to this) 2. Capture with software plugin with audio 3. Create the dup and times file for the software capture making sure you only get the unique frames. For example:
Language: AviSynth

AVISource("software.avi") ExactDedup(firstpass=true, dupinfo="software_dups.txt", times="software_times.txt", maxdupcount=999999)
4. Create the dup and times file for the OpenGL capture making sure you only get the unique frames. For example:
Language: AviSynth

AVISource("OpenGL.avi") ExactDedup(firstpass=true, dupinfo="OpenGL_dups.txt", times="OpenGL_times.txt", maxdupcount=999999)
5. Compare the amount of unique frames the software capture has versus the OpenGL capture. You can do this by setting ExactDedup parameter "firstpass" to false and open up the AVS in VDub to get a frame count. If the amount of unique frames are different, see below under "What to do if the frame count is different" 6. Do a quick check to see if the two captures have the same unique frames. You can do this by opening both of the captures with only unique frames up and go to a random frame number on both captures and compare to see if they are the same 7. Encode the OpenGL capture using the times file created with the software capture. For example: The AVS being sent to x264:
Language: AviSynth

AVISource("OpenGL.avi") ExactDedup(firstpass=false, dupinfo="OpenGL_dups.txt", maxdupcount=999999)
Notice dupinfo is using "OpenGL_dups.txt" The x264 line:
x264.exe --tcfile-in "software_times.txt" --output OpenGL.mkv OpenGL.avs
Notice tcfile-in is set to "software_times.txt" 8. When combining the audio with the OpenGL encode, use the audio from the software capture What to do if the frame count is different Assuming the count difference is minimal, there are a couple of solutions. If there are more unique frames in the OpenGL capture than the software capture, you could do one of the following: 1. It's more than likely the OpenGL has some near duplicate frames that was just rendered a bit off, so you can compare the two captures, find those extra frames, and remove them with DeleteFrame lines added in the AVS 2. You could also just modify the software_times.txt file to add in new times for those near duplicate frames in the OpenGL capture Now, if there are more unique frames in the software capture than the OpenGL capture, you could do one of the following: 1. Modify the software_times.txt to remove the times of extra frames that don't exist in the OpenGL capture 2. Make a duplicate OpenGL frame to act as the extra frame in the software capture via using trim If the difference in unique frames is not small, I don't really have a solution. Here is an example fix using Spike's Crash sample (requires 64-bit AviSynth or get the 32-bit versions of the plugin) (FixFPS here) (Also can use VFRtoCFR to do the same thing): https://www.mediafire.com/file/gx22ljdn3fcpx2r/Crash.zip/file
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I did post the solution. That was it.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
This almost works for Tekken 3 (The OpenGL file had 1 extra frame which looks like a dup at the end, so I'm not sure if it's due to the spot it was cut). You do first pass of ExactDeDup on both software and OpenGL. Then for OpenGL, you use the OpenGL dup file for the AVS, but use the software times file for x264/MKVToolNix. The thinking is that both have the same amount of unique frames, so you just use the right timing of software and combine with the right unique frames for OpenGL. As for dumping at the game framerate. I think it would be better to dump at 60, to make sure you have all frames, then you use FixFPS and then ChangeFPS to lower it back down to 30. I'm unsure of this, but we can talk more on IRC/Discord.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Welcome Maru!
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Okay, I took the time to finally understand why you are using 8:7 PAR to figure out the AR resolution. I got most of my understanding from here and here. Bottom line? It's subjective. But if you want to somewhat emulate (since no CRT TV does the signal the same) what it looks like on old CRT TVs, I think 4:3 DAR is the way to go since it's really easy. Doing PAR method has a couple of problems. 1. We don't actually know what the devs intended 2. It's different per game per system 3. Even in the same game, some sprites were corrected, others were not, so that there is no perfect method I'm sure someone else besides me has already done the research here and why we are going for 4:3 DAR, but this was new (or I completely forgot) to me and I had a lot of fun learning about this. Of course, you are free to choose your own preference, SuperLumberjack, and share with us your varies methods to AR correct using PAR method. Which, by the way, is awesome to see you have figured out how Higan did it! =)
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
It's solely depended on what Windows version you were using, as far as I know. At native, it shouldn't be blurry IMO, since it's the original pixel art. We're kind of getting off topic now though, so I think if we want to continue the blurry conversation, a new topic should be made.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
When I read your previous post above, my first thought is that the game blur is due to how later versions on Windows does on fly resizing which made it blurry. I was trying to explain that I forgot what circumstances are needed to have this happen, but I do know that it changed between Windows XP and Windows 7 (unsure about Windows Vista), and that it was only when an application used one of the older rendering system that Windows supports. Then, after a bit of unsuccessful Google-ing to jog my memory, I gave up and realized that Sonic Mania only recently came out and is highly unlikely to be using the older rendering system. Also the fact that the blur happens at native resolution also. I'm basically saying I had a random thought on why the game may be useful, and nothing useful came from it, that's all.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
It's a pretty new game, so I doubt it's using some old Windows rendering system that. I believe, Win7 started to introduce a blur upscaliling instead of point resize in WinXP. Unfortunately, I forgot what exactly was the problem, and I spent way too much on Google trying to find it (it was bugging me). Also, since your screenshots are of native resolution, so there would be no resizing and the problem I mention above wouldn't have existed anyway. TLDR: I don't know what's going on.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
If you have the upload speed, why not try uploading simpler AVC video files. We usually upload without b-frames and a constant qp of 5. The encodes are faster but the file size are a lot bigger.