Posts for TheCoreyBurton


1 2 3
12 13
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
The queue contains the entirety of the job info, not only information about the video file. This means that if you queued up a video with no filters, it will be processed with no filters. The easiest way to work with this is to load your first video and apply the filters you desire. Next, save your processing settings (File > Save processing settings) to some easy-to-find location, then before queuing each video, load these same processing settings.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Could you please post a sample of the footage to play around with?
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Marusame wrote:
540x720
I thought that mighty be the case. It's something that happens with vertical videos. My best guess is that Youtube's encoding calculations are based on height, but it's resolution options are based on width. This means that when it's encoded the video it's detected 720p and encoded a 720p60 stream, but the resulting video has instead been labeled as 480p60.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Find a video that's displaying at 480p60, right click the video in Youtube and select "stats for nerds". What is the resolution the video is playing back at?
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Habreno wrote:
612x448?
I don't have a copy of the game itself, so I can only speak in terms of what I worked with. I have two separate dumps, one for the PAL sections and one for the PAL60 sections. Both were done at 1x internal resolution by Dolphin's calculations (which could be very well be wrong). The PAL dump is at 608x456 and 50fps. The PAL60 dump dump is at 596x448 and 60fps. For the encode, it's all at PAL60 except for the footage prior to setting 60hz mode. This means that the Youtube and 512kb encode were both done at 60fps to give the best viewing experience, and the MKV is at 50/60 VFR (using 300fps for decimation). As for resolution, the downloadables were resized to match the PAL60 segments as it was the most common resolution, whereas for Youtube both segments were resized independently to 1440x1080 (and soon 5760x4320). In all of these cases the destination resolution is 4:3 as the game was intended for CRT display.
Habreno wrote:
TP's resolution, after cropping out the overscan, is 612px by 448px
This is interesting and likely responsible for the discrepancy. The footage you see on the encodes hasn't been cropped or adjusted (beyond what I mentioned above). It was presented without overscan.
Habreno wrote:
I also wanted to add this: I really like where you put the TAS information at. Clever spot.
Thank you. I try to make the subtitles as visually appealing as possible! :D Spikestuff actually suggested a nice improvement in relation to the timing as well, which has been incorporated into the replacement encodes.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
I'm starting to get an aversion towards the entire series.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Just in time to officially be a 2018 publication! To try and answer a few questions before they're asked, the encodes that are currently available are only temporary. I've got the proper set running on my PC right now, but it looks like they won't be ready until a couple of days in to the new year. For the time being, feos has provided downloadable encodes and I provided a quick 1080p encode for Youtube so that this could be published in 2018. Each encode will be replaced with the improved encode as soon as the new one is available. Sorry this one has taken so long. Some exciting extra encodes will be on the way too, but right my main priority is the publication itself. Edit: The downloadable encodes have been replaced with the final encodes, as have the associated torrent files.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
In addition to the encodes available on the publication page, here are some extra downloadable encodes for this run: Additional resolutions: 480p: Direct Link | Torrent 720p: Direct Link | Torrent 1080p: Direct Link | Torrent Additional resolutions (with mini-game explanations and results removed): 480p: Direct Link | Torrent 720p: Direct Link | Torrent 1080p: Direct Link | Torrent Lossless encodes: Standard: Direct Link | Torrent Native*: Direct Link | Torrent Lossless encodes (with mini-game explanations and results removed): Standard: Direct Link | Torrent Native*: Direct Link | Torrent * Encodes marked with an asterisk are done at native resolution with no graphical enhancements (such as anti-aliasing or anisotropic filtering). To download these files you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Guernsey wrote:
In Virtualdub do you change the aspect ratio after you setup the resize filter settings for the video you made?
If you're processing in Virtualdub alone, then you can do this at any stage but for the best quality output it's best to do it last. I'd resize each dimension to something larger (it doesn't have to be way over, just slightly bigger) than the 4:3 resolution you want using nearest neighbor, then I'd resize back down to the destination using Lanczos. You'll get even better clarity if you can avoid resizing either the width or height in this final step. I'll do my best to explain via some examples: Assuming you have Genesis footage which is 320x224. You can point resize this by 300% to 960x672. From here, you can do a number of resizes to make it 4:3. You can Lanczos resize it to 960x720, which will expand the height or you can Lanczos resize it to 896x672, which will shrink the width. In both cases, one dimension remains untouched and will remain perfectly clear from the point resize. The other option you have (in terms of hard resizing and maintain pixel sizes) is resizing by some larger number for both dimensions, such as 500%. That'll push it to 1600x1120, then you can Lanczos resize this down to 1440x1080 for a 1080p clip. If you're going encode MKV, I'd probably just avoid AR correction altogether and just upscale via a percentage in nearest neighbor, then use mkvmerge to set the display dimensions to 4:3. Then it'll be stretched on playback to the AR. It's worth noting that selecting the aspect ratio by right clicking the preview window is for the preview only and doesn't affect the output clip.
Guernsey wrote:
Asol, is the aspect ratio different for Genesis consoles or is it just the same?
Genesis uses 4:3. A good way to remind yourself is that if the console was intended for display on a CRT television, then it was intended for 4:3 display.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
EZGames69 wrote:
You may not have the right graphics card for your computer. When I talked to Corey about it disappeared in my encode he said it was due to not having a strong graphics card.
I said "perhaps", as that was my original suspicion. Feos and I checked on both our machines earlier (I meet all of the requirements) and whilst similar issues are resolved on mine, this one's present on both. It could be an unreported bug in the graphics plugin, core, or maybe it's just a TAS-induced oddity.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
As of about ten minutes ago, I have finished a complete dump of this run. The audio is in sync at 10 interval-based test points and five random test points. It looks like Fog's latest build has fixed the issue and I'll be continuing with the publication like normal from this point onwards.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
In addition to the encodes available on the publication page, here are some extra downloadable encodes for this run: Additional resolutions: 720p: Direct Link | Torrent 1080p: Direct Link | Torrent Lossless encodes: Standard: Direct Link | Torrent Native*: Direct Link | Torrent * Encodes marked with an asterisk are done at native resolution with no graphical enhancements (such as anti-aliasing or anisotropic filtering). To download these files you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
I'd love to see one (or more) of the games from Blueskied make it on here. Bound Around and Frozen Fruits 4 would be my main choices, but they'd also be bigger projects. There are a couple of free games that play the same but are much shorter. Edit: Oops, looks like I'd already made the same request back in 2015.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Ah, memories. It might not be the most glamorous game, but the dialog is incredibly well-written. It's going to take a while to read it all and determine if it's a "yes" or "meh" from me, so stay tuned. Edit: I ended up deciding on "meh" for entertainment as a result of the text-based nature of the game limiting my potential enjoyment, but you've managed to trivialize months of my own frustration and that has still made me very happy.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Recently, [1252] SNES Lemmings "best ending" by Lord_Tom in 1:03:04.45 was labelled as "all levels", despite the submission text stating
Many believe that the ideal Lemmings run would complete all 120 levels. However, with each level taking, say, 1.5 minutes, that's 3 hours, and many of the levels repeat with subtle differences to increase difficulty as the game progresses.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Guernsey wrote:
Is a 4:3.ratio good for some SNES games?
As these games were intended to be viewed on a CRT, yes. 4:3 is the correct aspect ratio here.
Guernsey wrote:
Or should keep the borders?
Do the dumps (or playback in the emulator) have the borders you mentioned initially, prior to their upscaling? I only ask because SNES dumps are generally 8:7 and depending on how PowerDirector is handling the upscaling, it could be trying to keep the original aspect ratio and adding these itself. Ideally you want the dumped footage to take up the entire 4:3 frame, so it depends if these borders are part of the game or not. When adding a filter to Virtualdub, you can crop prior to the filter's processing. The easiest way to do this without changing the video is to go Video > Filters > Add > Null Transform and hit "OK". On the side, you can select "cropping" and adjust this however you feel is necessary, but for SNES dumps you shouldn't have to do this. I posted something with a couple of methods of using VirtualDub for nearest neighbor upscaling if you wanted ideas on how to upscale the dumped footage without the need of PowerDirector.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
feos wrote:
Does it even desync within segments?
Yes, unfortunately. I've got a few notes on the problem: The desync is not gradual, it occurs at specific points (which appear to be during transitions). Prior to such a transition the audio is in consistent sync, and afterwards it remains out by a consistent amount until the next point occurs. It appears to be one way. The video appears to drift ahead of the audio. There are only two different FPS segments in the run. The first 244 frames are at 50 and the rest is at 60. The first desync occurs somewhere between 5:45 and 6:45, likely during a transition. The window is large because it's easy to verify sync at these points. The first obvious moment for the desync is at 6:44. There's a hit and the audio's very visibly out. This is the same issue I've noticed in several runs prior to ffmpeg dumping being introduced on Windows. In those cases, dumping via Linux was a viable solution as it used ffmpeg dumping and didn't exhibit these problems. According to Fog (in a private conversation), in relation to this information: "if it's the proper ffmpeg dumping, it should be dumping based on timecodes instead of frames" Feel free to correct me if any of this information is wrong, I'm pretty tired at the moment. Otherwise, I've also edited my previous post with an update.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Instead of coining an entirely new term, can we use "re-recording environment" and then shorten it to "RRE" for general talk? It doesn't have to be that term specifically, but this way it keeps things a bit more straightforward.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Habreno wrote:
Possible to get some kind of update on this? Is it in encoding limbo, is there someone working on getting an encode, is it working on trying to modify a Dolphin build to get an encode, etc...
I've just taken this for publication after doing a couple of test dumps. It looks like everything will be fine, but I don't want to get ahead of myself just yet. It's a fairly long run and I'm currently working on a few other things as well so it won't be a fast process, but it is currently being processed nonetheless. If things go well, I'd estimate a December publication but this is subject to change based on circumstance. Full steam ahead! Edit 1: I finished a complete dump and at the moment it looks like there is still a problem with the audio. I'll post here with any updates on the issue. Edit 2: After the first build failed to resolve the issue completely, Fog ported a second fix, this time regarding the audio sample rate. Unfortunately it still didn't resolve the issue. Unless a better solution presents itself, it's looking like ffmpeg dumping might have to be ported and this will take more time. My original estimate of December is very unlikely at this point, as even after dumping, encoding could take a few weeks.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
In addition to the encodes available on the publication page, here is an extra downloadable encode for this run: Lossless: Direct Link | Torrent To download these files you may have to right click on the link and select "save link as" (this option may be named differently depending on your web browser).
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
Great work, DungeonFacts! I'll take this for publication if it gets accepted. I go on a short vacation (lasting just over a week) starting tomorrow, but I've already prepared all the encodes just in case.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
I've never used ffmpeg for resizing, but I do have a fair bit of experience with nearest neighbor elsewhere. The most important question here is: what resolution are you resizing to? Due to the nature of the nearest neighbor, it will produce uneven pixel sizes if the destination dimensions aren't multiples of the respective source dimensions. This is because it doesn't interpolate colors between pixels, so each destination pixel is going to be the same color as an appropriate source pixel. I'm probably not the best at explaining this, but here's an attempt at an example: Assume you have a source frame that is 100 pixels wide. If your destination width is 200 (a factor of 2), each source pixel becomes two destination pixels. In this case, the width is doubled and the sharpness of the original image is retained. If your destination width is 150 pixels width (a factor of 1.5), each pixel becomes 1.5 destination pixels. This means the first destination pixel uses the first source pixel, but the second destination pixel is half of the first source pixel and half of the second source pixel. Because the filter only uses the exact colors from the source, it will have to choose one of these two (the nearest neighbor) to place there. This results in uneven pixel sizes. There are a couple of solutions here (though I'm not sure how they translate into ffmpeg) that might help: 1 - Resize the width and height by the same integer (4x, for example) and then set a 4:3 AR flag on the file (AR flags don't change the video data, but instead tell the player to stretch the video upon playback). 2 - Resize the width and height by separate integers that result in the correct aspect ratio. If you want 256x224 to play at 4:3, you can use 7 and 6 respectively. This gives 1792x1344, which is 4:3 and would have consistent pixel sizes. This tool may help you calculate the integers for this process. 3 - Resize the width and height (using nearest neighbor) by integers to a resolution that is higher than the resolution you wish to display at, then resize via Lanczos down to the destination resolution. For example: Resize 256x224 to 1536x1120 via nearest neighbor, then to 1440x1080 via Lanczos. This introduces a pixel's worth of blur to the resulting image, but can target any resolution. There are likely other solutions too.
I'm not as active as I once was, but I can be reached here if I should be needed.
Post subject: Re: Limit on framerate for PC games
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
To clarify my previous point, I do not mean to present the three ideas as separate items. The intention is that they work in tandem to provide the best coverage I can see for all scenarios. The general idea is to keep things running at the simplest frame rate they can without sacrifice and if it's beyond a practical encoding limit, then encode that with minimum sacrifice. To summarize: In order to keep things simple, I think 60 or 50 should be chosen where possible. If 60 or 50 is not an appropriate choice for the game, then a higher rate can be chosen (with explanation and justification in the submission text). If it's under 120 (what I'd suggest is the practical encoding limit), it can be any value. If it's above that limit then it should preferably be a multiple of 50 or 60 so that it can be decimated down. The rate it's decimated to will depend on the game and content. Ideally this would be 50 or 60, but if there's a benefit to 100 or 120 then I don't see why it shouldn't be allowed and there may be fringe cases where a trick is only available at 471fps for example, in which a best-case decimation should be applied. The values I provided are just my best thoughts at the moment and can be easily changed. The problem with relying on current hardware maximums is that unlike console hardware, computer hardware is constantly progressing. If we base limitations on current hardware, as that hardware becomes obsolete so will our limitations, and there's a chance movies will be obsoleted simply from changes in these limitations. Because of that, I don't see a point in capping movies to a specific frame rate, as long as it can be well-justified and caution is exercised. But at what point do encodes become impractical? I'd strongly argue for 120fps and suggest that in cases beyond that the movie file is used for closer examination, or alternatively a higher frame rate encode is given at a basic resolution as an extra encode (much like high resolution encodes for 3D consoles) in specific cases.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
I think perhaps several different ideas are needed to be combined here. My thoughts are as follows: 60fps should be encouraged where possible, as it's the de facto standard. 50fps could also be commonly acceptable for similar reasons. For arbitrary frame rates (such as 71, 93 or 111), a cap at 120fps is placed. This covers current DOS publications, allows for games with odd native rates, and also allows for high-frame rate publications without putting unnecessary strain on the encoders or viewers (the latter due to file size or playback requirements). For excessive rates (such as 360 or 1000), they could be acceptable as long as they're a multiple of the two standard rates mentioned above: 50 or 60. In these cases, the runs could be decimated down to those frame rates (or maybe even 100 or 120, depending on if the higher frame rates are allowed) when encoding, but frame-specific tricks could still be performed (and watched with the input file). Regarding the fact we'd lose a large portion of video data doing this, it's theoretically no different to running a game at an unlimited frame rate on a 60hz screen. You might be getting 1000fps generated a second, but you're only seeing 60 of them and so the viewing experience won't necessarily be different to the on the game actually provides. Edit: In the last scenario, it should probably also be possible to play back the movie at the higher rate (for example 600fps) whilst dumping at the decimated rate (for example 60fps) in order for this suggestion to be practical. Whilst the decimation can be done in AVISynth, at higher resolutions 1000fps will not only take an incredible amount of time, but will also use an absolutely gargantuan amount of HDD space. For reference, a few 4K Dolphin dumps I've done lately have hit the 2tb mark and they're only 60fps.
I'm not as active as I once was, but I can be reached here if I should be needed.
Experienced Forum User
Joined: 10/14/2013
Posts: 335
Location: Australia
creaothceann wrote:
Any programs in the background getting active periodically?
This would be my first thought too (after seeing your PC specs). Try going into Task Manager > Details and find Bizhawk on the list. Right click it, Set priority > High. If that improves the situation, then the issue is likely the result of another active program using your processor.
I'm not as active as I once was, but I can be reached here if I should be needed.
1 2 3
12 13