Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Mothrayas wrote:
retardedhorse wrote:
You guys do not understand what i mean,i was saying , literally , inside another program , like Crysis inside a box , and then makes the possible to do a TAS on it , understand now?
Not like Hourglass do
Isn't that just what Hourglass does? Sure, it doesn't support much more than smaller 2D games and especially not something as grand as Crysis, but other than that, Hourglass is basically like what you're describing.
The only issue would be is that the "box" for Hourglass is not complete; there are "holes" in it, that is, unintercepted services that make some games unable to be TASed.
The fix then though is to just develop Hourglass more..
New encodes, look much better (and WAY smaller). (URL same as old ones, as archive.org collection was updated).
New youtube, full HD process:
http://www.youtube.com/watch?v=poxUFFOeZl4
Technical info:
No filtering:
I haphazardly patched the GL renderer, stamping out every instance of GL_LINEAR I could find and replacing it with GL_NEAREST. That didn't seem to cover the final conversion for framebuffer to screen, so in addition I uncommented a code block that causes the framebuffer to be output 1:1 on the display. With that done, you get a crisp (all pointresize) image, but it's not quite right. 492 wide by 448 high, where 512 wide x 448 high is expected. So you pointresize up to 512 wide. I used trial and error to position the resize parameters exactly so that all of the single columns got doubled and none of the double columns got tripled. Then you can downsize to 256x224 easily:
A/V Sync:
I used a build that outputs timecodes for each frame to a text file. Scanning that revealed minimal jitter, no lag frames, and a framerate of 60750000/1014391
The audio dump was damaged however (audio dumping in Dolphin is currently a mess). After using the correct framerate and matching up the track beginnings with a delay offset, I noticed that there was still occasional drift through the course of the movie. The DMA is stopped occasionally during loading screens, causing small portions of audio silence to be missing. It was a simple, but slightly tedious matter to match it up by hand using a particular sync point (I found the sound where a boss's HP bar starts to fill up to be pretty easy to read):
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Slowking wrote:
Why is there nothing that can decode that in hardware? What is so special about it?
<-- Noob
It wouldn't be impossible; I just don't think any of the consumer available GPU or dedicated decoders handle 10 bit yet (which is a bit of a fringe format).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
AngerFist wrote:
natt, I don't know if it's due to my codecs (I am using ffdshow) or my computer but every once in a while, the running doesn't appear to be smooth. I am referring to your 720p encode.
I hate to say it, but it might be your computer. The video is 10 bit 4:2:0 at 720P and full 60fps. Nothing can decode that in hardware, so it's full software, and quite demanding at that.
The SD encode (768x432, 8 bit) has also been produced to a high level of quality; you might try that.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
PSXJin has a bit of a bug which causes every video dump to be slightly wrong (one column of pixels is missing). More information: http://tasvideos.org/forum/viewtopic.php?t=12560
Encoders should switch to svn718 or newer for dumping.
In my personal opinion, existing encodes should not be redumped. It's not really a big issue; just one that there's no reason to repeat in the future.
There doesn't appear to be an official build out yet, so here's an unofficial one:
svn718, release, built with MSVC 2010
http://www.mediafire.com/?65hg9gafeo55bql
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
the "HQ" encode will be coming soon. 1280x720 4:2:0 10bit, and it looks awesome. Under 2 gigs too.
For the technically interested, here's a dump (~6MB) of all of the "lag frames" that Dolphin doesn't record right and need to be reconstructed:
"first" is the frame that should be dupped, "second" is the frame that comes right after it. If particular pair of frame numbers appears more than once, then that frame was multiply dedupped; ie "23866 23867" appearing twice means what actually should go in the stream is ... 23865 23866 23866 23866 23867 23868 ...
http://www.mediafire.com/?7r5qyjcz5nx1gb8
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
ReneBalow wrote:
(SetupWiiMem: Can't find setting file).
The download only includes the changed executables. You should unzip them on top of a full dolphin distribution, such as the 32-bit one in here:
http://tasvideos.org/forum/viewtopic.php?t=12484
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
i've made a much better build, will post soon
included executables are against tas-input branch, but if you rebuild from source, probably will work against other branches. contains modifications to video dump code, as well as some (commented out) debugging for the sound dump.
git patches are included.
http://www.mediafire.com/?af25vm0wasnf8m7
functionality is all automatic; frames that should be dupped get dupped to the avi stream. it also creates dolphin_syncout_v2.txt which might be useful to me.
i doubt this will be at all useful to anyone. if you want to report failure/success of it, make sure to keep around dolphin_syncout_v2.txt (it's automatically overwritten each time you dump, so make sure to rename/move it if you want to preserve it)
edit: for NTSC titles, use AssumeFPS (27000*60, 26999). For Pal titles (50 or 60), the original AVI framerate should be correct
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
rog wrote:
The issue appears to be video dumping. As far as i can tell, it dumps only once per VI, even though there can be frames where no VI occurs. I've been successful in getting a/v to to sync by recording the vi/frame counter and adding extra frames to the encode whereever VIs fall behind relative to the frame counter.
So perhaps the practical best thing to do is to dump video with my Awesome New Dump Mode (coming soon!) and then see if you still have a/v sync problems.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
sonicpacker wrote:
That's weird. When I was encoding my SA2:B WIP, I tried multiple audio dumps and they were never the same.
Ilari was going over the sound code today, and from what he said my guess would be it depends on how individual games program the sound hardware. Muramasa in particular doesn't seem to have any such issues.
I do remember discussing Sanic Adventure encodes and av sync with you, but I guess I kind of glossed over some of the details =/
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
sonicpacker wrote:
natt wrote:
I made a "quick" encode...audio sync looks good.
So you fixed the issues that I was explaining to you on IRC a few weeks ago? Did you also fix the fact that Dolphin doesn't dump visual lag frames?
Don't recall what issues we were talking about (sorry!). As far as visual lag frames go, that's the point of this whole a/v sync stuffaroo that I'm doing. And yes, I believe my solution to that is pretty good.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I made a "quick" encode. Colors are wrong (FFMS bug, that's my next step), audio sync looks good. 823MiB (but this isn't indicative of anything, as I did it in ffmpeg with mostly default settings). Anyone want an upload?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Dump took ~14 hours and is ~180GiB (1080p lossless h264 rgb).
Trying to load the dump with DirectShowSource works, but the file is unseekable (consumes all my ram and then hangs vdub trying to seek). And full seeking is definitely necessary for frame fixup shenanigans.
FFMS2 takes about half an hour to index the source, but after that's done seeks only take about 10 seconds. Unfortunately, it has washed out colors (known bug). I'll probably have to go in and fix that bug, because I can't see any other way to load this behemoth.
The sync track looks very strange, I'm still not sure what's going on exactly. So a/v sync is still up in the air.
http://img842.imageshack.us/img842/9443/avsffms.png
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
CoolKirby wrote:
natt wrote:
Can't quite place dup frames exactly where they "should" occur.
Doesn't this affect A/V sync in the encode? Or does the hacked emulator just put the duplicate frames in the wrong places, or replace them with black screens?
The hacked emulator doesn't actually add any frames; the audio and video dumps are exactly what they are on the regular. It just creates the extra timing information.
Adding the dupframes in slightly wrong places does affect AV sync, but it should never get off by too much.
I'll know more when I actually test the method out; you need a pretty long sample to do anything useful.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
This is pretty cool looking:
[URL]http://img407.imageshack.us/img407/2730/syncgraph.png[/URL]
The data is from a ~1 minute test dump I did.
X axis: Video frame numbers.
Y axis: Time offsets in audio samples (48khz, so 800 samples is 1 video frame at the assumed 60fps)
Blue: Raw sync differences as reported by my hacked up dolphin. Due to the crappy nature of the hack, there is MASSIVE jitter.
Red: Blue significantly smoothed, with a +2000 sample offset. The offset is needed because the hack doesn't really understand the different start times at all (and we're assuming the very beginning of the video dump is in line with the very beginning of the audio dump).
Yellow: An approximation of red created by occasionally dupping a frame in the input stream.
Advantages:
1. Can be completely automated.
2. Should be in sync for the entire video.
Disadvantages:
Can't quite place dup frames exactly where they "should" occur.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
TheAxeMan wrote:
Why don't we just publish the main encode. I'll put together the lua for the alternate version some other time.
Yeah, that's what's being done. This is really my fault; the run was marked as "publication in progress" OmnipotentEntity and I didn't communicate with him on the extra encode. I talked to him on IRC and he's assembling a standard publication package; the standard downloadable will include the soft-subs that you created.
I, being a fool, have gotten too much on my plate, but I promise to make your extra encode and add it at some future point.
As far as an example lua script, would it help if I gave you the lua script I used for http://tasvideos.org/forum/viewtopic.php?p=304645#304645?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I've hacked up Dolphin to create timing information. I think it should be sufficient to recover usable a/v sync.
I've done some test dumps. Looks like it will take about 15 hours and 180+ GiB for a lossless x264 rgb dump at 1080p.
I'm not satisfied with image quality at the moment.
http://img808.imageshack.us/img808/3091/firstblood.png
1. Minor texture seams (you can see quite a few in that picture): These appear to present no matter what I do.
2. Lack of overall interesting detail: The game is primarily "textures as backdrops" and is not heavily polygon oriented. There just isn't 1080p of quality there. I don't mind my processing time so much, but I'm hesitant on presenting a 1080p encode to the end user that just wastes everyone's bits and cycles. Perhaps the best HQ downloadable would be 720p instead? I think that practically speaking, it would have just about all of the actual quality that a 1080p would, and would be smaller to download and easier to play. (How many systems out there, in any configuration at all, can play 1080p60? Before you say hardware accel, this would likely be outside the level restrictions of the existing gpu accelerators.)
