Site Admin, Skilled player (1235)
Joined: 4/17/2010
Posts: 11264
Location: RU
So what shall we do when encoding things like SotN? A run of it dumps to 70+ segments. Each time gameplay is interrupted (menus, cutscenes), we get another 2 segments. On a TV screen, it always looks good, as long as the resulting resolution is high. But we don't upscale our SD encodes. It's even more complicated since we also don't even apply aspect ratio correction for the primary encode, trying to keep the original gameplay screen untouched. One possible solution would be to force the GPU plugin just resize the frame to whatever we set (gameplay is in 256x240), and deal with just a single segment. But as is known, it distorts all 1 pixel wide elements (letters, borders). And we don't want to make it resize everything to the menus width either, because it distorts the gameplay picture and increases the file size. Other option is to resize all those segments to 256x240 using lanczos on the AVS side, on import. But that requires some extra automation avisnth doesn't provide. It would still look wrong, but it's the best we can do I guess. There's also an option to just ignore all the menus, and only append the credits to the otherwise totally resized dump of the whole run. That's what I did last time. The last one I know of is upscaling them all to some "least common multiple", and then down to 240x320 or whatever. But I didn't try anything about it. And the second problem is importing them all to begin with. The amount of segments overcomes the avisource plugin limits, and they all have that frame size appendix in their names, so you either need to rename them all, or do some magic in the script. However, the function I linked above also does it. But the problem with it is that it is slow due to resolution, and even mores slow due to that external avi importer. If the files had no appendix, we could use something like this:
Language: avisynth

AppendSegment("_movie", 1, 7, "%03.0f") function AppendSegment( \ string base, \ int first_val, \ int last_val, \ string format \){ AviSegment = String(first_val, format) + base + ".avi" result = Eval("AviSource(AviSegment).LanczosResize(256,240)") return (first_val < last_val) \ ? result + AppendSegment(base,first_val+1,last_val,format) \ : result }
Gameplay won't be resized, and the menus will be scaled the soft way. EDIT: Well, I renamed the files with AdvancedRenamer, and importing all 75 segments worked with just AviSource! And it does look OK to me.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Every time I had to do one of these, I cooked up something new. I think I did a SOTN once, but with enough cajoling I was able to get all the clips into memory at once (it was a shorter run I suppose?) Final Fantasy VIII and IX each had their own special setups involving a secondary program stitching together video files into bigger video files so I wouldn't have any out of memory problems. Final Fantasy VIII was by far the worst. My scripts processed all of the segments for each resolution into a single large video, together with a timeline for how it all assembled back together: http://pastebin.com/emfw295L When in that form, choosing a scaling treatment for each resolution is trivial (and you can see what I chose for FF8: 320x224, cropping or padding 320x* to fit, lanczos resize on anything else). If we're willing to hack something new into psxjin, you could do something like the final fantasy 8 encode without too much trouble with most of the work being automatic behind the scenes. Any solution that has the number of files open scaling with the length of the run is going to fail eventually, regardless of input plugin, and should be avoided.
Post subject: Re: Multiresolution games
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
Other option is to resize all those segments to 256x240 using lanczos on the AVS side, on import. But that requires some extra automation avisnth doesn't provide. It would still look wrong, but it's the best we can do I guess.
That part is pretty trivial in avisynth; just use a loop (or what passes as a loop in that horrible language) to call a function like this for each filename:
Language: avisynth

function ImportFunc (string s) { FFVideoSource (s) #Info AssumeFPS (1, 1) #PointResize (640, 480) #320x240: only the first loading part last.height == 240 ? Crop (0, 8, -0, -8) : last #320x216: rather common, battle screens last.height == 216 ? AddBorders (0, 4, 0, 4) : last #368x224: text screns last.width == 368 ? LanczosResize (320, 224, 0.0, 0.0, 368.0, 224.0) : last #640x480: opening and disk switch last.height == 480 ? Crop (0, 16, -0, -16).LanczosResize (320, 224) : last return last }
(This code is from a different attempt at FF8, where I tried to use MPPipeline to get around memory limitations. Unfortunately, MPPipeline is garbage.)
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Just crt_display them all to 640x480. ^_^
Site Admin, Skilled player (1235)
Joined: 4/17/2010
Posts: 11264
Location: RU
So what do you guys think of my own function? I'm already encoding with it. The only not yet automated part is importing the files by name. If PSXjin had an option to not append the resolution to the name, it would be completely solved to me. I even can do it myself, I just don't have the proper access.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
So what do you guys think of my own function? I'm already encoding with it. The only not yet automated part is importing the files by name. If PSXjin had an option to not append the resolution to the name, it would be completely solved to me. I even can do it myself, I just don't have the proper access.
It forces you to handle all resizes in the same way (lanczos with no cropping and no position offset parameters). In some cases you might want more control.
Site Admin, Skilled player (1235)
Joined: 4/17/2010
Posts: 11264
Location: RU
Made "append resolution" optional. Moved segment count to after the name. http://pastebin.com/gjjvBuYh
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Site Admin, Skilled player (1235)
Joined: 4/17/2010
Posts: 11264
Location: RU
natt wrote:
feos wrote:
So what do you guys think of my own function? I'm already encoding with it. The only not yet automated part is importing the files by name. If PSXjin had an option to not append the resolution to the name, it would be completely solved to me. I even can do it myself, I just don't have the proper access.
It forces you to handle all resizes in the same way (lanczos with no cropping and no position offset parameters). In some cases you might want more control.
What are those cases? How do you know you should crop the picture and then still apply aspect ratio correction? For example, Crash 1 outputs 12-pixel borders on top and bottom, and you cropped them in the encode and then did ARC of 512x216 to 4:3, right? Doesn't sound the same as ARCing 512x240.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.